dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-06-28T19:04:06Zhttps://git.dynare.org/Dynare/dynare/-/issues/1791bug in handling heteroskedastic shocks input2021-06-28T19:04:06ZMarco Rattobug in handling heteroskedastic shocks inputusing the attached modified mod file wrt test, with the following definitions:
```
heteroskedastic_shocks;
var e_b;
periods 100:120 125;
values 0.01 0.01;
var e_a;
periods 100:120 125;
scales 0 0;
end;
```
only triggers the ...using the attached modified mod file wrt test, with the following definitions:
```
heteroskedastic_shocks;
var e_b;
periods 100:120 125;
values 0.01 0.01;
var e_a;
periods 100:120 125;
scales 0 0;
end;
```
only triggers the last periods declared in heteroskdastic_shocks block (125) into `M_.heteroskedastic_shocks.Qhet`, ignoring all previous ones (100:125 in this case):
```
M_.heteroskedastic_shocks.Qhet.e_b
ans =
struct with fields:
time_value: 125
value: 0.0100
```
[fs2000_het.mod](/uploads/f5546deffa2da315852934a0b8fb60c7/fs2000_het.mod)5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1789Regression in extended path2021-05-28T12:02:51ZJohannes PfeiferRegression in extended pathThe attached file runs in 4.6.4 but crashes in the unstable. We should add the file to the testsuite.
[rbc_OBC_pf.mod](/uploads/c34feb62e9e4bab503d399e7701a23e2/rbc_OBC_pf.mod)The attached file runs in 4.6.4 but crashes in the unstable. We should add the file to the testsuite.
[rbc_OBC_pf.mod](/uploads/c34feb62e9e4bab503d399e7701a23e2/rbc_OBC_pf.mod)5.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1787Information set for the expectation variables with geometric discounting2021-09-13T08:45:20ZAnastasia ZhInformation set for the expectation variables with geometric discountingTo have a possibility to change the timing of an information set for the expectation variables with geometric discounting. At this stage it is hard coded at time t.To have a possibility to change the timing of an information set for the expectation variables with geometric discounting. At this stage it is hard coded at time t.https://git.dynare.org/Dynare/dynare/-/issues/1786Check iterative OLS and NLS estimation approaches for the estimation of the P...2021-09-13T08:46:33ZStéphane Adjemianstepan@adjemian.euCheck iterative OLS and NLS estimation approaches for the estimation of the PAC equationThe sum of square residuals should always be smaller (provided that the optimization algorithm does not fail or reach a local minimum) with NLS. Conduct a Monte-Carlo exercise to check that this is what we observe.The sum of square residuals should always be smaller (provided that the optimization algorithm does not fail or reach a local minimum) with NLS. Conduct a Monte-Carlo exercise to check that this is what we observe.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1785Add structural VAR model as an auxiliary model for VAR based expectations and...2021-09-13T08:44:21ZStéphane Adjemianstepan@adjemian.euAdd structural VAR model as an auxiliary model for VAR based expectations and PAC equations2021-09-10https://git.dynare.org/Dynare/dynare/-/issues/1783bug with auxiliary exo lags with loglinear2021-05-11T16:52:22ZMarco Rattobug with auxiliary exo lags with loglinearIn the new unit test `fs2000_het.mod`, (merge request !1844), I added a shock to the model to test `heteroskedastic_shocks`. doing that I noted a bug at the interaction between loglinear and auxiliary exo lag variables.
It turns out that...In the new unit test `fs2000_het.mod`, (merge request !1844), I added a shock to the model to test `heteroskedastic_shocks`. doing that I noted a bug at the interaction between loglinear and auxiliary exo lag variables.
It turns out that this modified mod file triggers an auxiliary lagged exo variable.
for this variable, ys is set to zero, which is then logged in `store_smoother_results`, resulting in inf's for that variable in `oo_.SmoothedVariables` etc.
Moreover, running forecast after that, this triggers nan for all forecasted variables.5.xhttps://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/1781Check correctness of optimal policy with linear model2021-05-31T13:30:20ZJohannes PfeiferCheck correctness of optimal policy with linear model`stoch_simul` locally sets
if options_.order~=1 && M_.hessian_eq_zero
options_.order = 1;
However, `M_.hessian_eq_zero` only seems to apply to the original model, not the nonlinear one resulting from e.g. `ramsey_model`.
On top o...`stoch_simul` locally sets
if options_.order~=1 && M_.hessian_eq_zero
options_.order = 1;
However, `M_.hessian_eq_zero` only seems to apply to the original model, not the nonlinear one resulting from e.g. `ramsey_model`.
On top of that, the change is local, so `evaluate_planner_objective` will crash, because it expects `order=2`.
The same will happen when declaring `model(linear)`. Note that an additional check is in `stochastic_solvers`.
An example is
[ramsey_test.mod](/uploads/452ae65f88b2dde038ab7a844ec429ed/ramsey_test.mod)5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1780Compile from source on Mac M1 Apple Silicon architecture2022-01-05T08:31:39ZWilli Mutschlerwilli@mutschler.euCompile from source on Mac M1 Apple Silicon architectureI got hold of a Mac M1 and cannot compile from source following the instructions in the README.md
I will investigate this further and change the instructions accordingly.I got hold of a Mac M1 and cannot compile from source following the instructions in the README.md
I will investigate this further and change the instructions accordingly.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1779Fix detection of Command Line Tools in macOS installer2021-06-28T19:04:06ZSébastien VillemotFix detection of Command Line Tools in macOS installerIn some circumstances (to be determined), the Dynare installer thinks that CLT are installed, while they are not. The typical error message in this case (in `install.log`) is that `git` is not in the path.
Some instances of this:
- http...In some circumstances (to be determined), the Dynare installer thinks that CLT are installed, while they are not. The typical error message in this case (in `install.log`) is that `git` is not in the path.
Some instances of this:
- https://forum.dynare.org/t/i-can-t-download-dynare-4-6-3-in-macos/17296/
- https://forum.dynare.org/t/error-while-installing-dynare-4-6-3-mac-os-big-sur/17131/
- https://forum.dynare.org/t/problem-installing-4-6-0-on-macos-catalina/15247/20 (second poster)
- https://forum.dynare.org/t/installation-problems-of-4-6-0-on-macos/15345/20 (second poster)5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1775Fix behavior of smoother2histval2021-09-17T16:07:34ZJohannes PfeiferFix behavior of smoother2histval- [x] The `smoother` will only store the `M_.orig_endo_nbr` variables for Bayesian estimation. So calling
`smoother2histval` will "forget" about the auxiliary variables we introduce. Thus, by convention they will be
initialized...- [x] The `smoother` will only store the `M_.orig_endo_nbr` variables for Bayesian estimation. So calling
`smoother2histval` will "forget" about the auxiliary variables we introduce. Thus, by convention they will be
initialized at their steady state - which differs from the description in the manual that it
>will use these values to construct initial conditions (as if they had been manually entered through histval).
In case of `histval`, the non-mentioned variables would be set to 0.
In contrast, for ML it will work.
- [ ] @MichelJuillard In https://git.dynare.org/Dynare/dynare/-/commit/b70d99d1b4af4e6799858902868300a246e3b492 the
code was refactored. But the treatment of lags seems inconsistent. Initialization assumes one lag via
```
M_.endo_histval = repmat(oo_.steady_state, 1, M_.maximum_lag);
```
but later we have
```
k = M_.orig_maximum_endo_lag - M_.maximum_endo_lag + 1: M_.orig_maximum_lag;
v = s((period-M_.orig_maximum_endo_lag+1):period);% + steady_state(j);
M_.endo_histval(j, :) = v(k);
```
which relies on `orig_maximum_endo_lag` and may have more than one lag. Using grep, it seems most other files
expect `M_.endo_histval` to be a vector not a matrix.
- [ ] Depending on whether output is to a file or `M_.endo_histval`, non-requested variables will be set to 0 or the steady state. We must be consistent.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1773Improve performance of local_state_space_iteration_*2022-02-01T09:54:22ZSé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.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1772Document method of moments toolbox2021-08-17T10:51:11ZSébastien VillemotDocument method of moments toolbox5.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.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/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/1769Discuss merging dsge_simulated_theoretical_correlation and dsge_simulated_the...2021-07-22T16:25:02ZJohannes PfeiferDiscuss merging dsge_simulated_theoretical_correlation and dsge_simulated_theoretical_covariance`dsge_simulated_theoretical_covariance` sets `options_.ar = 0` before calling `th_autocovariances`. `dsge_simulated_theoretical_correlation` again calls `th_autocovariances` and therefore recomputes the variance. One call with `options_....`dsge_simulated_theoretical_covariance` sets `options_.ar = 0` before calling `th_autocovariances`. `dsge_simulated_theoretical_correlation` again calls `th_autocovariances` and therefore recomputes the variance. One call with `options_.nar` would suffice. This inefficiency is even more pronounced at higher order with `pruning` where we need to call `pruned_state_space_system`.
We should either
1. Merge the two functions.
2. Have `dsge_simulated_theoretical_covariance` compute and store everything and only use `dsge_simulated_theoretical_correlation` to fill the fields.5.xhttps://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/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/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/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 Villemot