dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-09-20T09:47:15Zhttps://git.dynare.org/Dynare/dynare/-/issues/1774Manually verify analytic derivatives before major relases2021-09-20T09:47:15ZJohannes Pfeifer Manually verify analytic derivatives before major relasesUsing `optim = ('DerivativeCheck', 'on','FiniteDifferenceType','central')`
allows checking the correctness of analytic Jacobians for `analytic_derivatives/fs2000_analytic_derivation.mod` and `method_of_moments\RBC\RBC_MoM_GMM_gradient_op...Using `optim = ('DerivativeCheck', 'on','FiniteDifferenceType','central')`
allows checking the correctness of analytic Jacobians for `analytic_derivatives/fs2000_analytic_derivation.mod` and `method_of_moments\RBC\RBC_MoM_GMM_gradient_optim.mod`. These tests would fail as Matlab does not allow setting the tolerance lower than the default 1e-6, while we are at 1e-5. But we should nevertheless manually check whether we are within a reasonable tolerance.4.8https://git.dynare.org/Dynare/dynare/-/issues/1773Improve performance of local_state_space_iteration_*2021-08-30T10:56:58ZSébastien VillemotImprove performance of local_state_space_iteration_*The `local_state_space_iteration_2` MEX is much faster than `local_state_space_iteration_k` at order 2.
The solution is to fully rewrite it without using Dynare++ codebase (and by the way, do that in Fortran). This will be done via http...The `local_state_space_iteration_2` MEX is much faster than `local_state_space_iteration_k` at order 2.
The solution is to fully rewrite it without using Dynare++ codebase (and by the way, do that in Fortran). This will be done via https://git.dynare.org/Dynare/dynare/-/issues/1802
Related to #1768 and #1643.4.8https://git.dynare.org/Dynare/dynare/-/issues/1766Allow for Herbst-Schorfheide and DS-MH sampler2021-07-21T21:12:52ZJohannes Pfeifer Allow for Herbst-Schorfheide and DS-MH samplerSee https://forum.dynare.org/t/new-samplers-and-mode-compute-methods/17267/7
First part is done in https://git.dynare.org/Dynare/dynare/-/merge_requests/1884
- [ ] The default options for the samplers need to be added to `default_optio...See https://forum.dynare.org/t/new-samplers-and-mode-compute-methods/17267/7
First part is done in https://git.dynare.org/Dynare/dynare/-/merge_requests/1884
- [ ] The default options for the samplers need to be added to `default_option_values`
- [ ] The two routines currently do not provide any return arguments/output4.8https://git.dynare.org/Dynare/dynare/-/issues/1759Decide whether to drop Windows 7 support2021-03-23T13:48:34ZSébastien VillemotDecide whether to drop Windows 7 supportCurrently, we officially support three versions of Windows: 7, 8.1 and 10.
Mainstream support for Windows 7 expired on 2015, and extended support expired on January 2020.
Until January 2023, Microsoft still provides so-called “Extended...Currently, we officially support three versions of Windows: 7, 8.1 and 10.
Mainstream support for Windows 7 expired on 2015, and extended support expired on January 2020.
Until January 2023, Microsoft still provides so-called “Extended Security Updates”, but this requires a paid subscription (which is probably quite expensive, and thus only accessible to large institutions).
The decision to drop official Dynare support for Windows 7 therefore mostly depends on whether our institutional users have already moved away from Windows 7, or are still postponing the inevitable upgrade.
Note that dropping support for Windows 7 does not mean that Dynare would stop working on that platform (at least until we introduce some breaking change). It simply means that there would be no testing and no guarantee of functionality on that platform.4.8https://git.dynare.org/Dynare/dynare/-/issues/1758Discuss moving all mod-file output to folder `M_.dname`2021-09-23T09:39:16ZJohannes Pfeifer Discuss moving all mod-file output to folder `M_.dname`The discussion in https://git.dynare.org/Dynare/dynare/-/merge_requests/1793 points to a design problem of the generally useful `M_.dname`-option: We still save various output-files like the `_results.mat`-file in the main folder. So the...The discussion in https://git.dynare.org/Dynare/dynare/-/merge_requests/1793 points to a design problem of the generally useful `M_.dname`-option: We still save various output-files like the `_results.mat`-file in the main folder. So the `dname`-saving logic does not fully work. In the long-run, we will move almost all Dynare-generated output to a subfolder of `M_.dname` to get a clean root directory. We have increasingly moved to the direction in the past, e.g. with the $\LaTeX$-files. Two notable exceptions will most probably be
1. `_TeX_binder.tex` due to `\include` only working for subdirectories
2. The `log`-file
3. Potentially the files generated by mode-finders as the user can easily turn them off.
Still to be done:
- [ ] Offer a preprocessor command line option `dname` to set this at the preprocessor-level. This would allow solving the `json`-issue discussed at https://git.dynare.org/Dynare/dynare/-/merge_requests/1793
- [ ] Move the JSON files4.8https://git.dynare.org/Dynare/dynare/-/issues/1746Create a MEX equivalent to minreal from the control toolbx2021-05-03T13:58:40ZSébastien VillemotCreate a MEX equivalent to minreal from the control toolbxSee the comments in `get_minimal_state_representation.m`.See the comments in `get_minimal_state_representation.m`.4.8Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1745Adding support for dates in perfect_foresight_setup2021-05-05T14:32:04ZMichelJuillardAdding 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_f...The 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.8MichelJuillardMichelJuillardhttps://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...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/1721Get rid of oo_.dr.kstate2021-10-25T16:15:30ZSébastien VillemotGet rid of oo_.dr.kstateIn particular, see the discussion in #1653In particular, see the discussion in #16534.8https://git.dynare.org/Dynare/dynare/-/issues/1715Clean root folder of /tests2021-07-22T10:27:26ZJohannes 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.8https://git.dynare.org/Dynare/dynare/-/issues/1709Rework handling of trends including automatic detrending2021-08-19T08:43:04ZFerhatMihoubiRework handling of trends including automatic 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 ...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.4.8https://git.dynare.org/Dynare/dynare/-/issues/1707Macro commands that take no arguments have spurious parentheses appended to t...2021-07-23T15:37:25ZSé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.8https://git.dynare.org/Dynare/dynare/-/issues/1704Update partial information code2021-05-03T13:59:02ZSébastien VillemotUpdate partial information codeFirst version located in https://git.dynare.org/Yang/dynareFirst version located in https://git.dynare.org/Yang/dynare4.8https://git.dynare.org/Dynare/dynare/-/issues/1700Proposal for a generalized solver2021-07-20T10:58:59ZMichelJuillardProposal for a generalized solverModel inversion and deterministic conditional forecast solve the same mathematical problem: solving a (non-)linear system where the identity of the unknown variables change from period to period. I suggest to create a unique function tha...Model inversion and deterministic conditional forecast solve the same mathematical problem: solving a (non-)linear system where the identity of the unknown variables change from period to period. I suggest to create a unique function that would solve such problems.
``general_solver`` would take at least the following arguments:
* y: endogenous variables (matrix)
* x: exogenous variables (matrix) [possible concatenation of exo_det variables to the right]
* model: model (function handle)
* i_endo_flip: flip variables indices in endogenous variables (vector)
* i_exo_flip: flip variables indices in exogenous variables (vector)
### Conventions
1. there are as many endogenous flip variables as exogenenous or exo det variables
1. the endogenous and exogenous flip variables are in the same order (not necessary to be contiguous but may help)
1. given the indices vector of flip variablesm implicit pairs of endogenous/exogenous variables are formed
1. If the observation of an endogenous variable is a NaN, the endogenous variables plays it usual role of endogenous variable
1. If the observation of an endogenous variables is a valid number, the endogenous variable is treated as exogenous and the corresponding flip exogenous variables is treated as endogenous
1. The presence of a NaN for an endogenous variable not declared as a flip variable is an error
1. The corner case of unconditional forecast should be accepted for ease of use
1. The solution is written back in ``y`` and ``x`` irrespective of the actual role of a variable in a given period
### Operations
``general_solver`` dispatches la résolution du nouveau problème selon
1. purely backward linear model
1. purely backward nonlinear model
1. purely forward linear model (if we have the algorithm...)
1. purely forward nonlinear model
1. general linear model
1. general nonlinear model
1. bytecode and or block model
and according to the options selecting a particular algorithm4.8https://git.dynare.org/Dynare/dynare/-/issues/1698Allow checking linearity for perfect foresight models2021-07-22T13:27:44ZJohannes Pfeifer Allow checking linearity for perfect foresight modelsThe linearity check underlying `model(linear)` is based on the Hessian of the model. But we don’t compute the Hessian for a perfect foresight simulation, hence the check is skipped. See line 799 of `preprocessor/src/ModFile.cc`.
That ca...The linearity check underlying `model(linear)` is based on the Hessian of the model. But we don’t compute the Hessian for a perfect foresight simulation, hence the check is skipped. See line 799 of `preprocessor/src/ModFile.cc`.
That can be problematic in case of nonlinearities like a ZLB constraint in an otherwise linear model. The solver assumes that the Jacobian is the same at every period, and the constraint is not enforced.
For very large perfect foresight models, we actually don’t want to put the Hessian in the generated dynamic file, because compiling it can be very time consuming. Hence the fix is not straightforward.
I would suggest to add a way of testing this. One option would be trigger the Hessian computation with a `debug` option or something like this. For example, we could use the already present command line option `debug`.4.8https://git.dynare.org/Dynare/dynare/-/issues/1693Various improvements in Sphinx doc2021-07-23T15:21:51ZHoutan BastaniVarious improvements in Sphinx doc- see if we can use https://pypi.org/project/sphinxcontrib-matlabdomain/ instead of `MatComm` and `MatlabVar` defined in `doc/manual/utils/dynare_dom.py`
- if not, add new domain entry to differentiate between MATLAB commands and MATLA...- see if we can use https://pypi.org/project/sphinxcontrib-matlabdomain/ instead of `MatComm` and `MatlabVar` defined in `doc/manual/utils/dynare_dom.py`
- if not, add new domain entry to differentiate between MATLAB commands and MATLAB functions
- find way to fix output of Matlab Commands so the options conform to the true type used for Dynare Command options
- code block:
- many general problems with highlighting: e.g. `end` is highlighted when it is MATLAB code but the corresponding `for` is not highlighted
- despite being in `doc/manual/utils/dynare_lex.py`, `var` is not highlighted in code blocks
- ideally find a programmatic way to fill `doc/manual/utils/dynare_lex.py` from the `rst` files instead of having to update it by hand4.8https://git.dynare.org/Dynare/dynare/-/issues/1688fix `basic_plan`, `flip_plan` in doc2021-09-09T09:01:53ZHoutan Bastanifix `basic_plan`, `flip_plan` in docThe calling structure for both of these functions runs off the end of the pageThe calling structure for both of these functions runs off the end of the page4.8Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1684New WITH_TREND() operator for epilogue block2021-07-23T12:22:36ZSébastien VillemotNew WITH_TREND() operator for epilogue blockImplement a new operator (something like `WITH_TREND()` that could be used in the epilogue block, and that would add back the trend on the computed variables. In this way, the symbolic manipulations would be done in the preprocessor, whi...Implement a new operator (something like `WITH_TREND()` that could be used in the epilogue block, and that would add back the trend on the computed variables. In this way, the symbolic manipulations would be done in the preprocessor, which is much more easier to do than in MATLAB.
Initially discussed in #16484.8https://git.dynare.org/Dynare/dynare/-/issues/1680Adapt evaluate_planner_objective.m to higher order and perfect foresight2021-09-16T16:48:40ZJohannes Pfeifer Adapt evaluate_planner_objective.m to higher order and perfect foresightSupersedes https://git.dynare.org/Dynare/dynare/issues/564 and is related to https://git.dynare.org/Dynare/dynare/issues/1678
See also https://forum.dynare.org/t/evaluate-planner-objective-in-non-linear-model/15492
Remaining:
- [x] fixi...Supersedes https://git.dynare.org/Dynare/dynare/issues/564 and is related to https://git.dynare.org/Dynare/dynare/issues/1678
See also https://forum.dynare.org/t/evaluate-planner-objective-in-non-linear-model/15492
Remaining:
- [x] fixing or documenting the regression in behavior introduced in e880d1bc. In contrast to previous behavior `histval` will be ignored. `planner_objective_value` now returns conditional and unconditional welfare instead of welfare for different values of the Lagrange multiplier. (done in !1923)
- [x] the question of an interface for setting the initial condition (https://git.dynare.org/Dynare/preprocessor/-/issues/64)
- [ ] Adding higher order results to `evaluate_planner_objective`
- [ ] Compute unconditional welfare at order>2
- [x] Documenting the recent changes4.8Normann RionNormann Rionhttps://git.dynare.org/Dynare/dynare/-/issues/1675Migrate to Dragonfly parallel toolkit2021-05-06T14:33:48ZSébastien VillemotMigrate to Dragonfly parallel toolkitThe embedded parallel toolkit should be replaced by the [Dragonfly](https://github.com/DragonflyTeam/dragonfly) toolkit.
A branch called `dragonfly` has been created, with the toolkit under `matlab/modules/dragonfly` (see ee3971ad636491...The embedded parallel toolkit should be replaced by the [Dragonfly](https://github.com/DragonflyTeam/dragonfly) toolkit.
A branch called `dragonfly` has been created, with the toolkit under `matlab/modules/dragonfly` (see ee3971ad6364910851ff06da9729d9b4a084ca4b).4.8Marco RattoMarco Ratto