dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-06-28T19:04:06Zhttps://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/1776Consistency in variable names2023-10-25T13:56:19ZWilli Mutschlerwilli@mutschler.euConsistency in variable namesI would propose to keep the names of common input and output arguments like `M_`, `options_`, `oo_`, `estim_params_`, `bayestopt_`, `dataset_`, `dataset_info`, `estimation_info` consistent throughout the code base. For instance in `dsge_...I would propose to keep the names of common input and output arguments like `M_`, `options_`, `oo_`, `estim_params_`, `bayestopt_`, `dataset_`, `dataset_info`, `estimation_info` consistent throughout the code base. For instance in `dsge_likelihood.m`, `dsge_var_likelihood.m`, `non_linear_dsge_likelihood` or in the functions of the identification toolbox we use names like `DynareOptions`, or `options` (without underscore). So maybe, right before we release 6.x, we could make the names consistent? This would be a simple text search and replace, but everyone would then need to rebase local branches to this.
I think these are the most important variables (feel free to add to this list):
- `M_`
- `options_`
- `oo_`
- `estim_params_`
- `bayestopt_`
- `dataset_`
- `dataset_info`
- `estimation_info`6.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://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 Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1763Ramsey: document potential problems with auxiliary variables for timeless per...2021-08-17T10:24:37ZJohannes PfeiferRamsey: document potential problems with auxiliary variables for timeless perspectiveSee https://forum.dynare.org/t/timing-perfect-foresight-ramsey/17157/16See https://forum.dynare.org/t/timing-perfect-foresight-ramsey/17157/165.xhttps://git.dynare.org/Dynare/dynare/-/issues/1762set_auxiliary_variables function doesn't handle exogenous variables correctly2021-01-11T14:41:53ZMichelJuillardset_auxiliary_variables function doesn't handle exogenous variables correctlyCurrently the signature of ``set_auxiliary_variables`` function is
```
y = <modname>_set_auxiliary_variables(y, x, params).
```
When there are auxiliary exogenous variables the updated value of ``x`` isn't returned.
1. return [y, x]
2. m...Currently the signature of ``set_auxiliary_variables`` function is
```
y = <modname>_set_auxiliary_variables(y, x, params).
```
When there are auxiliary exogenous variables the updated value of ``x`` isn't returned.
1. return [y, x]
2. modify existing Matlab code calling the function
3. The Julia version of the this function should modify ``y`` and ``x`` in place and not return anythinghttps://git.dynare.org/Dynare/dynare/-/issues/1761Method of Moments mode_compute 11 and 122021-01-13T14:59:36ZWilli Mutschlerwilli@mutschler.euMethod of Moments mode_compute 11 and 12In merge request !1799 I added a test mod file RBC_MoM_optimizer.mod which runs through all optimizers to check whether the call to the optimizers succeeds. For mode_compute=11 and mode_compute=12, at least for me, there is an error.In merge request !1799 I added a test mod file RBC_MoM_optimizer.mod which runs through all optimizers to check whether the call to the optimizers succeeds. For mode_compute=11 and mode_compute=12, at least for me, there is an error.5.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1760issue on dynare.jl repo is tracked?2021-01-05T21:22:58ZFlorian Oswaldissue on dynare.jl repo is tracked?hi all,
sorry for cross posting this here but i [left an issue](https://git.dynare.org/Dynare/Dynare.jl/-/issues/5) on the julia version repo and I'm a bit worried it won't get picked up (I had trouble finding it again myself from the D...hi all,
sorry for cross posting this here but i [left an issue](https://git.dynare.org/Dynare/Dynare.jl/-/issues/5) on the julia version repo and I'm a bit worried it won't get picked up (I had trouble finding it again myself from the Dynare.jl dashboard, so...)https://git.dynare.org/Dynare/dynare/-/issues/1759Decide whether to drop Windows 7 support2021-11-16T16:29:57ZSébastien VillemotDecide whether to drop Windows 7 supportCurrently, we officially support three versions of Windows: 7, 8.1 and 10.
Mainstream support for Windows 7 expired on 2015, and extended support expired on January 2020.
Until January 2023, Microsoft still provides so-called “Extended...Currently, we officially support three versions of Windows: 7, 8.1 and 10.
Mainstream support for Windows 7 expired on 2015, and extended support expired on January 2020.
Until January 2023, Microsoft still provides so-called “Extended Security Updates”, but this requires a paid subscription (which is probably quite expensive, and thus only accessible to large institutions).
The decision to drop official Dynare support for Windows 7 therefore mostly depends on whether our institutional users have already moved away from Windows 7, or are still postponing the inevitable upgrade.
Note that dropping support for Windows 7 does not mean that Dynare would stop working on that platform (at least until we introduce some breaking change). It simply means that there would be no testing and no guarantee of functionality on that platform.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1757Fix dynare_estimation_1 for order>12021-01-25T18:34:24ZJohannes PfeiferFix dynare_estimation_1 for order>1Particle filter estimation was simply plugged into `dynare_estimation_1`. Many routines can be recycled, but we need to be more careful to check that outputs are really correct at `order>1`. For example, we will return smoother results b...Particle filter estimation was simply plugged into `dynare_estimation_1`. Many routines can be recycled, but we need to be more careful to check that outputs are really correct at `order>1`. For example, we will return smoother results based on a Kalman smoother instead of a particle smoother.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1756Decide what to do with options_.particles.pruning2021-01-25T18:34:24ZJohannes PfeiferDecide what to do with options_.particles.pruningI am having trouble with the `options_.particles.pruning`-option. It is used within the particle filter routines, but currently not inherited for the use of `simult_` in e.g. `non_linear_dsge_likelihood` or `irf.m`. I actually don't see ...I am having trouble with the `options_.particles.pruning`-option. It is used within the particle filter routines, but currently not inherited for the use of `simult_` in e.g. `non_linear_dsge_likelihood` or `irf.m`. I actually don't see why we need that as a separate option of `particles`. I would prefer to have `options_.pruning` and have `particles` rely on it. Or to stay within the module-logic, have `options_.pruning` inherit `options_.particles.pruning`.5.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1755bug in variable_mapping for Ramsey optimal policy2020-12-09T17:44:43ZMichelJuillardbug in variable_mapping for Ramsey optimal policyIn the preprocessor, for a model using ramsey_model(), variableMapping is empty and in JSON file the field variable_mapping is incomplete. I attach an example generating the problem when run with
```
dynare_m cgg_ramsey.mod json=compute
...In the preprocessor, for a model using ramsey_model(), variableMapping is empty and in JSON file the field variable_mapping is incomplete. I attach an example generating the problem when run with
```
dynare_m cgg_ramsey.mod json=compute
```
[cgg_ramsey.mod](/uploads/a2f584ba20aa90e661a476ee1273a546/cgg_ramsey.mod)5.xSébastien VillemotSébastien Villemot