dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2022-04-21T19:45:03Zhttps://git.dynare.org/Dynare/dynare/-/issues/1531Add interface for flexible IRF-generation2022-04-21T19:45:03ZJohannes PfeiferAdd interface for flexible IRF-generationCreate block
```
generate_irfs(options_list);
(groupname1), exo_name1=1, exo_name 2=-0.5;
(groupname2), exo_name1=2, exo_name 3=-0.5;
end;
```
or alternatively (as suggested in #115 )
```
generate_irfs(options_list);
[ name='gr...Create block
```
generate_irfs(options_list);
(groupname1), exo_name1=1, exo_name 2=-0.5;
(groupname2), exo_name1=2, exo_name 3=-0.5;
end;
```
or alternatively (as suggested in #115 )
```
generate_irfs(options_list);
[ name='groupname1' ] exo_name1=1, exo_name 2=-0.5;
[ name='groupname1' ] exo_name1=2, exo_name 3=-0.5;
end;
```
where `options_list` can be (for now)
- `stderr_multiples` translating to `options_.irf_opt.stderr_multiples`
- `diagonal_only` translating to `options_.irf_opt.diagonal_only`
and where each line translates into
1. a cell array `options_.irf_opt.irf_shock_graphtitles` storing the group_name along the rows
2. a column of a matrix `options_.irf_opt.irf_shocks` of size M_.exo_nbr*n_lines where non-specified `var_exo` get a 0 entry.
If no line is provided, leave those fields empty.
The block translates into
1. setting of options_
2. a call to `oo_.irfs=generate_irfs(M_,options_,oo_)`4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1532Factorize IRF code into function generate_irfs(M_,options_,oo_)2022-04-21T19:45:02ZJohannes PfeiferFactorize IRF code into function generate_irfs(M_,options_,oo_)Take the fragmented codes from `stoch_simul` and `PosteriorIRFcore1` and put them into one function that is used in those other commands, but can also be called as a standalone. Related to #1531.Take the fragmented codes from `stoch_simul` and `PosteriorIRFcore1` and put them into one function that is used in those other commands, but can also be called as a standalone. Related to #1531.Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/116IRF: give the possibility to choose the starting point (at least at order 2 a...2022-04-21T19:44:12ZSébastien VillemotIRF: give the possibility to choose the starting point (at least at order 2 and above)In particular, give the possibility to start from the stochastic steady stateIn particular, give the possibility to start from the stochastic steady stateJohannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/115IRF: add the possibility to change the size of the shocks in the computations2022-04-21T19:43:09ZSébastien VillemotIRF: add the possibility to change the size of the shocks in the computationsAt order 1, it is equivalent to changing the standard deviation of the shocks and adding the corresponding inverse transformation in the equations.
But at orders 2 and above, the equivalence does not hold.At order 1, it is equivalent to changing the standard deviation of the shocks and adding the corresponding inverse transformation in the equations.
But at orders 2 and above, the equivalence does not hold.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/1848Problems of the example for Occbin mod file2022-03-28T13:51:52Zsongkaihonglalala704156579@qq.comProblems of the example for Occbin mod filein the mod file, the euler equation (or equation 1 with relax), we only assume the investment equation is not binding in the current period, but in your codes it seems assume both current and next period the INEG condition is relaxed. I ...in the mod file, the euler equation (or equation 1 with relax), we only assume the investment equation is not binding in the current period, but in your codes it seems assume both current and next period the INEG condition is relaxed. I think this is a mistake and looking forward to your reply.https://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/1802Write Fortran k-order simulation routine2022-02-23T15:36:27ZJohannes PfeiferWrite Fortran k-order simulation routineThis is required as the Dynare++ routines have a heavy overhead. It should be used to replace `local_state_space_iteration` (https://git.dynare.org/Dynare/dynare/-/issues/1773) and will be used for simulated moments in the context of hig...This is required as the Dynare++ routines have a heavy overhead. It should be used to replace `local_state_space_iteration` (https://git.dynare.org/Dynare/dynare/-/issues/1773) and will be used for simulated moments in the context of higher-order welfare (https://git.dynare.org/Dynare/dynare/-/merge_requests/1866).6.xNormann RionNormann Rionhttps://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/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/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/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/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/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/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/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/1826occbin: allow more general formulas for constraints2021-12-11T17:50:17ZMarco Rattooccbin: allow more general formulas for constraintscurrently it is not possible to define constraints like:
```
bind logical((a>0).*(b>0))>0;
```
since preprocessor impedes the use of .* in the definition
since a and b are time series, then the evaluation of the constraint goes wrong ...currently it is not possible to define constraints like:
```
bind logical((a>0).*(b>0))>0;
```
since preprocessor impedes the use of .* in the definition
since a and b are time series, then the evaluation of the constraint goes wrong since we are multiplying two vectors.
would this be something doable?Sébastien VillemotSébastien Villemot