dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-07-20T10:58:59Zhttps://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 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.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 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.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 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.8https://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/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, which is much more easier to do than in MATLAB.
Initially discussed in #1648Implement 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-07-23T11:13:16ZJohannes 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:
- [ ] 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.
- [ ] 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
- [ ] Documenting the recent changesSupersedes 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:
- [ ] 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.
- [ ] 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
- [ ] Documenting the recent changes4.7Normann 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 ee3971ad6364910851ff06da9729d9b4a084ca4b).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 Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1674Modification to shock_decomposition and plot_decomposition interfaces to incl...2021-07-21T15:18:53ZDóra Kocsiskocsis.doralinda@gmail.comModification to shock_decomposition and plot_decomposition interfaces to include flexibility with datesInclude the following options for dates when shock_decomposition is triggered:
* date of the start of the decomposition, default: start of the estimation sample (some people may want to start the decomposition with the smoothed value at the end of the sample). Proposed option name: `init_date = INTEGER`.
* date of the start of the graph, default: start of the estimation sample. Proposed option name: `graph_init_date = INTEGER`.Include the following options for dates when shock_decomposition is triggered:
* date of the start of the decomposition, default: start of the estimation sample (some people may want to start the decomposition with the smoothed value at the end of the sample). Proposed option name: `init_date = INTEGER`.
* date of the start of the graph, default: start of the estimation sample. Proposed option name: `graph_init_date = INTEGER`.4.8https://git.dynare.org/Dynare/dynare/-/issues/1665Implement bridge sampler for computing marginal data density2021-07-20T10:57:50ZJohannes Pfeifer Implement bridge sampler for computing marginal data density4.8https://git.dynare.org/Dynare/dynare/-/issues/1664Implement option to use LMMCP for steady state computation2021-06-22T10:31:02ZMichelJuillardImplement option to use LMMCP for steady state computationIntroducing mixed complementarity problems in steady state computation may be useful to exclude parts of the definition space where no solution exists. It may also help when one doesn't know whether an occasionally binding constraints bites at the steady state or not, depending on the value of the parameters.Introducing mixed complementarity problems in steady state computation may be useful to exclude parts of the definition space where no solution exists. It may also help when one doesn't know whether an occasionally binding constraints bites at the steady state or not, depending on the value of the parameters.https://git.dynare.org/Dynare/dynare/-/issues/1663datafile option in perfect_foresight_setup: incomplete documentation and not ...2020-11-13T14:22:21ZMichelJuillarddatafile option in perfect_foresight_setup: incomplete documentation and not flexible enoughthe datafile option in perfect_foresight solver requires a text file without variable names, variables being order in order of VAR statement. The file name must end with ``_endo.dat``.
- [x] make loading data for guess value more flexible
- [x] honor INITVAL_FILE command or deprecate it
- [ ] make possible to use guess values with simul_backward-modelthe datafile option in perfect_foresight solver requires a text file without variable names, variables being order in order of VAR statement. The file name must end with ``_endo.dat``.
- [x] make loading data for guess value more flexible
- [x] honor INITVAL_FILE command or deprecate it
- [ ] make possible to use guess values with simul_backward-model4.7https://git.dynare.org/Dynare/dynare/-/issues/1660Update documentation of dseries2021-01-21T15:53:26ZSébastien VillemotUpdate documentation of dseriesSince dseries have been substantially rewritten since 4.5, the documentation in the reference needs to be updated.Since dseries have been substantially rewritten since 4.5, the documentation in the reference needs to be updated.4.7Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1658Write a howto on forecasting2019-09-20T13:06:55ZSébastien VillemotWrite a howto on forecastinghttps://git.dynare.org/Dynare/dynare/-/issues/1657add shock decomposition for forecasts done after estimation2021-01-21T15:56:53ZSébastien Villemotadd shock decomposition for forecasts done after estimation@MichelJuillard has some preliminary codes.@MichelJuillard has some preliminary codes.4.8Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1643Implement pruning at order>32021-07-22T12:11:36ZJohannes Pfeifer Implement pruning at order>3The algorithm should follow Andreasen et al. (2018) as already implemented in `simult_.m` for orders 2 and 3. Should be done in the C++ routines of `dynare_simul_` as discussed in https://git.dynare.org/Dynare/dynare/commit/1e92e308b9d0301108d18d7256f47655097f20cb#note_8364The algorithm should follow Andreasen et al. (2018) as already implemented in `simult_.m` for orders 2 and 3. Should be done in the C++ routines of `dynare_simul_` as discussed in https://git.dynare.org/Dynare/dynare/commit/1e92e308b9d0301108d18d7256f47655097f20cb#note_83644.8Normann RionNormann Rionhttps://git.dynare.org/Dynare/dynare/-/issues/1611Make dynare_sensitivity compatible with recursive estimation or provide infor...2018-11-08T09:59:51ZJohannes Pfeifer Make dynare_sensitivity compatible with recursive estimation or provide informative errorSee https://forum.dynare.org/t/calculating-rmses/11903 See https://forum.dynare.org/t/calculating-rmses/11903 https://git.dynare.org/Dynare/dynare/-/issues/1605Better document behavior of steady_state operator2018-09-10T12:35:46ZJohannes Pfeifer Better document behavior of steady_state operatorSee https://forum.dynare.org/t/steady-state-command-in-perfect-foresight-simulations/11632/3See https://forum.dynare.org/t/steady-state-command-in-perfect-foresight-simulations/11632/3https://git.dynare.org/Dynare/dynare/-/issues/1603Allow simulation with var_exo_det with stoch_simul2021-07-23T15:08:18ZJohannes Pfeifer Allow simulation with var_exo_det with stoch_simulSee https://forum.dynare.org/t/varexo-det-to-simulate-random-shocks-during-a-predetermined-period/11637
It seems there is at least one call to `make_ex_` missingSee https://forum.dynare.org/t/varexo-det-to-simulate-random-shocks-during-a-predetermined-period/11637
It seems there is at least one call to `make_ex_` missing4.8https://git.dynare.org/Dynare/dynare/-/issues/1597Accept UTF-8 in .mod file2020-05-07T17:45:03ZHoutan BastaniAccept UTF-8 in .mod filehttps://git.dynare.org/Dynare/dynare/-/issues/1596add maximum lag info by variable2020-05-07T17:45:37ZHoutan Bastaniadd maximum lag info by variable```
M_.maximum_endo_lag_by_var = [ ... ];
M_.maximum_exo_lag_by_var = [ ... ];
```
Where the vectors are the length of `M_.orig_endo_nbr````
M_.maximum_endo_lag_by_var = [ ... ];
M_.maximum_exo_lag_by_var = [ ... ];
```
Where the vectors are the length of `M_.orig_endo_nbr`