dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-03-02T16:14:50Zhttps://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.7MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1702det_cond_forecast() argument checking is broken2020-02-11T09:44:04ZMichelJuillarddet_cond_forecast() argument checking is brokenIf one calls det_cond_forecast with two arguments only as in the manual example, the function fails with error
```
impossible case
```
that is triggered near line 208If one calls det_cond_forecast with two arguments only as in the manual example, the function fails with error
```
impossible case
```
that is triggered near line 2084.7MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1701det_conditional_forecast doesn't set set options_.qz_criterium2020-02-03T17:37:21ZMichelJuillarddet_conditional_forecast doesn't set set options_.qz_criteriumWhen ``det_conditional_forecast`` is used by itself in a *.mod file as in the example of the manual options_.qz_criterium isn't set.
We should have
```
options_.qz_criterium = 1+1e-6;
```
at the beginning of the functionWhen ``det_conditional_forecast`` is used by itself in a *.mod file as in the example of the manual options_.qz_criterium isn't set.
We should have
```
options_.qz_criterium = 1+1e-6;
```
at the beginning of the function4.6https://git.dynare.org/Dynare/dynare/-/issues/1700Proposal for a generalized solver2020-01-30T09:53:09ZMichelJuillardProposal 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 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 algorithmModel 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.7https://git.dynare.org/Dynare/dynare/-/issues/1699Welfare under optimal discretionary policy not computed2020-01-30T14:50:04ZSébastien VillemotWelfare under optimal discretionary policy not computedAt least with `dennis_1.mod` and `Gali_discretion.mod` from `tests/discretionary_policy/`, the welfare (as stored in `oo_.planner_objective_value`) is a `NaN`. This is a regression from 4.5.
Unfortunately, the test at the end of `Gali_discretion.mod` did not catch the problem, because of the specific evaluation rules for `NaN`. This should also be fixed with some call to `isnan()`.At least with `dennis_1.mod` and `Gali_discretion.mod` from `tests/discretionary_policy/`, the welfare (as stored in `oo_.planner_objective_value`) is a `NaN`. This is a regression from 4.5.
Unfortunately, the test at the end of `Gali_discretion.mod` did not catch the problem, because of the specific evaluation rules for `NaN`. This should also be fixed with some call to `isnan()`.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1698Allow checking linearity for perfect foresight models2020-02-14T15:05:47ZJohannes 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 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`.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.7https://git.dynare.org/Dynare/dynare/-/issues/1697Regression in LMMCP perfect foresight solver2020-03-30T12:25:19ZSébastien VillemotRegression in LMMCP perfect foresight solverThe simulation in `tests/lmmcp/rbcii.mod` fails to converge. The same file works with 4.5.
Once this is fixed, a check that convergence has indeed been obtained should be added, so that regressions may be detected earlier in the future.The simulation in `tests/lmmcp/rbcii.mod` fails to converge. The same file works with 4.5.
Once this is fixed, a check that convergence has indeed been obtained should be added, so that regressions may be detected earlier in the future.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1696fix parsing of user-provided command line arguments2020-02-11T17:15:49ZHoutan Bastanifix parsing of user-provided command line argumentsMatlab is actually quite good about keeping user-provided arguments together. See:
```
>> dynare example1 '-DA="nthn thnth"' -DB=[1,2, .3] -DB=( oe )
-DA="nthn thnth"
-DB=[1,2, .3]
-DB=( oe )
```
The output above comes from simply printing the arguments of `varargin`.
We should be able to thus simply add single quotes around every user-provided argument in `dynare.m` and pass these directly to the preprocessor for processing. We'd then require that all strings be double-quoted and could potentially even handle macro expressions (not just base values) in `-D` arguments.Matlab is actually quite good about keeping user-provided arguments together. See:
```
>> dynare example1 '-DA="nthn thnth"' -DB=[1,2, .3] -DB=( oe )
-DA="nthn thnth"
-DB=[1,2, .3]
-DB=( oe )
```
The output above comes from simply printing the arguments of `varargin`.
We should be able to thus simply add single quotes around every user-provided argument in `dynare.m` and pass these directly to the preprocessor for processing. We'd then require that all strings be double-quoted and could potentially even handle macro expressions (not just base values) in `-D` arguments.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1695Calib_Smoother options specify sheet and range2020-01-13T17:40:52ZCamilo MarchesiniCalib_Smoother options specify sheet and range```calib_smoother``` currently does not support options related to 'sheet' and 'range' of the Excel spreadsheet. However, these options can be included in the ```estimation``` call. It could be useful to include them also in the call to ```calib_smoother``` .
```calib_smoother``` currently does not support options related to 'sheet' and 'range' of the Excel spreadsheet. However, these options can be included in the ```estimation``` call. It could be useful to include them also in the call to ```calib_smoother``` .
4.6https://git.dynare.org/Dynare/dynare/-/issues/1694Identification tests fail for old matlab2020-01-24T17:25:41ZWilli Mutschlerwilli@mutschler.euIdentification tests fail for old matlabSome identification tests fail under MATLAB R2009b, see https://git.dynare.org/Dynare/dynare/-/jobs/12770. Some functions need to be replaced.Some identification tests fail under MATLAB R2009b, see https://git.dynare.org/Dynare/dynare/-/jobs/12770. Some functions need to be replaced.4.6Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1693Various improvements in Sphinx doc2020-01-08T16:24:40ZHoutan 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 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 hand- 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.7https://git.dynare.org/Dynare/dynare/-/issues/1692Update doc for dynasave and dynatype2020-01-06T10:05:46ZHoutan BastaniUpdate doc for dynasave and dynatypeSplitting up #1691, update the doc for 4.6 and leave the other changes for 4.7Splitting up #1691, update the doc for 4.6 and leave the other changes for 4.74.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1691Allow dynasave and dynatype to also save simulated exogenous variables2020-01-06T13:59:31ZJohannes Pfeifer Allow dynasave and dynatype to also save simulated exogenous variablesThe documentation does not state that this is not allowed. We would need to
* [x] Adjust the Matlab code
* [ ] Make the documentation more explicit
* [x] Allow for the `var_list_` to accept exogenousThe documentation does not state that this is not allowed. We would need to
* [x] Adjust the Matlab code
* [ ] Make the documentation more explicit
* [x] Allow for the `var_list_` to accept exogenous4.6https://git.dynare.org/Dynare/dynare/-/issues/1690Return an error if nonlinear filters are used with trends or prefilter2020-01-13T17:40:52ZStéphane Adjemianstepan@adjemian.euReturn an error if nonlinear filters are used with trends or prefilterSee discussion [here](https://git.dynare.org/Dynare/dynare/commit/76e3c6ca687dbbb55f5e8b47cc8a613b039d80ed#note_10148).See discussion [here](https://git.dynare.org/Dynare/dynare/commit/76e3c6ca687dbbb55f5e8b47cc8a613b039d80ed#note_10148).4.6Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1689Clarify licensing information for identification stuff2020-01-24T14:41:20ZSébastien VillemotClarify licensing information for identification stuffSee !1689
The information should be added in the corresponding headers, and in `license.txt`See !1689
The information should be added in the corresponding headers, and in `license.txt`4.6Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1688fix `basic_plan`, `flip_plan` in doc2020-01-28T14:01:41ZHoutan 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.7Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1687Interface and documentation for new shock decomposition functionalities2020-01-22T17:18:39ZSébastien VillemotInterface and documentation for new shock decomposition functionalitiesImplement the preprocessor changes needed for !1655.
The test `tests/shock_decomposition/ls2003_plot.mod` will need to be adapted for the new `squeeze_shock_decomposition` command.
Also add the related documentation.Implement the preprocessor changes needed for !1655.
The test `tests/shock_decomposition/ls2003_plot.mod` will need to be adapted for the new `squeeze_shock_decomposition` command.
Also add the related documentation.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1686Add interface to set LaTeX-name of optimal_policy_discount_factor2019-12-18T16:46:52ZJohannes Pfeifer Add interface to set LaTeX-name of optimal_policy_discount_factorI would propose an option `planner_discount_latex_name` to `ramsey_model` that takes a string and sets `M_.param_names_tex{strmatch('optimal_policy_discount_factor',M_.param_names,'exact')}` as well as the internal field in the preprocessor output used for the `write_latex_*` commands. Unfortunately, this needs to be a LaTeX string that can contain a backslash. If the parser cannot easily handle this, we should not implement it.I would propose an option `planner_discount_latex_name` to `ramsey_model` that takes a string and sets `M_.param_names_tex{strmatch('optimal_policy_discount_factor',M_.param_names,'exact')}` as well as the internal field in the preprocessor output used for the `write_latex_*` commands. Unfortunately, this needs to be a LaTeX string that can contain a backslash. If the parser cannot easily handle this, we should not implement it.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1685Fix write_latex_dynamic_model(write_equation_tags) for ramsey_model2020-01-06T17:33:31ZJohannes Pfeifer Fix write_latex_dynamic_model(write_equation_tags) for ramsey_modelWhen using `ramsey_model`, the `M_.ramsey_eq_nbr` planner FOCs are written before the `M_.orig_eq_nbr` private sector FOCs for which the equation tags have been provided. But the equation tags are printed for the first `M_.orig_eq_nbr` equations, not for the `M_.ramsey_eq_nbr+1:M_.eq_nbr` ones.When using `ramsey_model`, the `M_.ramsey_eq_nbr` planner FOCs are written before the `M_.orig_eq_nbr` private sector FOCs for which the equation tags have been provided. But the equation tags are printed for the first `M_.orig_eq_nbr` equations, not for the `M_.ramsey_eq_nbr+1:M_.eq_nbr` ones.4.6Sébastien VillemotSébastien Villemot