dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-03-16T08:27:57Zhttps://git.dynare.org/Dynare/dynare/-/issues/1716Fix bug in contemp_reduced_form of SBVAR2020-03-16T08:27:57ZJohannes PfeiferFix bug in contemp_reduced_form of SBVARAs outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveB...As outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveBVAR.mod](/uploads/f7b1c204676a2323d03a467702f6e3c5/constantRecursiveBVAR.mod)https://git.dynare.org/Dynare/dynare/-/issues/1853Incorrect pruning at order 2 with particle filtering2022-05-13T11:20:01ZSébastien VillemotIncorrect pruning at order 2 with particle filteringAn anonymous user noticed that our implementation of pruning at order 2 with particle filtering is probably incorrect. The problem is located in MEX `local_state_space_iteration_2`.
More precisely, when computing next period pruned vari...An anonymous user noticed that our implementation of pruning at order 2 with particle filtering is probably incorrect. The problem is located in MEX `local_state_space_iteration_2`.
More precisely, when computing next period pruned variables, instead of adding the term `+ghxu·ŷ₁⊗ε` (as indicated in the comment), the code actually adds `+ghxu·ŷ₂⊗ε`. See https://git.dynare.org/Dynare/dynare/-/blob/master/mex/sources/local_state_space_iterations/local_state_space_iteration_2.cc#L118
The paper by Kim et al. (2008), and also our MATLAB/Octave implementation of pruned simulations (in `matlab/simult_.m`), both use `ŷ₁` at that place.
I’d be grateful if someone else could confirm this diagnostic. Cc @stepan-a @JohannesPfeifer @normann6.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1851Investigate failures of block decomposition when computing steady states2022-05-23T13:34:58ZJohannes PfeiferInvestigate failures of block decomposition when computing steady statesThe file [solve_v8.mod](/uploads/ebfe2f378975dc36bacb9cded885af23/solve_v8.mod) fails computing the terminal steady state with trust region, while it works with `fsolve`. Part of the problem is that `dogleg` returns `NaN` due to `0*Inf`....The file [solve_v8.mod](/uploads/ebfe2f378975dc36bacb9cded885af23/solve_v8.mod) fails computing the terminal steady state with trust region, while it works with `fsolve`. Part of the problem is that `dogleg` returns `NaN` due to `0*Inf`.
[parameter.mat](/uploads/54b16134b65e3a1606bcffb16cfe981a/parameter.mat)
[steadystate.mat](/uploads/52ef9c6f06f434910020d5e5f3a6e0cd/steadystate.mat)
This seems to be caused by blocks computed from the Dulmage-Mendelsohn decomposition having singular Jacobians.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1850Fix perfect_foresight_problem.cc for case without leaded variables2022-05-20T08:21:51ZJohannes PfeiferFix perfect_foresight_problem.cc for case without leaded variablesThe file contains the error message
> mexErrMsgTxt("M_.lead_lag_incidence should be a real dense matrix with 2+M_.maximum_endo_lag rows and M_.endo_nbr columns");
but `M_.lead_lag_incidence` is `1 + M_.maximum_endo_lag +M_.maximum_endo...The file contains the error message
> mexErrMsgTxt("M_.lead_lag_incidence should be a real dense matrix with 2+M_.maximum_endo_lag rows and M_.endo_nbr columns");
but `M_.lead_lag_incidence` is `1 + M_.maximum_endo_lag +M_.maximum_endo_lead`, not `2+M_.maximum_endo_lag`
[test4.mod](/uploads/933fb136ea3b9a64301b60f49d09c067/test4.mod) should trigger the issue.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1843Fix stochastic singularity check with `heteroskedastic_shocks`2022-02-18T20:24:55ZJohannes PfeiferFix stochastic singularity check with `heteroskedastic_shocks`Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1842Fix Occbin estimation with `prefilter`2022-04-07T12:30:48ZJohannes PfeiferFix Occbin estimation with `prefilter`Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1840Fix loading of `xls_sheet` and `xls_range` in mom2022-04-07T12:30:48ZJohannes PfeiferFix loading of `xls_sheet` and `xls_range` in momThe problem is caused by https://git.dynare.org/Dynare/dseries/-/issues/51 and was reported in https://forum.dynare.org/t/mom-in-dynare-5-0-does-not-load-correct-xls-sheet/19693The problem is caused by https://git.dynare.org/Dynare/dseries/-/issues/51 and was reported in https://forum.dynare.org/t/mom-in-dynare-5-0-does-not-load-correct-xls-sheet/19693https://git.dynare.org/Dynare/dynare/-/issues/1837PAC model fails with models linear in logs2022-01-24T11:24:29ZStéphane Adjemianstepan@adjemian.euPAC model fails with models linear in logs[example3.mod](/uploads/0ca5f43b137a17193e5c45f17005c929/example3.mod) fails with the following error:
```shell
>> dynare example3
Starting Dynare (version 6-unstable).
Calling Dynare with arguments: none
Starting preprocessing of the mo...[example3.mod](/uploads/0ca5f43b137a17193e5c45f17005c929/example3.mod) fails with the following error:
```shell
>> dynare example3
Starting Dynare (version 6-unstable).
Calling Dynare with arguments: none
Starting preprocessing of the model file ...
Substitution of Unary Ops: added 1 auxiliary variables and equations.
Substitution of Diff operator: added 7 auxiliary variables and equations.
ERROR: the model equation defining the 'target' of 'pac_target_info(pacman)' is not of the right form (should be a linear combination of endogenous variables)
Error using dynare (line 269)
Dynare: preprocessing failed
```
But the model is linear in logs, and the preprocessor should not throw an error.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1828occbin_write_regimes bug: smoothed regimes are not handled2021-12-11T17:50:17ZMarco Rattooccbin_write_regimes bug: smoothed regimes are not handledthe current behavior of `occbin_write_regimes` command points to the field `oo_.occbin.regime_history`, which is provided as a result of a model simulation.
when running a smoother, instead, regime history is stored in `oo_.occbin.smooth...the current behavior of `occbin_write_regimes` command points to the field `oo_.occbin.regime_history`, which is provided as a result of a model simulation.
when running a smoother, instead, regime history is stored in `oo_.occbin.smoother.regime_history`: we would then need an extra option to the command to specify whether the regmies come from a simulation or from a smoother, so to allow calling it;
`occbin_write_regimes(smoother);` or `occbin_write_regimes(simulation);`
at this point, we may also think to move the results of a simulation in a substructure `oo_.occbin.simul` ?Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1827occbin bug: varables with trend are not properly handled in switching equations2021-12-11T17:50:17ZMarco Rattooccbin bug: varables with trend are not properly handled in switching equationsAssume a model with variables with trend:
```
var bg y (deflator=y0);
var t;
```
with parameters
```
parameters eta deftar
eta=0.01;
deftar=0.03;
```
I a variable with a trend appears in an equation that switches:
```
[name = 'debt sta...Assume a model with variables with trend:
```
var bg y (deflator=y0);
var t;
```
with parameters
```
parameters eta deftar
eta=0.01;
deftar=0.03;
```
I a variable with a trend appears in an equation that switches:
```
[name = 'debt stabilization rule', bind = 'bg0']
t=0;
[name = 'debt stabilization rule', relax = 'bg0']
t = eta*( (bg-bg(-1))/y - deftar);
...
```
```
steady_state_model;
t=0;
y=1;
bg=2.4;
end;
```
then, the switches are treated BEFORE handling the trends, which means that in static_resid the first difference `bg-bg(-1)` is first evaluated to be ZERO (which is wrong, since the trend is not considered there), so that in steady state we have a residual equation like
```
resid() = t_ss - eta*(-deftar);
```
which provides a non-zero residual.
I fear a similar issue pops up in the dynamic file.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1823Fix or block interplay of stochastic Ramsey and block2021-11-24T10:32:33ZJohannes PfeiferFix or block interplay of stochastic Ramsey and block1. The attached file has a problem with the residual of the static model. It outputs residuals of the conditional steady state file that do not exist without `block` [rams1.mod](/uploads/708d194c770eb1cb8e1747f533139c19/rams1.mod)
2. Whe...1. The attached file has a problem with the residual of the static model. It outputs residuals of the conditional steady state file that do not exist without `block` [rams1.mod](/uploads/708d194c770eb1cb8e1747f533139c19/rams1.mod)
2. When overriding this and moving into `dyn_ramsey_static`, the `nblock`-input of the `+FNAME.static.m`-file is not set, suggesting that `block` is not supported in the first place.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1821evaluate_planner_objective does not compute expected utility correctly2021-10-18T16:43:48ZJohannes Pfeiferevaluate_planner_objective does not compute expected utility correctlySee the failed tests in !1945
The proximate cause is that the expected value `EU` in `evaluate_planner_objective.m` differs from what you would get when it were part of the variables in `oo_.mean`.See the failed tests in !1945
The proximate cause is that the expected value `EU` in `evaluate_planner_objective.m` differs from what you would get when it were part of the variables in `oo_.mean`.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1820Invalid memory accesses in local_state_space_iteration_2 when there are more ...2021-10-21T18:11:05ZSébastien VillemotInvalid memory accesses in local_state_space_iteration_2 when there are more shocks than statesIn [local_state_space_iteration_2](mex/sources/local_state_space_iterations/local_state_space_iteration_2.cc#L166), in function `ss2Iteration`, the block that computes `ghx·yhat+ghu·u` reads as follows:
```
for (int column = 0,...In [local_state_space_iteration_2](mex/sources/local_state_space_iterations/local_state_space_iteration_2.cc#L166), in function `ss2Iteration`, the block that computes `ghx·yhat+ghu·u` reads as follows:
```
for (int column = 0, column_ = 0; column < q; column++, column_ += m)
{
int i1 = variable+column_;
int i2 = column+particle__;
int i3 = column+particle___;
y[variable_] += ghx[i1]*yhat[i2];
y[variable_] += ghu[i1]*epsilon[i3];
}
for (int column = q, column_ = q*m; column < n; column++, column_ += m)
y[variable_] += ghx[variable+column_]*yhat[column+particle__];
```
This code makes the implicit assumption that `q⩽n`, i.e. that the number of shocks is less than or equal to the number of states. If `q>n`, it will try to read invalid memory references in `ghx` and `yhat`, and it will either crash or return dummy results.
The same problem is present in the `ss2Iteration_pruning` function.
The fix is simply to reorganize the loops, with one loop that only deals with the states and another one that deals with shocks.
@stepan-a If you agree with this diagnostic, I will take care of fixing it.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1819Fix bug in mex k-order-simulations (i.e. without pruning)2021-10-12T15:39:39ZJohannes PfeiferFix bug in mex k-order-simulations (i.e. without pruning)The mex-file `dynare_simul_` erroneously iterates on the policy function with a zero shock vector for the first (non-endogenous) period. As a consequence, results differ from the m-file-based simulations at second order and from a one at...The mex-file `dynare_simul_` erroneously iterates on the policy function with a zero shock vector for the first (non-endogenous) period. As a consequence, results differ from the m-file-based simulations at second order and from a one at a time sequential simulation (see https://forum.dynare.org/t/simult-results-different-with-loop/19053/3).
The bug will not affect
1. third order simulations with pruning, which are based on the m-file.
2. IRFs starting the stochastic steady state/ergodic mean in the absence of shocks due to it being the fixed point of the simulation.
The bug will typically hardly affect moment computations and IRFs at the ergodic mean due to the initial burn-in period. In that case, the initial condition should wash out.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1815bytecode locks .bin file after entering homotopy.2021-09-20T16:44:50ZJohannes Pfeiferbytecode locks .bin file after entering homotopy.Running [ireland.mod](/uploads/27aa0ebc6b17c399aa0a9f0ee2929c23/ireland.mod) triggers an exception
`Fatal error in bytecode: umfpack_dl_solve failed`
in the first iteration so that we enter homotopy mode. This it successful. But subseque...Running [ireland.mod](/uploads/27aa0ebc6b17c399aa0a9f0ee2929c23/ireland.mod) triggers an exception
`Fatal error in bytecode: umfpack_dl_solve failed`
in the first iteration so that we enter homotopy mode. This it successful. But subsequently, the mod-file cannot be run a second time due to `model/bytecode/dynamic.bin` being locked. It seems that
`SparseMatrix.cc` opens
```
SaveCode.open(file_name + "/model/bytecode/dynamic.bin", ios::in | ios::binary);
```
but never closes it in case of an exception.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1810macOS: solve installation problems2021-09-01T13:44:39ZJohannes PfeifermacOS: solve installation problemsSee https://forum.dynare.org/t/installation-failure-with-dynare-4-6-4/18563/18
and
https://github.com/Homebrew/discussions/discussions/1990#discussioncomment-1190489See https://forum.dynare.org/t/installation-failure-with-dynare-4-6-4/18563/18
and
https://github.com/Homebrew/discussions/discussions/1990#discussioncomment-11904895.xhttps://git.dynare.org/Dynare/dynare/-/issues/1807Manual: fix broken references2021-09-20T16:34:02ZJohannes PfeiferManual: fix broken referencesThe manual contains a bunch of broken internal references that seems to occur when referencing something that does not have a natural anchor. For example
```
.. _quote-note:
.. note::
Note on Quotes
```
and
```
...The manual contains a bunch of broken internal references that seems to occur when referencing something that does not have a natural anchor. For example
```
.. _quote-note:
.. note::
Note on Quotes
```
and
```
.. _VarianceDecomposition:
``VarianceDecomposition``
Decomposition of variance (unconditional variance, i.e. at
horizon infinity). [#f5]_
``VarianceDecompositionME``
Same as `VarianceDecomposition`_, but contains
```
do not work5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1804Dynare++: fix --steps option2021-09-01T12:56:19ZJohannes PfeiferDynare++: fix --steps optionUsing
```
dynare++ --steps 1 example1.mod
```
returns
```
Caught TL exception: At ../tl/cc/t_container.hh:186:NaN or Inf asserted in TensorContainer::insert
```
See https://forum.dynare.org/t/steps-option-not-working/18634Using
```
dynare++ --steps 1 example1.mod
```
returns
```
Caught TL exception: At ../tl/cc/t_container.hh:186:NaN or Inf asserted in TensorContainer::insert
```
See https://forum.dynare.org/t/steps-option-not-working/186345.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1797Octave on Mac Homebrew error with mkoctfile2021-09-15T15:49:13ZWilli Mutschlerwilli@mutschler.euOctave on Mac Homebrew error with mkoctfileWhen I compile from source on my Macbook Air (M1), I run into several issues with Octave. For instance, if I run `walsh.mod`, `mkoctfile` calls clang instead of `gcc`. This is most likely a Homebrew-specific problem.
```
Computing stati...When I compile from source on my Macbook Air (M1), I run into several issues with Octave. For instance, if I run `walsh.mod`, `mkoctfile` calls clang instead of `gcc`. This is most likely a Homebrew-specific problem.
```
Computing static model derivatives (order 1).
Computing dynamic model derivatives (order 1).
Processing outputs ...
Compiling static MEX...
"/usr/local/Cellar/octave/6.2.0_3/bin/mkoctfile" -O3 -g0 --param ira-max-conflict-table-size=1 -fno-forward-propagate -fno-gcse -fno-dce -fno-dse -fno-tree-fre -fno-tree-pre -fno-tree-cselim -fno-tree-dse -fno-tree-dce -fno-tree-pta -fno-gcse-after-reload --mex "walsh/model/src/static.c" -o "+walsh/static.mex"
clang: error: unknown argument: '-fno-forward-propagate'
clang: error: unknown argument: '-fno-dce'
clang: error: unknown argument: '-fno-dse'
clang: error: unknown argument: '-fno-tree-fre'
clang: error: unknown argument: '-fno-tree-pre'
clang: error: unknown argument: '-fno-tree-cselim'
clang: error: unknown argument '-fno-tree-dse'; did you mean '-fno-tree-dce'?
clang: error: unknown argument: '-fno-tree-pta'
clang: warning: optimization flag '-fno-gcse' is not supported [-Wignored-optimization-argument]
clang: warning: optimization flag '-fno-tree-dce' is not supported [-Wignored-optimization-argument]
clang: warning: optimization flag '-fno-gcse-after-reload' is not supported [-Wignored-optimization-argument]
Compilation failed
error: Dynare: preprocessing failed
error: called from
dynare at line 269 column 5
```5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1794Different results between Octave and Matlab for jermann98.mod2021-07-22T12:42:23ZWilli Mutschlerwilli@mutschler.euDifferent results between Octave and Matlab for jermann98.modAs noticed by @MichelJuillard: Octave and Matlab seem to deliver very different results for 3rd order simulation of jermann98.mod
[jermann98.mod](/uploads/6be3231b9be639e1bee8a4f73979f938/jermann98.mod)As noticed by @MichelJuillard: Octave and Matlab seem to deliver very different results for 3rd order simulation of jermann98.mod
[jermann98.mod](/uploads/6be3231b9be639e1bee8a4f73979f938/jermann98.mod)