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/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/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/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/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/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 Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1754Add model_info for non-block models2021-09-15T16:36:15ZJohannes PfeiferAdd model_info for non-block modelsSee https://forum.dynare.org/t/perfect-foresight-model-what-variables-predetermined-and-forward-looking/17028/2 for a starting point. The main issue is auxiliary variablesSee https://forum.dynare.org/t/perfect-foresight-model-what-variables-predetermined-and-forward-looking/17028/2 for a starting point. The main issue is auxiliary variables5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1752Fix identification error with unit root observables and diffuse_filter set2020-11-26T15:41:44ZJohannes PfeiferFix identification error with unit root observables and diffuse_filter setSee [LW_NIC.mod](/uploads/79897cc6c15966c2177cda0cbad032fc/LW_NIC.mod) where the option is correctly set, but we still ask the user to set it.See [LW_NIC.mod](/uploads/79897cc6c15966c2177cda0cbad032fc/LW_NIC.mod) where the option is correctly set, but we still ask the user to set it.5.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1751Fix encoding of jnl-files2020-11-20T14:54:49ZJohannes PfeiferFix encoding of jnl-filesIt seems the date/time string given by the operating system needs to be converted to UTF-8 [example1.jnl](/uploads/65e2ab3a669e03f39e16ae8dad6fcd53/example1.jnl)It seems the date/time string given by the operating system needs to be converted to UTF-8 [example1.jnl](/uploads/65e2ab3a669e03f39e16ae8dad6fcd53/example1.jnl)5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1750Fix Octave mex-files on Windows2020-12-07T11:32:40ZJohannes PfeiferFix Octave mex-files on WindowsOn Windows 10 64bit with Octave 5.2 I am getting the error message
```
error: k_order_pert: could not find library or dependencies: C:\dynare\4.6.2\matlab../mex/octave/win64\k_order_perturbation.mex
```
when using `k_order_solver`. Most...On Windows 10 64bit with Octave 5.2 I am getting the error message
```
error: k_order_pert: could not find library or dependencies: C:\dynare\4.6.2\matlab../mex/octave/win64\k_order_perturbation.mex
```
when using `k_order_solver`. Most likely `libmatio` or `libwinpthread` are the culprits.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1749Fix testsuite for Octave2021-09-21T15:58:35ZWilli Mutschlerwilli@mutschler.euFix testsuite for OctaveOn master, some mod files do not yet run with Octave due to e.g. missing functions and other small bugs. Here is an (updated) list, when I push fixes I'll update the list:
- [x] analytic_derivatives/BrockMirman_PertParamsDerivs (on RHEL...On master, some mod files do not yet run with Octave due to e.g. missing functions and other small bugs. Here is an (updated) list, when I push fixes I'll update the list:
- [x] analytic_derivatives/BrockMirman_PertParamsDerivs (on RHEL/CentOS, but not Fedora, with KRONFLAG=-1)
- [x] estimation/method_of_moments/* (use nanmean instead of mean(x,'omitnan'; randstream not implemented in Octave;maybe other errors)
- [ ] bgp/* (many problems, probably numerical imprecision, also due to incompatibilities from and differences in toolboxes such as optim)5.xSébastien VillemotSébastien Villemot