dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-07-13T14:00:20Zhttps://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/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/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-06-15T11:01:36ZMichelJuillardError 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.Sé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/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-05-26T15:05:02ZSé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
- [ ] Fix the bug in bytecode
- [ ] 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
- [ ] Fix the bug in bytecode
- [ ] 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 Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1726Option mfs=3 gives wrong result2020-05-20T10:26:56ZSébastien VillemotOption mfs=3 gives wrong resultThe `mfs=3` option of the `model` keyword gives wrong results.
This can for example be verified by adding `mfs=3` to `deterministic/lola_solve_one_boundary.mod`.
Once this is fixed, we should add tests that check that all the possible values of `mfs` give the same result on a given model.
The option `mfs` is also broken in version 4.6.1. Several other problems with `mfs` have already be fixed in the 4.6 branch, but the present issue is still unfixed.The `mfs=3` option of the `model` keyword gives wrong results.
This can for example be verified by adding `mfs=3` to `deterministic/lola_solve_one_boundary.mod`.
Once this is fixed, we should add tests that check that all the possible values of `mfs` give the same result on a given model.
The option `mfs` is also broken in version 4.6.1. Several other problems with `mfs` have already be fixed in the 4.6 branch, but the present issue is still unfixed.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1725Better interface for mfs option2020-05-20T10:14:37ZSébastien VillemotBetter interface for mfs optionThe `mfs` option of the `model` keyword, that enables an additional optimization in the block decomposition, has an unfriendly interface. It currently accepts an integer, while it would be more natural to use keywords (the challenge is to choose keywords that reflect the natural ordering of the possible values).
The old integer values would still have to be kept for backward compatibility.
From an implementation point of view, the different values should be stored as an enum class in the preprocessor.The `mfs` option of the `model` keyword, that enables an additional optimization in the block decomposition, has an unfriendly interface. It currently accepts an integer, while it would be more natural to use keywords (the challenge is to choose keywords that reflect the natural ordering of the possible values).
The old integer values would still have to be kept for backward compatibility.
From an implementation point of view, the different values should be stored as an enum class in the preprocessor.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1721Get rid of oo_.dr.kstate2020-05-04T16:22:55ZSébastien VillemotGet rid of oo_.dr.kstateIn particular, see the discussion in #1653In particular, see the discussion in #16534.7https://git.dynare.org/Dynare/dynare/-/issues/1720lmmcp does not work with purely forward or backward models2020-04-11T19:23:48ZJohannes Pfeifer lmmcp does not work with purely forward or backward modelsIn this case, the MCP-tags are ignored due to `perfect_foresight_solver_core` having checks like `if M_.maximum_endo_lead == 0` and immediately calling `sim1_purely_backward` and `sim1_purely_forward`, which do not account for the constraints. A current workaround is using dummy equations.In this case, the MCP-tags are ignored due to `perfect_foresight_solver_core` having checks like `if M_.maximum_endo_lead == 0` and immediately calling `sim1_purely_backward` and `sim1_purely_forward`, which do not account for the constraints. A current workaround is using dummy equations.4.7https://git.dynare.org/Dynare/dynare/-/issues/1718Auxillary particle filter --- number_of_state_variables is undefined2020-03-30T10:09:49ZArtur ZmanovskiiAuxillary particle filter --- number_of_state_variables is undefinedIn `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`number_of_state_variables` --- at lines 137--138) and causes error.In `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`number_of_state_variables` --- at lines 137--138) and causes error.4.7Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://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/1715Clean root folder of /tests2020-03-07T17:21:34ZJohannes Pfeifer Clean root folder of /testsAll integration tests should be in subfolders. The current structure is a messAll integration tests should be in subfolders. The current structure is a mess4.7https://git.dynare.org/Dynare/dynare/-/issues/1709Automatic detrending2020-03-06T17:35:41ZFerhatMihoubiAutomatic detrendingFor the moment the deterministic or stochastic trends have to be declared using the trend_var (or log_trend_var) commands and the option deflator (or log_deflator) in var command to declare the trended variables.
The purpose of the new feature is to find and remove automatically the trends. To do so, the proposal is to add :
- an option in var command to indicate if the variable is expressed in logarithm or not (the default being not in logarithm). For instance *var(log) list of variables*.
- a command that will add to all endogenous variables a growth factor (additive or multiplicative depending on the previously declared status) and the equations that put in relation all the growth factors to theirs endogenous variables. This step should be performed in the preprocessor to produce a new dynamic model containing all the endogenous variables and the growth factor associated to all the endogenous variables.
- during the execution the complete new dynamic model should be solved to compute the growth factors and the steady state values of the endogenous variables.
This command could be *detrend* for instance.For the moment the deterministic or stochastic trends have to be declared using the trend_var (or log_trend_var) commands and the option deflator (or log_deflator) in var command to declare the trended variables.
The purpose of the new feature is to find and remove automatically the trends. To do so, the proposal is to add :
- an option in var command to indicate if the variable is expressed in logarithm or not (the default being not in logarithm). For instance *var(log) list of variables*.
- a command that will add to all endogenous variables a growth factor (additive or multiplicative depending on the previously declared status) and the equations that put in relation all the growth factors to theirs endogenous variables. This step should be performed in the preprocessor to produce a new dynamic model containing all the endogenous variables and the growth factor associated to all the endogenous variables.
- during the execution the complete new dynamic model should be solved to compute the growth factors and the steady state values of the endogenous variables.
This command could be *detrend* for instance.https://git.dynare.org/Dynare/dynare/-/issues/1707Macro commands that take no arguments have spurious parentheses appended to t...2020-05-07T17:43:51ZSébastien VillemotMacro commands that take no arguments have spurious parentheses appended to their synopsisSee for example the definition of `@#else`, `@#endif`, `@#endfor`, `@#echomacrovars` in the reference manual.See for example the definition of `@#else`, `@#endif`, `@#endfor`, `@#echomacrovars` in the reference manual.4.7https://git.dynare.org/Dynare/dynare/-/issues/1704Update partial information code2020-03-02T16:14:50ZSébastien VillemotUpdate partial information codeFirst version located in https://git.dynare.org/Yang/dynareFirst version located in https://git.dynare.org/Yang/dynare4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1703det_cond_forecast() depends on oo_.dr.state_var but this is not always available2020-02-11T10:08:29ZMichelJuillarddet_cond_forecast() depends on oo_.dr.state_var but this is not always available``det_cond_forecast()`` depends on ``oo_.dr.state_var`` but this variable is computed by ``dyn_first_order_solver``. So it isn't available for a purely backward or purely forward model``det_cond_forecast()`` depends on ``oo_.dr.state_var`` but this variable is computed by ``dyn_first_order_solver``. So it isn't available for a purely backward or purely forward model4.7MichelJuillardMichelJuillard