dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2023-09-27T15:04:53Zhttps://git.dynare.org/Dynare/dynare/-/issues/1847Expand *_calibration to higher order2023-09-27T15:04:53ZJohannes PfeiferExpand *_calibration to higher orderCurrently, we only support first order. See also https://forum.dynare.org/t/gsa-of-irfs-with-a-higher-order-approximation/19758/2Currently, we only support first order. See also https://forum.dynare.org/t/gsa-of-irfs-with-a-higher-order-approximation/19758/27.xhttps://git.dynare.org/Dynare/dynare/-/issues/1846Remove global variables from dynare_sensitivity2023-12-14T20:00:14ZJohannes PfeiferRemove global variables from dynare_sensitivityThe command resets various options permanently, causing unexpected downstream problems. An example is !2009The command resets various options permanently, causing unexpected downstream problems. An example is !20096.xhttps://git.dynare.org/Dynare/dynare/-/issues/1845Use keywords as option values when it makes more sense than numerical values2023-09-27T15:11:20ZSébastien VillemotUse keywords as option values when it makes more sense than numerical valuesSeveral options currently accept numerical values, which are not very meaningful nor informative. We could instead use keywords as values (but continue accepting the old numerical values for backward compatibility).
Candidate options fo...Several options currently accept numerical values, which are not very meaningful nor informative. We could instead use keywords as values (but continue accepting the old numerical values for backward compatibility).
Candidate options for this change are:
- `solve_algo`
- `stack_solve_algo`
- `mode_compute`
- `lik_init`
- `kalman_algo`
- `analytic_derivation_mode`
- `mfs`
- `plot_priors`
For example, for `solve_algo`, the integer value `0` could be replaced by the keyword `fsolve`. And so on. The first step is obviously to decide which keywords to use for each numerical value.7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1844algebra at the beginning of conditional_forecast2022-03-02T17:15:11ZMichelJuillardalgebra at the beginning of conditional_forecastIn the algebraic description of ``conditional_forecast`` in section 4.20 of the manual, lagged uncontrolled endogenous variables are missingIn the algebraic description of ``conditional_forecast`` in section 4.20 of the manual, lagged uncontrolled endogenous variables are missing6.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1843Fix stochastic singularity check with `heteroskedastic_shocks`2022-09-21T08:29:57ZJohannes 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/1841dynare_solve maxit option2022-05-04T15:59:17ZMichelJuillarddynare_solve maxit optionThe function dynare_solve was initially developed to compute the steady state but is now used in other contexts like solving backward models. However, lines 57-61: maxit is set by options.steady.maxitThe function dynare_solve was initially developed to compute the steady state but is now used in other contexts like solving backward models. However, lines 57-61: maxit is set by options.steady.maxitStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://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/1839Automatic normalization of variables when solving a model with multiple trends2022-11-03T10:08:33ZUgo DuboisAutomatic normalization of variables when solving a model with multiple trendsIn a model with multiple trends, values of variables which have different trends vary widely at long horizons of simulations (e.g. capital stock which is trended versus a rate of return which is not trended). It implies growing discrepan...In a model with multiple trends, values of variables which have different trends vary widely at long horizons of simulations (e.g. capital stock which is trended versus a rate of return which is not trended). It implies growing discrepancies in simulations, such that some numerical “residuals” are too big with respect to others. Mixing very small quantities with very big ones could cause issues in the numerical methods used to solve simulations of the model.
Operating some automatic normalization (dividing variables by their trend, for variables in level; computing deviations of variables from their trend, for variables in log) when solving the model could solve this issue.
An intuitive way to implement this normalization would be to use information about the steady-state growth rates of all variables in the model (using dlog growth rates, defined as the change of the log of a variable), in order to compute such trends (if the dlog growth rate is g for a period t, as exp(t*g) for variables in level and as t*g for variables in log) and perform a normalization every n periods during the simulation, with n a given number of periods provided as an option by the user (if not provided by the user, Dynare would have a default value for this option). A discussion will be needed with Stéphane Adjemian to assess if this number n could be automatically determined by dynare.
This solution would require an input to provide such information (ideally a structure) to pass it to Dynare. This object should contain the following information about all variables in the model: name, type (e.g. constant or trend), dlog growth rate (as a function of model’s parameters, e.g. z_g+z_pi with z_g and z_pi the change of logs of real output and output price at the steady state), nature (e.g. level or log).
The way to operate such a normalization and the degree of generality of the algorithm (only for backward-looking models or also for forward-looking ones) will be specified after a discussion with Stéphane Adjemian.https://git.dynare.org/Dynare/dynare/-/issues/1838Adding support for dates in perfect_foresight_setup2022-01-25T17:21:59ZUgo DuboisAdding support for dates in perfect_foresight_setupThe user should be able to control the dates of the dseries `simulated_time_series` produced by `perfect_foresight_solver` via perfect_foresight_setup.
Currently, options of perfect foresight simulations work as follows:
• `initval_fil...The user should be able to control the dates of the dseries `simulated_time_series` produced by `perfect_foresight_solver` via perfect_foresight_setup.
Currently, options of perfect foresight simulations work as follows:
• `initval_file` has two inputs, a dseries (for historical values, first guesses and terminal values) and a first date of the simulation named `first_simulation_period`. An alternative is to set with the input `first_obs` the dates used for the first initial conditions. Values of the dseries are passed to `perfect_foresight_setup`, but the first simulation period is not used and the dseries `simulated_time_series` generated by `perfect_foresight_solver` starts at period 1 instead of the first simulation period.
• There exists an internal option `initial_period` of `options_`, but this option is unused.
• The user also provides the input periods to `perfect_foresight_setup` and it is used by `perfect_foresight_solver` in order to generate the good size for `simulated_time_series`.
In order to deal properly with fist and last dates of simulations, we would like:
• First, in order to be consistent with the date concept used in dseries, to name corresponding options with “date” names instead of “period” names, i.e. `first_simulation_date` and `last_simulation_date` for first and last dates of simulations.
• Second, `first_simulation_date` sets the first date of the perfect foresight simulation through `perfect_foresight_setup`. Must be consistent with `first_simulation_date` of `initval_file`. It is an alternative to specifying `first_obs` and must be consistent if `first_obs` is also used as an option. Values for initial conditions before this date must be available.
• Third, `last_simulation_date` sets the last date of simulation through `perfect_foresight_setup`. Combined with `first_simulation_date`, this date should determine the number of periods (last date minus first date plus one) and the `periods` option would not be necessary in this context. It must be consistent with `periods `if it is also used as an option. Data for terminal conditions past the last period must be available.
• Fourth, we would like `simulated_time_series` to be dated and to contain simulated values in the range going from first to last simulation dates. Be careful that the first row of data of `simulated_time_series` changes depending on the presence of lags and leads in the endogenous variables of the model (i.e. it contains the data corresponding to the first date before the first simulated period when the model only contains lags. However, it contains the first simulated period when the model has leads or a mix of leads and lags). Dynare should set the internal option `initial_period` of `options_` to `first_simulation_period` or `first_simulation_period-1` depending on the lead-lag context.
• Fifth, consistent treatments could be developed in the case of the usage of `histval `or `histval_file`. Similarly, if `first_obs `is used, the treatment must be consistent with `histval `or `histval_file `if they are used.
(this ticket updates and replaces this public one: https://git.dynare.org/Dynare/dynare/-/issues/1745)https://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/1836Provide conditional variance decomposition also for pruning2023-09-08T12:55:21ZJohannes PfeiferProvide conditional variance decomposition also for pruningSee https://forum.dynare.org/t/conditional-variance-decomposition-for-order-2-with-pruning-dynare-5-0/19601
This would (partially) restore the old behavior.See https://forum.dynare.org/t/conditional-variance-decomposition-for-order-2-with-pruning-dynare-5-0/19601
This would (partially) restore the old behavior.https://git.dynare.org/Dynare/dynare/-/issues/18355.0 installs empty directories2023-10-11T19:41:19Zyuri@FreeBSD5.0 installs empty directoriesThese directories are empty:
```
lib/dynare/matlab/modules/dseries/src/modules/matlab-fame-io/doc
lib/dynare/matlab/modules/dseries/src/modules/matlab-fame-io/tests/FameDatabases
```These directories are empty:
```
lib/dynare/matlab/modules/dseries/src/modules/matlab-fame-io/doc
lib/dynare/matlab/modules/dseries/src/modules/matlab-fame-io/tests/FameDatabases
```6.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1834example3.mod crashes2022-01-12T16:34:39Zyuri@FreeBSDexample3.mod crashesThis command line:
> octave --eval 'dynare example3.mod'
opens 2 windows (Figure 1 and Figure 2) and crashes with terminal output ending like this:
```
APPROXIMATED COEFFICIENTS OF AUTOCORRELATION
Order 1 2 3 ...This command line:
> octave --eval 'dynare example3.mod'
opens 2 windows (Figure 1 and Figure 2) and crashes with terminal output ending like this:
```
APPROXIMATED COEFFICIENTS OF AUTOCORRELATION
Order 1 2 3 4 5
y 0.9762 0.9530 0.9303 0.9081 0.8864
c 0.9949 0.9889 0.9819 0.9741 0.9656
k 0.9992 0.9971 0.9937 0.9891 0.9834
a 0.9641 0.9299 0.8973 0.8662 0.8365
h 0.9195 0.8442 0.7739 0.7082 0.6468
b 0.9641 0.9299 0.8973 0.8662 0.8365
Total computing time : 0h00m11s
Note: warning(s) encountered in MATLAB/Octave code
fatal: caught signal Segmentation fault -- stopping myself...
Thread 0x80d614300 has exited with leftoveSegmentation fault
```
Version 5.0
FreeBSD 13https://git.dynare.org/Dynare/dynare/-/issues/1833Fails to build with clang2022-01-24T11:24:29Zyuri@FreeBSDFails to build with clang```
EquationTags.cc:74:14: error: invalid operands to binary expression ('std::ostream' (aka 'basic_ostream<char>') and 'const char [3]')
output << " " << eqn + 1
~~~~~~ ^ ~~~~
/usr/include/c++/v1/cstddef:141:3: note: candi...```
EquationTags.cc:74:14: error: invalid operands to binary expression ('std::ostream' (aka 'basic_ostream<char>') and 'const char [3]')
output << " " << eqn + 1
~~~~~~ ^ ~~~~
/usr/include/c++/v1/cstddef:141:3: note: candidate function template not viable: cannot convert argument of incomplete type 'std::ostream' (aka 'basic_ostream<char>') to 'std::byte' for 1st argument
operator<< (byte __lhs, _Integer __shift) noexcept
^
/usr/include/c++/v1/memory:3983:1: note: candidate template ignored: could not match 'shared_ptr<type-parameter-0-2>' against 'char const[3]'
operator<<(basic_ostream<_CharT, _Traits>& __os, shared_ptr<_Yp> const& __p);
^
/usr/include/c++/v1/string_view:813:1: note: candidate template ignored: could not match 'basic_string_view<type-parameter-0-0, type-parameter-0-1>' against 'const char *'
operator<<(basic_ostream<_CharT, _Traits>& __os,
^
/usr/include/c++/v1/string:4425:1: note: candidate template ignored: could not match 'basic_string<type-parameter-0-0, type-parameter-0-1, type-parameter-0-2>' against 'char const[3]'
operator<<(basic_ostream<_CharT, _Traits>& __os,
^
/usr/include/c++/v1/regex:5320:1: note: candidate template ignored: could not match 'sub_match<type-parameter-0-2>' against 'char const[3]'
operator<<(basic_ostream<_CharT, _ST>& __os, const sub_match<_BiIter>& __m)
^
EquationTags.cc:75:40: error: use of undeclared identifier 'endl'; did you mean 'end'?
<< key << " " << value << endl;
^~~~
end
/usr/include/c++/v1/initializer_list:108:1: note: 'end' declared here
end(initializer_list<_Ep> __il) _NOEXCEPT
^
EquationTags.cc:81:10: error: invalid operands to binary expression ('std::ostream' (aka 'basic_ostream<char>') and 'const char [22]')
output << "M_.equations_tags = {" << endl;
~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~
```
Dynare-5.0
clang-12
FreeBSD 13https://git.dynare.org/Dynare/dynare/-/issues/1831Investigate warning in run_all_unitary_tests.m2022-01-03T17:04:41ZJohannes PfeiferInvestigate warning in run_all_unitary_tests.mThe log contains:
>Warning: using insecure memory!The log contains:
>Warning: using insecure memory!5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1830dynare_version: add release date string as second output argument2022-01-11T12:02:50ZJohannes Pfeiferdynare_version: add release date string as second output argumentWill allow identifying whether a version on the stable branch is before or after the stable release. The second output should follow the logic of the unstable versions, e.gg.
```
5.0-2021-12-24
```Will allow identifying whether a version on the stable branch is before or after the stable release. The second output should follow the logic of the unstable versions, e.gg.
```
5.0-2021-12-24
```5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1829occbin_write_regime: periods option2023-10-02T15:46:52ZMarco Rattooccbin_write_regime: periods optionthe scope and use of the option is not to select for which periods to save the occasionally binding regimes, but to provide a more informative label to the periods, i.e. dates or real numbers representing years and quarters.
this is in f...the scope and use of the option is not to select for which periods to save the occasionally binding regimes, but to provide a more informative label to the periods, i.e. dates or real numbers representing years and quarters.
this is in fact the behaviour of the function which prints any array T that is user provided.
So, I would suggest to allow for `periods` option to have not only integers, but also real, if not also dates arrays.https://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 Villemot