dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-03-16T08:27:57Zhttps://git.dynare.org/Dynare/dynare/-/issues/1716Fix bug in contemp_reduced_form of SBVAR2020-03-16T08:27:57ZJohannes Pfeifer Fix bug in contemp_reduced_form of SBVARAs outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveBVAR.mod](/uploads/f7b1c204676a2323d03a467702f6e3c5/constantRecursiveBVAR.mod)As outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveBVAR.mod](/uploads/f7b1c204676a2323d03a467702f6e3c5/constantRecursiveBVAR.mod)https://git.dynare.org/Dynare/dynare/-/issues/1745Adding support for dates in perfect_foresight_setup2020-09-25T08:38:53ZMichelJuillardAdding support for dates in perfect_foresight_setupThe user should be able to control the dates of the dseries produced by ``perfect_foresight_solver``
- Currently, `histval``,``histval_file`` and ``initval_file`` pass a ``dseries` to ``perfect_foresight_setup``
- By default, ``perfect_foresight_setup`` should be consistent with the dates of this ``dseries``
- dates must be permitted in ``histval`` instead of only signed integers
- ``first_obs``: sets the dates used for the first initial conditions. Must be consistent with ``histval`` or ``histval_file`` if they are used
- ``first_simulation_period``: sets the dates used for the first period of the simulation. It is an alternative to specifying ``first_obs`` and must be consistent if ``first_obs``is also used as an option. Values for initial conditions before this date must be available. Must be consistent with ``histval`` or ``histval_file`` if they are used.
- ``last_simulation_period``: sets the date of the last period of simulation. It is an alternative to specifying ``periods`` and must be consistent if ``periods``is also used as an option. Data for terminal conditions past the last period must be availableThe user should be able to control the dates of the dseries produced by ``perfect_foresight_solver``
- Currently, `histval``,``histval_file`` and ``initval_file`` pass a ``dseries` to ``perfect_foresight_setup``
- By default, ``perfect_foresight_setup`` should be consistent with the dates of this ``dseries``
- dates must be permitted in ``histval`` instead of only signed integers
- ``first_obs``: sets the dates used for the first initial conditions. Must be consistent with ``histval`` or ``histval_file`` if they are used
- ``first_simulation_period``: sets the dates used for the first period of the simulation. It is an alternative to specifying ``first_obs`` and must be consistent if ``first_obs``is also used as an option. Values for initial conditions before this date must be available. Must be consistent with ``histval`` or ``histval_file`` if they are used.
- ``last_simulation_period``: sets the date of the last period of simulation. It is an alternative to specifying ``periods`` and must be consistent if ``periods``is also used as an option. Data for terminal conditions past the last period must be available4.7MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1744endogenous_prior with missing observation2020-09-21T10:32:53Znaivejendogenous_prior with missing observationHi dynare team,
(Sorry if I posted in the wrong place, I just realised that gitlab seems for developers only)
In v4.6.2, endogenous_prior cannot work with missing observation, but this is not pointed out in the Reference Manual.
I suppose a naive way to fix this is to exclude any period or variables with missing observations in the calculation of statistics.
Currently, I modified the code as follows but not sure if this is statistically correct. Is there a better way to make this work?
```matlab
Ydemean(:,j)=Y(:,j)-mean(Y(:,j),'omitnan');
Fhat=std(Ydemean,1,'omitnan').^2';
for j=1:n
Ydemean(:,j)=Y(:,j)-mean(Y(:,j),'omitnan');
end
Fhat=std(Ydemean,1,'omitnan').^2';%Fhat=diag(Ydemean'*Ydemean)/Tsamp;
Sgood=find(~any(isnan(Y),2));
Tgood=length(Sgood);
hmat=zeros(n,Tgood);
% we need ht, where t=1,...,T
for t=1:Tgood
hmat(:,t)=diag(Ydemean(Sgood(t),:)'*Ydemean(Sgood(t),:))-Fhat;
end
% To calculate Shat we need C0, C1 and C2
for t=1:Tgood
C0=C0+1/Tgood*hmat(:,t)*hmat(:,t)';
end
for t=2:Tgood
C1=C1+1/(Tgood-1)*hmat(:,t)*hmat(:,t-1)';
end
for t=3:Tgood
C2=C2+1/(Tgood-2)*hmat(:,t)*hmat(:,t-2)';
end
```Hi dynare team,
(Sorry if I posted in the wrong place, I just realised that gitlab seems for developers only)
In v4.6.2, endogenous_prior cannot work with missing observation, but this is not pointed out in the Reference Manual.
I suppose a naive way to fix this is to exclude any period or variables with missing observations in the calculation of statistics.
Currently, I modified the code as follows but not sure if this is statistically correct. Is there a better way to make this work?
```matlab
Ydemean(:,j)=Y(:,j)-mean(Y(:,j),'omitnan');
Fhat=std(Ydemean,1,'omitnan').^2';
for j=1:n
Ydemean(:,j)=Y(:,j)-mean(Y(:,j),'omitnan');
end
Fhat=std(Ydemean,1,'omitnan').^2';%Fhat=diag(Ydemean'*Ydemean)/Tsamp;
Sgood=find(~any(isnan(Y),2));
Tgood=length(Sgood);
hmat=zeros(n,Tgood);
% we need ht, where t=1,...,T
for t=1:Tgood
hmat(:,t)=diag(Ydemean(Sgood(t),:)'*Ydemean(Sgood(t),:))-Fhat;
end
% To calculate Shat we need C0, C1 and C2
for t=1:Tgood
C0=C0+1/Tgood*hmat(:,t)*hmat(:,t)';
end
for t=2:Tgood
C1=C1+1/(Tgood-1)*hmat(:,t)*hmat(:,t-1)';
end
for t=3:Tgood
C2=C2+1/(Tgood-2)*hmat(:,t)*hmat(:,t-2)';
end
```4.7https://git.dynare.org/Dynare/dynare/-/issues/1743Start diary earlier to include input arguments and Dynare version2020-09-21T10:32:05ZJohannes Pfeifer Start diary earlier to include input arguments and Dynare versionCurrently, the diary only starts after the version and the input arguments have been printed. That way, important information is missing when calling a mod-file with command-line switches.Currently, the diary only starts after the version and the input arguments have been printed. That way, important information is missing when calling a mod-file with command-line switches.4.7https://git.dynare.org/Dynare/dynare/-/issues/1742Fix reported problems in extended path2020-09-10T12:25:41ZJohannes Pfeifer Fix reported problems in extended pathSee https://forum.dynare.org/t/extended-path-bytecode/16577See https://forum.dynare.org/t/extended-path-bytecode/165774.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1741Linear algorithm for perfect foresight is buggy when there are lagged exogeno...2020-09-04T14:07:56ZMichelJuillardLinear algorithm for perfect foresight is buggy when there are lagged exogenous variables in the modelThe algorithm implemented in ``sim1_linear.m`` is wrong when there are lagged exogenous variables because it relies on the derivatives of exogenous variables that are themselves wrong because of the issue reported in #1731The algorithm implemented in ``sim1_linear.m`` is wrong when there are lagged exogenous variables because it relies on the derivatives of exogenous variables that are themselves wrong because of the issue reported in #17314.7https://git.dynare.org/Dynare/dynare/-/issues/1740Investigate MS-BVAR problems on Windows2020-08-27T08:30:31ZJohannes Pfeifer Investigate MS-BVAR problems on WindowsThe `test_ms_variances.mod` fails in `4.6.1` with
```
Unable to create the starting point data file est_csminwel_test_ms_variances.out in csminwel.c!
Error in MS-SBVAR MEX file.
```The `test_ms_variances.mod` fails in `4.6.1` with
```
Unable to create the starting point data file est_csminwel_test_ms_variances.out in csminwel.c!
Error in MS-SBVAR MEX file.
```4.7https://git.dynare.org/Dynare/dynare/-/issues/1739Investigate parallel issues2020-07-13T14:00:20ZJohannes Pfeifer Investigate parallel issuesSee https://forum.dynare.org/t/parallel-estimation-mcmc-diagnostics-issue/16228/4See https://forum.dynare.org/t/parallel-estimation-mcmc-diagnostics-issue/16228/44.7https://git.dynare.org/Dynare/dynare/-/issues/1738Publication-quality plots2020-07-15T10:44:06ZWilli Mutschlerwilli@mutschler.euPublication-quality plotsMatlab's capabilities to produce plots are very low-level and I usually find that using e.g. R's ggplot2 function gives "better" looking figures. I recently came across the following project which basically ports ggplot2 to matlab and is under the MIT license:
https://github.com/piermorel/gramm
What do @all think, would it be good to use this and provide publication-quality plots in Dynare?Matlab's capabilities to produce plots are very low-level and I usually find that using e.g. R's ggplot2 function gives "better" looking figures. I recently came across the following project which basically ports ggplot2 to matlab and is under the MIT license:
https://github.com/piermorel/gramm
What do @all think, would it be good to use this and provide publication-quality plots in Dynare?https://git.dynare.org/Dynare/dynare/-/issues/1737Provide disclyap_fast.m as a mex-file2020-07-30T15:13:17ZJohannes Pfeifer Provide disclyap_fast.m as a mex-filePreliminary testing with the Matlab Coder in C++ indicated significant speed gains (factor 3 for a 54 by 54 matrix). Useful as there may be thousands of calls in the context of GMM.
We currently do not use the `chol`-check anywhere. So may leave it out and only code the main loop.Preliminary testing with the Matlab Coder in C++ indicated significant speed gains (factor 3 for a 54 by 54 matrix). Useful as there may be thousands of calls in the context of GMM.
We currently do not use the `chol`-check anywhere. So may leave it out and only code the main loop.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1736Display of simulated moments: introduce cutoff for 0 variables2020-09-03T14:45:13ZJohannes Pfeifer Display of simulated moments: introduce cutoff for 0 variablesSee the problem in https://forum.dynare.org/t/question-on-ramsey-example-mod/16113See the problem in https://forum.dynare.org/t/question-on-ramsey-example-mod/16113https://git.dynare.org/Dynare/dynare/-/issues/1735Change treatment of jnl-file of k_order_perturbation2020-06-30T14:07:41ZJohannes Pfeifer Change treatment of jnl-file of k_order_perturbationDisable the writing of the file to the hard-disk by default. Implement an additional input argument so that options_.debug triggers writing this file.Disable the writing of the file to the hard-disk by default. Implement an additional input argument so that options_.debug triggers writing this file.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1734Finish nonlinear prior restrictions2020-06-22T10:25:28ZJohannes Pfeifer Finish nonlinear prior restrictionsSee https://git.dynare.org/Dynare/dynare/-/commit/0efcef8f20c549c1484ce56c8986bc4c24d5292aSee https://git.dynare.org/Dynare/dynare/-/commit/0efcef8f20c549c1484ce56c8986bc4c24d5292a4.7https://git.dynare.org/Dynare/dynare/-/issues/1733Fix identification issues around steady state file2020-06-22T08:35:36ZJohannes Pfeifer Fix identification issues around steady state fileThe issue popped up in https://forum.dynare.org/t/mode-check-plots-with-flat-lines/16020/13 with the attached files. From what I can see, the issue is parameters being updated in the steady state file. Identification in `4.7` seems unable to handle this. If I am not mistaken (@rattoma should know better), this is a regression as in the past, we resorted to simulation instead of theoretical derivatives which are now unavailable.
[Model.mod](/uploads/7416c13b9a736cfe8133774f9342b9bd/Model.mod)
[SOEMData.xlsx](/uploads/9121d21da0eed219d98bac015f97d9ec/SOEMData.xlsx)
[Model_steadystate.m](/uploads/914342354a7271f21b18cdb9130e03ad/Model_steadystate.m)The issue popped up in https://forum.dynare.org/t/mode-check-plots-with-flat-lines/16020/13 with the attached files. From what I can see, the issue is parameters being updated in the steady state file. Identification in `4.7` seems unable to handle this. If I am not mistaken (@rattoma should know better), this is a regression as in the past, we resorted to simulation instead of theoretical derivatives which are now unavailable.
[Model.mod](/uploads/7416c13b9a736cfe8133774f9342b9bd/Model.mod)
[SOEMData.xlsx](/uploads/9121d21da0eed219d98bac015f97d9ec/SOEMData.xlsx)
[Model_steadystate.m](/uploads/914342354a7271f21b18cdb9130e03ad/Model_steadystate.m)4.7https://git.dynare.org/Dynare/dynare/-/issues/1732Improve debugging options for perfect foresight2020-06-10T06:15:36ZJohannes Pfeifer Improve debugging options for perfect foresightWe occasionally have issues with singular Jacobians as in https://forum.dynare.org/t/blanchard-conditions-in-stochastic-and-deterministic-models/15980
It would be good to have a debugging options that would point to the culprit for e.g. a row or column of zeros. Maybe we could add this to `model_diagnostics`.
[ADS_NE.mod](/uploads/93a8991fbd2cfd3eface2eb12d9a745f/ADS_NE.mod)We occasionally have issues with singular Jacobians as in https://forum.dynare.org/t/blanchard-conditions-in-stochastic-and-deterministic-models/15980
It would be good to have a debugging options that would point to the culprit for e.g. a row or column of zeros. Maybe we could add this to `model_diagnostics`.
[ADS_NE.mod](/uploads/93a8991fbd2cfd3eface2eb12d9a745f/ADS_NE.mod)https://git.dynare.org/Dynare/dynare/-/issues/1731Error in derivatives of perfect foresight models with leaded or lagged exogen...2020-09-04T14:09:13ZMichelJuillardError in derivatives of perfect foresight models with leaded or lagged exogenous variablesA perfect foresight model with leads and lags in exogenous variables produces wrong derivative file ``dynamic_g1.m`` such as:
```
...
g1 = zeros(6, 12);
g1(1,8)=(-params(1));
g1(1,8)=1;
...
```
Here is ``test_0.mod``:
[test_o.mod](/uploads/27569e4244c8152ea98b9f1b7b48c21c/test_o.mod)
The issue occurs in 4.6 and in the unstable version.A perfect foresight model with leads and lags in exogenous variables produces wrong derivative file ``dynamic_g1.m`` such as:
```
...
g1 = zeros(6, 12);
g1(1,8)=(-params(1));
g1(1,8)=1;
...
```
Here is ``test_0.mod``:
[test_o.mod](/uploads/27569e4244c8152ea98b9f1b7b48c21c/test_o.mod)
The issue occurs in 4.6 and in the unstable version.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1730Consider saving results using -v7.3 flag2020-06-15T10:29:17ZJohannes Pfeifer Consider saving results using -v7.3 flagWe may want to consider saving the results of a Dynare run using the `-v7.3` flag, which available after Matlab R2006b. That would help getting around occasional issues with the 2GB file limit otherwise present.We may want to consider saving the results of a Dynare run using the `-v7.3` flag, which available after Matlab R2006b. That would help getting around occasional issues with the 2GB file limit otherwise present.https://git.dynare.org/Dynare/dynare/-/issues/1729Suggestion: Provide unstable builds of current major version branch (e.g. 4.6...2020-06-05T16:58:28ZTom HoldenSuggestion: Provide unstable builds of current major version branch (e.g. 4.6 at present) as well as builds of the master branchIt would be good if as well as providing unstable builds of the master branch, unstable builds of the current major version branch were also provided (e.g. the 4.6 branch at present).
While people can of course compile this themselves, in practice this is quite onerous.It would be good if as well as providing unstable builds of the master branch, unstable builds of the current major version branch were also provided (e.g. the 4.6 branch at present).
While people can of course compile this themselves, in practice this is quite onerous.https://git.dynare.org/Dynare/dynare/-/issues/1728Improvements to make install rule2020-07-28T08:34:19ZSébastien VillemotImprovements to make install ruleCurrently the preprocessor is installed at two places: `${prefix}/lib/dynare/matlab/preprocessorNN/` and `${prefix}/bin`. The former should probably be made a symlink to the latter.
By the way, we could rename the preprocessor binary to a better name.
Moreover, docs should be installed under `${prefix}/share/doc/dynare/`.Currently the preprocessor is installed at two places: `${prefix}/lib/dynare/matlab/preprocessorNN/` and `${prefix}/bin`. The former should probably be made a symlink to the latter.
By the way, we could rename the preprocessor binary to a better name.
Moreover, docs should be installed under `${prefix}/share/doc/dynare/`.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1727Blocks of type "evaluate backward" are not correctly simulated2020-09-23T13:29:57ZSébastien VillemotBlocks of type "evaluate backward" are not correctly simulatedThe testsuite does not currently have a block of this type (which typically appears when there is a purely forward variable).
Tasks:
- [x] Fix the bug in MATLAB mode
- [x] Fix the bug in bytecode
- [x] Add a test in the testsuite
The test can simply consist of adding an equation to `block_bytecode/ls2003.mod`, which would read as: `pure_forward = 0.9*pure_forward(+1) + e_pure_forward;`. The `e_pure_forward` variable needs to be shocked, preferably in the end of the simulation sample.The testsuite does not currently have a block of this type (which typically appears when there is a purely forward variable).
Tasks:
- [x] Fix the bug in MATLAB mode
- [x] Fix the bug in bytecode
- [x] Add a test in the testsuite
The test can simply consist of adding an equation to `block_bytecode/ls2003.mod`, which would read as: `pure_forward = 0.9*pure_forward(+1) + e_pure_forward;`. The `e_pure_forward` variable needs to be shocked, preferably in the end of the simulation sample.4.7Sébastien VillemotSébastien Villemot