dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-09-13T08:46:33Zhttps://git.dynare.org/Dynare/dynare/-/issues/1786Check iterative OLS and NLS estimation approaches for the estimation of the P...2021-09-13T08:46:33ZStéphane Adjemianstepan@adjemian.euCheck iterative OLS and NLS estimation approaches for the estimation of the PAC equationThe sum of square residuals should always be smaller (provided that the optimization algorithm does not fail or reach a local minimum) with NLS. Conduct a Monte-Carlo exercise to check that this is what we observe.The sum of square residuals should always be smaller (provided that the optimization algorithm does not fail or reach a local minimum) with NLS. Conduct a Monte-Carlo exercise to check that this is what we observe.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1785Add structural VAR model as an auxiliary model for VAR based expectations and...2021-09-13T08:44:21ZStéphane Adjemianstepan@adjemian.euAdd structural VAR model as an auxiliary model for VAR based expectations and PAC equations2021-09-10https://git.dynare.org/Dynare/dynare/-/issues/1784Output updated_covariance from smoother2023-11-10T15:04:55ZMarco RattoOutput updated_covariance from smoothermore on 551917581fba7858f8f590c508b791716a1ace37, I have a question:
- we are issuing in `oo_.Smoother.Variance` the one step ahead variance of variables `V(t+1|t)`. this is in principle a duplicate of the `FilteredVariablesKStepAheadVar...more on 551917581fba7858f8f590c508b791716a1ace37, I have a question:
- we are issuing in `oo_.Smoother.Variance` the one step ahead variance of variables `V(t+1|t)`. this is in principle a duplicate of the `FilteredVariablesKStepAheadVariances`, for k=1.
- we are issuing in `oo_.Smoother.State_uncertainty` the smoother covariances `V(t|T)`
- we are not issuing the updated covariances `V(t|t)`: should we also provide this?
`V(t|t)` would be available already from `matlab/missing_DiffuseKalmanSmootherH3_Z.m` (`P` variable), while for `matlab/missing_DiffuseKalmanSmootherH1_Z.m` it is not (should be computed on purpose).7.xJohannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1783bug with auxiliary exo lags with loglinear2021-05-11T16:52:22ZMarco Rattobug with auxiliary exo lags with loglinearIn the new unit test `fs2000_het.mod`, (merge request !1844), I added a shock to the model to test `heteroskedastic_shocks`. doing that I noted a bug at the interaction between loglinear and auxiliary exo lag variables.
It turns out that...In the new unit test `fs2000_het.mod`, (merge request !1844), I added a shock to the model to test `heteroskedastic_shocks`. doing that I noted a bug at the interaction between loglinear and auxiliary exo lag variables.
It turns out that this modified mod file triggers an auxiliary lagged exo variable.
for this variable, ys is set to zero, which is then logged in `store_smoother_results`, resulting in inf's for that variable in `oo_.SmoothedVariables` etc.
Moreover, running forecast after that, this triggers nan for all forecasted variables.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1782Fix model_local_variable command2021-04-20T12:06:37ZJohannes PfeiferFix model_local_variable commandThe file [SW2007_4Forum.mod](/uploads/331476d7971f9497341297d7ee97f238/SW2007_4Forum.mod)
returns
`terminate called after throwing an instance of 'DataTree::UnknownLocalVariableException'`
See also https://forum.dynare.org/t/tex-output...The file [SW2007_4Forum.mod](/uploads/331476d7971f9497341297d7ee97f238/SW2007_4Forum.mod)
returns
`terminate called after throwing an instance of 'DataTree::UnknownLocalVariableException'`
See also https://forum.dynare.org/t/tex-output-unwanted-subscript-t/160725.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1781Check correctness of optimal policy with linear model2021-05-31T13:30:20ZJohannes PfeiferCheck correctness of optimal policy with linear model`stoch_simul` locally sets
if options_.order~=1 && M_.hessian_eq_zero
options_.order = 1;
However, `M_.hessian_eq_zero` only seems to apply to the original model, not the nonlinear one resulting from e.g. `ramsey_model`.
On top o...`stoch_simul` locally sets
if options_.order~=1 && M_.hessian_eq_zero
options_.order = 1;
However, `M_.hessian_eq_zero` only seems to apply to the original model, not the nonlinear one resulting from e.g. `ramsey_model`.
On top of that, the change is local, so `evaluate_planner_objective` will crash, because it expects `order=2`.
The same will happen when declaring `model(linear)`. Note that an additional check is in `stochastic_solvers`.
An example is
[ramsey_test.mod](/uploads/452ae65f88b2dde038ab7a844ec429ed/ramsey_test.mod)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/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/1778Identification toolbox: support measurement errors2023-12-14T20:01:47ZWilli Mutschlerwilli@mutschler.euIdentification toolbox: support measurement errorsThe identification toolbox should be able to support measurement errors.The identification toolbox should be able to support measurement errors.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1777Pruned theoretical moments: provide a more detailed decomposition of effects2023-09-27T15:17:17ZWilli Mutschlerwilli@mutschler.euPruned theoretical moments: provide a more detailed decomposition of effectsI think we should provide a more detailed decomposition of theoretical unconditional moments at higher-order with pruning as there might be huge differences between e.g. the second and third order system's moments. So something similar t...I think we should provide a more detailed decomposition of theoretical unconditional moments at higher-order with pruning as there might be huge differences between e.g. the second and third order system's moments. So something similar to the output of the `nlma` toolbox:
```sh
THEORETICAL MEAN
VARIABLE MEAN(1st Order Accurate) MEAN(2nd and 3rd Order Accurate)
c 4.8675 29.9263
y 4.8675 29.9263
MEAN(2nd and 3rd Order Accurate) DECOMPOSITION IN LEVEL
VARIABLE Mean(2nd and 3rd Order Accurate) Det. Steady State Risk Adj. from Var. of Future Shock Risk Adj. from Var. of Past Shock
c 29.9263 4.8675 27.8139 -2.7551
y 29.9263 4.8675 27.8139 -2.7551
THEORETICAL STANDARD DEVIATION AND VARIANCE
VARIABLE STD.(1st Order Accurate) STD.(2nd Order Accurate) STD.(3rd Order Accurate) VAR.(1st Order Accurate) VAR.(2nd Order Accurate) VAR.(3rd Order Accurate)
c 14.8060 16.0911 53.0529 219.2180 258.9244 2814.6081
y 3.5188 6.8786 63.4057 12.3816 47.3149 4020.2871
THEORETICAL CORRELATIONS(1st Order Accurate)
Variables c y
c 1.0000 0.5852
y 0.5852 1.0000
THEORETICAL CORRELATIONS(2nd Order Accurate)
Variables c y
c 1.0000 0.5201
y 0.5201 1.0000
THEORETICAL CORRELATIONS(3rd Order Accurate)
Variables c y
c 1.0000 0.8925
y 0.8925 1.0000
THEORETICAL COEFFICIENTS OF AUTOCORRELATION(1st Order Accurate)
Order 1 2 3 4 5
c 0.9602 0.9222 0.8861 0.8518 0.8191
y 0.9960 0.9919 0.9877 0.9834 0.9791
THEORETICAL COEFFICIENTS OF AUTOCORRELATION(2nd Order Accurate)
Order 1 2 3 4 5
c 0.9651 0.9319 0.9001 0.8698 0.8408
y 0.9917 0.9833 0.9747 0.9660 0.9573
THEORETICAL COEFFICIENTS OF AUTOCORRELATION(3rd Order Accurate)
Order 1 2 3 4 5
c 0.9944 0.9891 0.9839 0.9789 0.9741
y 0.9979 0.9958 0.9934 0.9909 0.9882
VARIANCE (3rd Order Accurate) DECOMPOSITION IN PERCENTAGE
VARIABLE Total Risk Adj. Total Amp. Total Risk-Amp. Interplay
c 127.42 32.41 -59.83
y 127.42 12.82 -40.24
COMPLETE VARIANCE (3rd Order Accurate) DECOMPOSITION IN PERCENTAGE
VARIABLE Total Risk Adj. 1st Order Amp. 2nd Order Incre. Amp. 3rd Order Incre. Amp. 1st-3rd Order Incre. Amp. 3rd Order Incre. Risk-Amp. Interplay 1st-3rd Order Incre. Risk-Amp. Interplay
c 127.42 7.79 1.41 22.44 0.76 -30.31 -29.51
y 127.42 0.31 0.87 10.10 1.55 -28.00 -12.24
```7.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://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/1774Manually verify analytic derivatives before major relases2024-01-17T13:47:43ZJohannes PfeiferManually verify analytic derivatives before major relasesUsing `optim = ('DerivativeCheck', 'on','FiniteDifferenceType','central')`
allows checking the correctness of analytic Jacobians for `analytic_derivatives/fs2000_analytic_derivation.mod` and `method_of_moments\RBC\RBC_MoM_GMM_gradient_op...Using `optim = ('DerivativeCheck', 'on','FiniteDifferenceType','central')`
allows checking the correctness of analytic Jacobians for `analytic_derivatives/fs2000_analytic_derivation.mod` and `method_of_moments\RBC\RBC_MoM_GMM_gradient_optim.mod`. These tests would fail as Matlab does not allow setting the tolerance lower than the default 1e-6, while we are at 1e-5. But we should nevertheless manually check whether we are within a reasonable tolerance.7.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`