dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-05-04T09:21:20Zhttps://git.dynare.org/Dynare/dynare/-/issues/1725Better interface for mfs option2021-05-04T09:21:20ZSé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 t...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.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1782Fix model_local_variable command2021-04-20T12:06:37ZJohannes PfeiferFix model_local_variable commandThe file [SW2007_4Forum.mod](/uploads/331476d7971f9497341297d7ee97f238/SW2007_4Forum.mod)
returns
`terminate called after throwing an instance of 'DataTree::UnknownLocalVariableException'`
See also https://forum.dynare.org/t/tex-output...The file [SW2007_4Forum.mod](/uploads/331476d7971f9497341297d7ee97f238/SW2007_4Forum.mod)
returns
`terminate called after throwing an instance of 'DataTree::UnknownLocalVariableException'`
See also https://forum.dynare.org/t/tex-output-unwanted-subscript-t/160725.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1732Improve debugging options for perfect foresight2021-03-25T16:08:29ZJohannes PfeiferImprove 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. ...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`. Two test cases are attached, one for `sim1` and one for `sim1_linear`.
[ADS_NE.mod](/uploads/93a8991fbd2cfd3eface2eb12d9a745f/ADS_NE.mod)
[code_14_march.mod](/uploads/715a4d7c3f3e4485d60919247ccb11c8/code_14_march.mod)Normann RionNormann Rionhttps://git.dynare.org/Dynare/dynare/-/issues/1768Harmonize output of local_state_space_iteration_k and local_state_space_itera...2021-03-12T14:00:54ZJohannes PfeiferHarmonize output of local_state_space_iteration_k and local_state_space_iteration_2`local_state_space_iteration_k` has all endogenous variables as its output, while `local_state_space_iteration_2` has only `restrict_var_list` (i.e. drops static variables that are not observed). Nevertheless in pretty much all particle ...`local_state_space_iteration_k` has all endogenous variables as its output, while `local_state_space_iteration_2` has only `restrict_var_list` (i.e. drops static variables that are not observed). Nevertheless in pretty much all particle filters we have code like
```
if ReducedForm.use_k_order_solver
tmp = local_state_space_iteration_k(yhat, epsilon, dr, Model, DynareOptions);
else
tmp = local_state_space_iteration_2(yhat,epsilon,ghx,ghu,constant,ghxx,ghuu,ghxu,ThreadsOptions.local_state_space_iteration_2);
end
PredictionError = bsxfun(@minus,Y(:,t),tmp(mf1,:));
```
where `mf1` is the position of the observables in `restrict_var_list`. Consequently, the use of `k_order_solver` will generally return wrong result as we are reading out the wrong variables. There are two ways of fixing this:
1. Change indexing for reading out to `restrict_var_list(mf1)` in various subfunctions
2. Make the output of `local_state_space_iteration_k` and `local_state_space_iteration_2` consistent to output only `restrict_var_list`
I would prefer option 2 as it makes the code faster and we do not need to introduce additional case distinctions that make the code hard to parse.
Relatedly, `local_state_space_iteration_2` is about 60 times faster than `local_state_space_iteration_k` at the same `order=2`, see https://git.dynare.org/Dynare/dynare/-/blob/master/tests/particle/local_state_space_iteration_k_test.mod so any changes should keep this in mind.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1764Document storage of decision rules at order ≥ 42021-03-12T14:00:54ZSébastien VillemotDocument storage of decision rules at order ≥ 4The reference manual documents the matrix storage of decision rules up to order 3. We should give a short description of the storage for higher order (simply the generalisation of order 3, which already uses Dynare++ storage).The reference manual documents the matrix storage of decision rules up to order 3. We should give a short description of the storage for higher order (simply the generalisation of order 3, which already uses Dynare++ storage).5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1770Document optimizers allowing analytic_derivation and fix bugs2021-02-18T15:39:35ZJohannes PfeiferDocument optimizers allowing analytic_derivation and fix bugs- [x] The manual does not state which optimizers employ the analytic gradient. It should be at least `fmincon` (1), `csminwel` (4), `newrat` (5).
- [x] `csminwel` and `newrat` are the two optimizers not shipped with e.g. Matlab. They re...- [x] The manual does not state which optimizers employ the analytic gradient. It should be at least `fmincon` (1), `csminwel` (4), `newrat` (5).
- [x] `csminwel` and `newrat` are the two optimizers not shipped with e.g. Matlab. They rely on calls to
```[~,cost_flag,g1] = penalty_objective_function(x1,fcn,penalty,varargin{:});```
where the third output argument is the gradient. Within `penalty_objective_function` we then have
```
[fval, info, exit_flag, arg1, arg2] = fcn(x, varargin{:});
```
where the gradient `arg1` is the fourth and the Hessian `arg2` the fifth output argument of the underlying objective function. For example
```
function [fval,info,exit_flag,DLIK,Hess,SteadyState,trend_coeff,Model,DynareOptions,BayesInfo,DynareResults] = dsge_likelihood(xparam1,DynareDataset,DatasetInfo,DynareOptions,Model,EstimatedParameters,BayesInfo,BoundsInfo,DynareResults,derivatives_info)
```
This interface creates a problem for Matlab optimizers like `fmincon`, which expect the Jacobian as second and the Hessian as the third function output. Neither the underlying objective nor `penalty_objective_function` conform to this convention. The question is how to address this issue. There are two ways:
1. Add a wrapper function along the line of `penalty_objective_function`, which introduces another layer but would be quite easy to implement.
2. Change the output order of the objective function. This would be cleaner and more efficient, but would require quite massive changes in the code-base
- [x] The current implementation of `analytic_derivation` for `fmincon` in `dynare_minimize_objective` is buggy as it considers the second output `info` to be the gradient.
- [ ] It's not clear whether the treatment of the analytic Jacobian in case of the penalty approach is correct as the Jacobian does not take the penalty into account. We need to check whether these cases are filtered out via `cost_flag`5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1767Deal with stale fields in oo_.dr2021-01-29T14:38:54ZJohannes PfeiferDeal with stale fields in oo_.dr`resol.m` contains
```
if isfield(oo,'dr');
dr = oo.dr;
end
```
which will create problems with stale fields if the order in a mod-file decreases. It will also throw off `size_of_the_reduced_form_model``resol.m` contains
```
if isfield(oo,'dr');
dr = oo.dr;
end
```
which will create problems with stale fields if the order in a mod-file decreases. It will also throw off `size_of_the_reduced_form_model`https://git.dynare.org/Dynare/dynare/-/issues/1702det_cond_forecast() argument checking is broken2021-01-28T20:29:40ZMichelJuillarddet_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 2085.xMichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1409Add an interface for setting initial condition of the Kalman filter2021-01-27T16:46:38ZStéphane Adjemianstepan@adjemian.euAdd an interface for setting initial condition of the Kalman filterSee discussion in #1395.See discussion in #1395.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1757Fix dynare_estimation_1 for order>12021-01-25T18:34:24ZJohannes PfeiferFix dynare_estimation_1 for order>1Particle filter estimation was simply plugged into `dynare_estimation_1`. Many routines can be recycled, but we need to be more careful to check that outputs are really correct at `order>1`. For example, we will return smoother results b...Particle filter estimation was simply plugged into `dynare_estimation_1`. Many routines can be recycled, but we need to be more careful to check that outputs are really correct at `order>1`. For example, we will return smoother results based on a Kalman smoother instead of a particle smoother.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1756Decide what to do with options_.particles.pruning2021-01-25T18:34:24ZJohannes PfeiferDecide what to do with options_.particles.pruningI am having trouble with the `options_.particles.pruning`-option. It is used within the particle filter routines, but currently not inherited for the use of `simult_` in e.g. `non_linear_dsge_likelihood` or `irf.m`. I actually don't see ...I am having trouble with the `options_.particles.pruning`-option. It is used within the particle filter routines, but currently not inherited for the use of `simult_` in e.g. `non_linear_dsge_likelihood` or `irf.m`. I actually don't see why we need that as a separate option of `particles`. I would prefer to have `options_.pruning` and have `particles` rely on it. Or to stay within the module-logic, have `options_.pruning` inherit `options_.particles.pruning`.5.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1771preprocessor crash @#ifndef with ||2021-01-22T13:21:42ZMarco Rattopreprocessor crash @#ifndef with ||the following macro-processor syntax is obviously wrong
```
@#ifndef blabla || something
```
but preprocessor crashes without echoing an error.the following macro-processor syntax is obviously wrong
```
@#ifndef blabla || something
```
but preprocessor crashes without echoing an error.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1765Decide what to do with exogenous deterministic with lead or lag2021-01-22T13:19:33ZSébastien VillemotDecide what to do with exogenous deterministic with lead or lagEndogenous with a lead/lag > 1 and exogenous with a lead/lag are now replaced by auxiliary variables in both stochastic and deterministic mode (see #1112).
However, no such transformation is performed for exogenous deterministic (`varex...Endogenous with a lead/lag > 1 and exogenous with a lead/lag are now replaced by auxiliary variables in both stochastic and deterministic mode (see #1112).
However, no such transformation is performed for exogenous deterministic (`varexo_det`) with lead/lag.
First, we should verify that the current code is not buggy when an exo det is used with a lead/lag (see also #1603).
In any case, it is probably better to homogeneize the treatment across the various types of variables. There are basically two options:
- forbid exo det with lead/lag
- perform the same substitution for those as for “regular” exogenous variables
The first option is of course easier to implement. The second option has the advantage of making things more symmetric, but it’s unclear whether it’s worth it.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1534Add documentation for SMM/GMM/IRF options2021-01-21T15:54:44ZJohannes PfeiferAdd documentation for SMM/GMM/IRF optionsRelevant commits are https://github.com/DynareTeam/dynare/commit/254a73a4065a4b476296391dd22672637f82fc72 and https://github.com/DynareTeam/dynare/commit/d52f13114d10fbe5fd4d263d5d0b9d7cfda787f6Relevant commits are https://github.com/DynareTeam/dynare/commit/254a73a4065a4b476296391dd22672637f82fc72 and https://github.com/DynareTeam/dynare/commit/d52f13114d10fbe5fd4d263d5d0b9d7cfda787f6Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1600look at preprocessor `output` option2021-01-19T09:49:57ZHoutan Bastanilook at preprocessor `output` optionWhat is `dynamic` used for?
Look at printing in `DynareMain2.cc`. Why do we switch on `output_mode` ?What is `dynamic` used for?
Look at printing in `DynareMain2.cc`. Why do we switch on `output_mode` ?5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1728Improvements to make install rule2021-01-19T09:49:57ZSé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...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/`.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1731Error in derivatives of perfect foresight models with leaded or lagged exogen...2021-01-13T17:20:08ZMichelJuillardError 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](/uploa...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.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1761Method of Moments mode_compute 11 and 122021-01-13T14:59:36ZWilli Mutschlerwilli@mutschler.euMethod of Moments mode_compute 11 and 12In merge request !1799 I added a test mod file RBC_MoM_optimizer.mod which runs through all optimizers to check whether the call to the optimizers succeeds. For mode_compute=11 and mode_compute=12, at least for me, there is an error.In merge request !1799 I added a test mod file RBC_MoM_optimizer.mod which runs through all optimizers to check whether the call to the optimizers succeeds. For mode_compute=11 and mode_compute=12, at least for me, there is an error.5.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1762set_auxiliary_variables function doesn't handle exogenous variables correctly2021-01-11T14:41:53ZMichelJuillardset_auxiliary_variables function doesn't handle exogenous variables correctlyCurrently the signature of ``set_auxiliary_variables`` function is
```
y = <modname>_set_auxiliary_variables(y, x, params).
```
When there are auxiliary exogenous variables the updated value of ``x`` isn't returned.
1. return [y, x]
2. m...Currently the signature of ``set_auxiliary_variables`` function is
```
y = <modname>_set_auxiliary_variables(y, x, params).
```
When there are auxiliary exogenous variables the updated value of ``x`` isn't returned.
1. return [y, x]
2. modify existing Matlab code calling the function
3. The Julia version of the this function should modify ``y`` and ``x`` in place and not return anythinghttps://git.dynare.org/Dynare/dynare/-/issues/1743Start diary earlier to include input arguments and Dynare version2021-01-06T16:32:28ZJohannes PfeiferStart 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.5.xSébastien VillemotSébastien Villemot