dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-11-13T12:19:37Zhttps://git.dynare.org/Dynare/dynare/-/issues/1718Auxillary particle filter --- number_of_state_variables is undefined2020-11-13T12:19:37ZArtur ZmanovskiiAuxillary particle filter --- number_of_state_variables is undefinedIn `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`n...In `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`number_of_state_variables` --- at lines 137--138) and causes error.5.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1714`get_error_message` does not return an output when `options_.noprint = 1`2020-03-10T08:26:24ZAliaksandr Zaretski`get_error_message` does not return an output when `options_.noprint = 1`The function `get_error_message` must return an output, but does so only when `options_.noprint = 0`. Hence, there is an unexpected error message when both `info(1) > 0` and `options_.noprint = 1`. To replicate, see attached [example1_ed...The function `get_error_message` must return an output, but does so only when `options_.noprint = 0`. Hence, there is an unexpected error message when both `info(1) > 0` and `options_.noprint = 1`. To replicate, see attached [example1_ed.mod](/uploads/f0716731f7540ce7030e68dd2e5de1eb/example1_ed.mod), where I set `alpha = -0.36` to generate an error and added the `noprint` option. See attached slightly revised [print_info.m](/uploads/30439caa39aacbdac9f9e1b2a644483b/print_info.m) and [get_error_message.m](/uploads/c15787c57bb9e46b6a3136be9a803db9/get_error_message.m) where the issue is solved.https://git.dynare.org/Dynare/dynare/-/issues/1713Decide minimal MATLAB version requirement for Dynare 4.72020-09-03T14:45:14ZSébastien VillemotDecide minimal MATLAB version requirement for Dynare 4.7We need to decide what will be the minimal version of MATLAB required to run Dynare 4.7.
For Dynare 4.6, our policy has been to support MATLAB versions that are at most 10 years old.
Assuming that Dynare 4.7 is released in 2021, keepin...We need to decide what will be the minimal version of MATLAB required to run Dynare 4.7.
For Dynare 4.6, our policy has been to support MATLAB versions that are at most 10 years old.
Assuming that Dynare 4.7 is released in 2021, keeping the same policy would imply raising the minimal MATLAB version to R2011a or R2011b (depending on the exact release date).
But we could also decide to change our policy and support less versions. For example, we could go for a 5-years windows, which would imply R2016a or R2016b. Or we could choose something between 5 and 10 years.
Relevant to this discussion is the list of [MATLAB incompatibilities across versions](https://git.dynare.org/Dynare/dynare/-/wikis/MATLAB-Versions). Here are the main benefits that would bring certain requirements:
- *R2013a*: we could get rid of the hack needed to support `intersect(…, 'stable')`
- *R2014a*: we could easily install the minimal required MATLAB version on modern GNU/Linux systems (currently we need a hack to create an artificial `eth0` device with the correct MAC address)
- *R2016a*: we could drop the support for 32-bit versions, which would halve the size of the Windows installer and simplify the build process
- *R2016b*: we could use automatic broadcasting in many places, instead of the obscure `bsxfun` syntax5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1712Difficulty configuring dynare in Ubuntu 18.042020-03-17T10:31:02ZCraig FratrikDifficulty configuring dynare in Ubuntu 18.04There doesn't seem to be an easy way to get Ubuntu 18.04 to default to GCC 8 if GCC 7 is around, which is normally is because of build-essentials.
It would be nice if the configure script for dynare, double checked that gcc and g++ and ...There doesn't seem to be an easy way to get Ubuntu 18.04 to default to GCC 8 if GCC 7 is around, which is normally is because of build-essentials.
It would be nice if the configure script for dynare, double checked that gcc and g++ and gfortran are >= 8, and if they aren't lookede for gcc-8, etc. instead.
I'm not sure how much work this would be inside the configure scripts. But if you think it's a good idea I can look into it. It would be especially helpful if you had thoughts on the best way to do this, because I'm ignorant when it comes to configure things.
I did write this script after >30m of searching on the internet [update-alternatives.sh](/uploads/7fd44dc23129675f12ea787e3c5e561c/update-alternatives.sh)https://git.dynare.org/Dynare/dynare/-/issues/1711Provide M_ as output of stoch_simul and discretionary_policy2020-05-06T14:33:56ZJohannes PfeiferProvide M_ as output of stoch_simul and discretionary_policyWe forgot in https://git.dynare.org/Dynare/dynare/commit/e043c60903dd0e5746feb8af25cd60f1dbcbe53f
that within the computation of decision rules, the steady state file can change parameters and therefore `M_.params`. In the current versio...We forgot in https://git.dynare.org/Dynare/dynare/commit/e043c60903dd0e5746feb8af25cd60f1dbcbe53f
that within the computation of decision rules, the steady state file can change parameters and therefore `M_.params`. In the current version, that change will not be passed to the base workspace.https://git.dynare.org/Dynare/dynare/-/issues/1710num_procs doesn't exist in Matalb R2019b anymore2020-02-22T17:49:35ZMichelJuillardnum_procs doesn't exist in Matalb R2019b anymoreThere is no function ``num_procs``in Matlab release 2019b
``num_procs`` is used in ``default_option_values.m`` to initialize number of threads for ``kronecker.sparse_hessian_times_B_kronecker_C``, ``perfect_foresight_problem`` and ``k_o...There is no function ``num_procs``in Matlab release 2019b
``num_procs`` is used in ``default_option_values.m`` to initialize number of threads for ``kronecker.sparse_hessian_times_B_kronecker_C``, ``perfect_foresight_problem`` and ``k_order_perturbation``
A possible alternative would be an undocumented Matlab feature: ``feature('numcores')``
Undocumented Matlab features are discussed in this old document: http://undocumentedmatlab.com/articles/undocumented-feature-function/ but is still working.https://git.dynare.org/Dynare/dynare/-/issues/1708Preprocessor fails to parse dates with negative date2020-06-30T12:10:36ZMichelJuillardPreprocessor fails to parse dates with negative date```
dates('-4Y');
```
translates in
```
dates('-dates('4Y')');
```
and
```
'-4Y'
```
translates in
```
'-dates('4Y')';
```
See attached *.mod file[test_negative_date.mod](/uploads/bd77dc2c55701ffd505b432a2071f86d/test_negative_date.mod...```
dates('-4Y');
```
translates in
```
dates('-dates('4Y')');
```
and
```
'-4Y'
```
translates in
```
'-dates('4Y')';
```
See attached *.mod file[test_negative_date.mod](/uploads/bd77dc2c55701ffd505b432a2071f86d/test_negative_date.mod)
The problem didn't appear in 4.5.74.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1706Fix wrong computation in third-order approximation in pruned_state_space.m2020-04-06T08:19:17ZJohannes PfeiferFix wrong computation in third-order approximation in pruned_state_space.mMattermost discussion 06/02/20Mattermost discussion 06/02/204.6Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1705Fix, clean and speed up discretionary_policy routines2020-02-12T16:18:04ZJohannes PfeiferFix, clean and speed up discretionary_policy routinesAs is `discretionary_policy_1.m` has various issues
1. At its end, we have
```
function ys=NondistortionarySteadyState(M_)
if exist([M_.fname,'_steadystate.m'],'file')
eval(['ys=',M_.fname,'_steadystate.m;'])
else
ys=zeros(M_.en...As is `discretionary_policy_1.m` has various issues
1. At its end, we have
```
function ys=NondistortionarySteadyState(M_)
if exist([M_.fname,'_steadystate.m'],'file')
eval(['ys=',M_.fname,'_steadystate.m;'])
else
ys=zeros(M_.endo_nbr,1);
end
```
which seems to miss the case of a `steady_state_model`-block. It's also not clear why we have this in any case. At the end of the function, we write `ys` based on this input. But throughout the function, like in
```
[U,Uy,W] = feval([M_.fname,'.objective.static'],zeros(endo_nbr,1),[], M_.params);
```
we assume the steady state to be 0.
2. The handling of error codes should be nested into the `print_info`-framework as opposed to always issuing errors.
3. The function is very verbatim in terms of providing diagnostics. That is useful in standalone code, but a bottleneck when run in a loop like `estimation` where we only want to discard infeasible draws without providing diagnostics.
4. The order of some checks is strange. We do computations on the model before checking e.g. whether the number of instruments is valid. We should be able to do this without computing the Jacobian. Also a check like this should only be done once in the context of estimation and does not belong into the core engine. This suggests a different factorization.
Related to https://git.dynare.org/Dynare/dynare/issues/11734.6Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1703det_cond_forecast() depends on oo_.dr.state_var but this is not always available2021-09-17T16:07:34ZMichelJuillarddet_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 model5.xMichelJuillardMichelJuillardhttps://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/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/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_d...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/1697Regression in LMMCP perfect foresight solver2020-12-02T21:55:49ZSé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 sim...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``` 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/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 PfeiferAllow 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.eu