dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-01-13T14:59:36Zhttps://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/1204Crash in unstable mex when called from parallel workers2020-11-13T13:44:38ZTom HoldenCrash in unstable mex when called from parallel workersI'm afraid I don't have time to produce a minimal example of this bug now, but I'll leave the replication steps here in case anyone else does.
1) Download my version of Dynare, with sub-modules from https://github.com/tholden/dynare
2) ...I'm afraid I don't have time to produce a minimal example of this bug now, but I'll leave the replication steps here in case anyone else does.
1) Download my version of Dynare, with sub-modules from https://github.com/tholden/dynare
2) Replace the files in the mex subfolder with those from the latest unstable.
3) Browse to the dynare\examples\nonlinear-estimation directory within MATLAB, and then execute `dynare NKNonCentralEstimate.mod`
4) Note that Dynare correctly calculates the initial likelihood, but then when it starts calculating the first numerical derivative of the likelihood, in parallel, each of the parallel workers crash in turn.
5) Reset the repository so you have my compiled MEX. Rerun the same test and observe that the parallel workers do not crash.
I would strongly expect that in fact you don't need to use my version of Dynare, or to use my code for estimating an approximation around the mean, and in the latest unstable this ought to be present whenever you evaluate the likelihood in parallel.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1724Discuss interface for method of Moments in Dynare (GMM, SMM, IRF Matching)2020-08-05T14:38:34ZWilli Mutschlerwilli@mutschler.euDiscuss interface for method of Moments in Dynare (GMM, SMM, IRF Matching)Hey,
I am working on a first draft for a toolbox for moment estimation with GMM, SMM and IRF-Matching (I will start with GMM, then SMM, and deal with IRF-matching later) which will work for perturbation (with pruning) up to third-order. ...Hey,
I am working on a first draft for a toolbox for moment estimation with GMM, SMM and IRF-Matching (I will start with GMM, then SMM, and deal with IRF-matching later) which will work for perturbation (with pruning) up to third-order. I have a couple of questions|proposal for the best interface and call for this and would like your guys take on this.
### Declaring parameters
Here I would simply opt to what we do in a Maximum likelihood estimation and use the same syntax in an `estimated_params` or an `estimated_params_bounds` block:
```
stderr VARIABLE_NAME | corr VARIABLE_NAME_1, VARIABLE_NAME_2 | PARAMETER_NAME, LOWER_BOUND, UPPER_BOUND;
```
### Declaring which moments to use
Here I would propose a block similar to `moment_calibration`, but call it `estimated_moments`:
```
estimated_moments;
y_obs,y_obs; //[unconditional variance]
y_obs,y_obs(-(1:4)); //[some acf]
@#for ilag in -2:2
y_obs,R_obs(@{ilag}); //[ccf]
@#endfor
end;
```
### Invocation
Now the toughest question. How to invoke it? I see two options.
Option A: Add an option to `estimation`, e.g.
```
estimation(moments_estimation='GMM');
```
Option B: Have an own command for this, e.g.:
```
gmm_estimation(OPTIONS);
smm_estimation(OPTIONS);
irf_matching(OPTIONS);
```
which then internally calls a wrapper `dynare_moments_estimation.m` and runs the toolbox.
What do you guys think?5.xhttps://git.dynare.org/Dynare/dynare/-/issues/251SMM: create preprocessor interface, make it compatible with Octave2020-05-28T08:57:07ZSébastien VillemotSMM: create preprocessor interface, make it compatible with OctaveIn particular, the current code is not compatible with Octave since it uses RandStream at several places.
In particular, the current code is not compatible with Octave since it uses RandStream at several places.
https://git.dynare.org/Dynare/dynare/-/issues/1673Nonlinear filters at k-order2020-02-17T09:28:31ZSébastien VillemotNonlinear filters at k-orderA MEX file for iterating in the state space (based on Dynare++) is already present in the `local_state_space_iteration_k` branch.
It needs to be tested and integrated in the estimation routines.A MEX file for iterating in the state space (based on Dynare++) is already present in the `local_state_space_iteration_k` branch.
It needs to be tested and integrated in the estimation routines.4.6Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1659Filter out non-positive definite Hessians before Laplace approximation2019-11-21T14:06:17ZJohannes PfeiferFilter out non-positive definite Hessians before Laplace approximationWe do not check whether the normal approximation underlying the Laplace approximation to the marginal data density makes any sense given the Hessian at hand. That results in wrong output, because the log determinant will be complex and M...We do not check whether the normal approximation underlying the Laplace approximation to the marginal data density makes any sense given the Hessian at hand. That results in wrong output, because the log determinant will be complex and Matlab only prints the real-valued parts.
See https://forum.dynare.org/t/hessian-matrix-at-the-mode-is-not-positive-definite-but-the-marginal-density-is-displayed-anyway/14510/3
Proposed solution: skip the computation of the Hessian is not positive semi-definite and return NaN.4.6Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/644support mcmc_* options wherever there's an mh_* option2019-11-21T08:36:45ZHoutan Bastanisupport mcmc_* options wherever there's an mh_* optionas mcmc is more general than mh. support mh_\* for backwards compatibility.
as mcmc is more general than mh. support mh_\* for backwards compatibility.
https://git.dynare.org/Dynare/dynare/-/issues/1063Make output of dsge_var_likelihood accessible2019-11-21T08:36:44ZJohannes PfeiferMake output of dsge_var_likelihood accessibleSee the discussions in http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7315 and http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2920
See the discussions in http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7315 and http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2920
https://git.dynare.org/Dynare/dynare/-/issues/1160Implement filter_covariance option in Bayesian estimation2019-11-21T08:36:41ZJohannes PfeiferImplement filter_covariance option in Bayesian estimationCurrently only possible in ML and calibrated smoother
Currently only possible in ML and calibrated smoother
https://git.dynare.org/Dynare/dynare/-/issues/1622Fix posterior_sampler_initialization>set_proposal_density_to_previous_value2019-09-07T05:27:10ZJohannes PfeiferFix posterior_sampler_initialization>set_proposal_density_to_previous_valueIn case of the `record`-structure not containing the required fields, the output argument of the private function at the bottom of the file are not set, crashing Matlab.In case of the `record`-structure not containing the required fields, the output argument of the private function at the bottom of the file are not set, crashing Matlab.https://git.dynare.org/Dynare/dynare/-/issues/400Add steady_no_check option to estimation command2019-06-19T15:38:18ZJohannes PfeiferAdd steady_no_check option to estimation command`unit_root_vars` is supposed to be deprecated by using ``diffuse_filter` instead for estimating a model with non-stationary observed variables. But estimation still checks the steady state unless it is preceded by a `steady(nocheck)` com...`unit_root_vars` is supposed to be deprecated by using ``diffuse_filter` instead for estimating a model with non-stationary observed variables. But estimation still checks the steady state unless it is preceded by a `steady(nocheck)` command that sets `options_.steadystate.nocheck` to 1. We should add an explicit option to set this option in estimation or automatically trigger it if the diffuse filter is requested. For a background, see
http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=4671
http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2813
4.4Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/414Add interface and doc to use_univariate_filters_if_singularity_is_detected op...2019-06-19T15:38:18ZSébastien VillemotAdd interface and doc to use_univariate_filters_if_singularity_is_detected optionWas added in 894b3d69f4662a1132c0f7fb50083bf982745536
Was added in 894b3d69f4662a1132c0f7fb50083bf982745536
4.4Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/430Deal with treatment of presample2019-06-19T15:38:18ZJohannes PfeiferDeal with treatment of presample#429 introduces an error messsage for non-linear estimation with a `presample` being specified. This incorrectly used the first `presample` observations to compute the likelihood despite the manual saying that they are skipped. In the lo...#429 introduces an error messsage for non-linear estimation with a `presample` being specified. This incorrectly used the first `presample` observations to compute the likelihood despite the manual saying that they are skipped. In the long-run, we might either want to actually use the presample to initialize the state matrix (e.g. as an option for initialization similar to using the ergodic state variance matrix of the linear model) or just skip the first `presample` periods by only using the observations `presample+1:end`
Another place where presample shows up is `bvar_toolbox.m`. Here we should clarify the distinction to the training sample in `options_.bvar_prior_train`
4.5https://git.dynare.org/Dynare/dynare/-/issues/435Potentially automatically detect non-stationary model and change QZ criterium2019-06-19T15:38:18ZJohannes PfeiferPotentially automatically detect non-stationary model and change QZ criteriumWhile the manual states that `kalman_algo` automatically uses the correct filter for stationary and nonstationary models, this case never seems to happen. If the user does not specify that the model is non-stationary, initial_estimation_...While the manual states that `kalman_algo` automatically uses the correct filter for stationary and nonstationary models, this case never seems to happen. If the user does not specify that the model is non-stationary, initial_estimation_checks will throw out an error, because the QZ criterium is too high for the BK conditions to be satisfied. It might be a good idea to check in `initial_estimation_checks` for the presence of a unit root, throw out a warning, and set the `qz_criterium` to 0.999999 if a unit root is detected.
4.5https://git.dynare.org/Dynare/dynare/-/issues/488dynDate substitution.2019-06-19T15:38:16ZStéphane Adjemianstepan@adjemian.eudynDate substitution.Users should not use dynDate or dynDates objects in a mod file (at least for basic usage: extraction of sub-samples or observations). For instance, one should be able to define a range as follows:
```
r = 1990Q1:2012Q3 ;
```
in the mod...Users should not use dynDate or dynDates objects in a mod file (at least for basic usage: extraction of sub-samples or observations). For instance, one should be able to define a range as follows:
```
r = 1990Q1:2012Q3 ;
```
in the mod file, and use `r` to define a subsample from a dynSeries object. Obviously, such a statement, interpreted as a matlab command by the preprocessor, would produce an error message in matlab. We need to convert occurences of dates by explicit calls to the dynDate constructor. For instance the previous statement should be replaced by
```
r = dynDate('1990Q1'):dynDate('2012Q3') ;
```
It is easy to find all the dates in a mod file a using regular expression of the form
```
[1-9][0-9]+([YyAa]|[Qq][1-4]|[Mm]([1-9]|[1][1-2])|[Ww]([1-9]|[1-4][0-9]|[5][1-2]))
```
The tricky part is that we do not want to replace all the occurences of dates: we do not want to replace dates written in dynare commands (`set_time` and `data`), in commented lines or blocks, in strings.
The matlab routine available [here](https://gist.github.com/stepan-a/6780885) does these substitutions (there is also an example [here](https://gist.github.com/stepan-a/6781075)). It would be faster and more elegant if the translation was done in the preprocessor (after the macroprocessing because dates can be defined using the macro language).
4.4Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/494Check correctness of set_parameters used in dynare_estimation_12019-06-19T15:38:16ZJohannes PfeiferCheck correctness of set_parameters used in dynare_estimation_11. `dynare_estimation_1` contains the lines
```
if ~isempty(estim_params_)
set_parameters(xparam1);
end
```
I was wondering why not `set_all_parameters` is used, which also sets the measurement error. `set_parameters` may have its...1. `dynare_estimation_1` contains the lines
```
if ~isempty(estim_params_)
set_parameters(xparam1);
end
```
I was wondering why not `set_all_parameters` is used, which also sets the measurement error. `set_parameters` may have its justification here, but I don't see why.
2. `set_parameters` sets `M_.Sigma_e`, but in contrast to `set_all_parameters` it does not use the correlation information from calibration stored in `M_.Correlation_matrix` and `M_.Correlation_matrix_ME`. This strikes me as wrong and the file thus as buggy.
This relates also to #392
4.4https://git.dynare.org/Dynare/dynare/-/issues/503Check use and precedence of jscale and document it.2019-06-19T15:38:16ZJohannes PfeiferCheck use and precedence of jscale and document it.The use of `bayestopt_.mh_jscale` and `bayestopt_.jscale` as well as `options_.mh_jscale` is confusing an potentially buggy (see also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5072). In `dynare_estimation_1` we use
```
mh_scale_...The use of `bayestopt_.mh_jscale` and `bayestopt_.jscale` as well as `options_.mh_jscale` is confusing an potentially buggy (see also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5072). In `dynare_estimation_1` we use
```
mh_scale_fname = [M_.fname '_optimal_mh_scale_parameter.mat'];
if exist(mh_scale_fname)
if options_.mode_compute == 0
tmp = load(mh_scale_fname,'Scale');
bayestopt_.mh_jscale = tmp.Scale;
clear tmp;
else
% remove the file if mode_compute ~= 0
delete('mh_scale_fname')
end
end
```
to read out the `mh_jscale` from a previous run of `mode_compute=6`. But this is after `dynare_estimation_init` where the `mh_jscale` seems to be translated into the `bayestopt_.jscale` actually used in estimation. Thus, it looks as if this statement does nothing.
4.5Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/504Discuss and document the load_mh_file option2019-06-19T15:38:16ZJohannes PfeiferDiscuss and document the load_mh_file optionThe current behavior of the `load_mh_file`-option with it recomputing the mode, the Hessian, and the scale-factor by default seems counterintuitive. Given the fixed seed, one should get the same results, but there is the risk of them cha...The current behavior of the `load_mh_file`-option with it recomputing the mode, the Hessian, and the scale-factor by default seems counterintuitive. Given the fixed seed, one should get the same results, but there is the risk of them changing between the reloaded chain and the new elements to be added and thus having a chain with difffering proposal densities. We should at least document this behavior and potentially reload the mode-file by default. See also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5051
4.5https://git.dynare.org/Dynare/dynare/-/issues/519mode_compute consistency check2019-06-19T15:38:16ZMichelJuillardmode_compute consistency checkIn unstable, we have added a check that reports an error if the parameters contained in a previously computed mode don't match the list of currently estimated ones.
Some users (Christiano, Motto, Rostagno, 2013, public code for Risk Shoc...In unstable, we have added a check that reports an error if the parameters contained in a previously computed mode don't match the list of currently estimated ones.
Some users (Christiano, Motto, Rostagno, 2013, public code for Risk Shocks, AER) rely on the behavior of version 4.3.2 that didn't perform this check.
I suggest to transform the error in warning and use the prior mean to initialize estimated parameters that are missing in the previously computed mode.
4.4Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/521Check treatment of covariances in DSGE-VAR2019-06-19T15:38:16ZJohannes PfeiferCheck treatment of covariances in DSGE-VARIn the wake of #392, #494, and #511 various issues with parameter updating around covariance matrices have been detected. None of these changes have been ported to `DsgeVarLikelihood` as the file still contains a TODO list in the comment...In the wake of #392, #494, and #511 various issues with parameter updating around covariance matrices have been detected. None of these changes have been ported to `DsgeVarLikelihood` as the file still contains a TODO list in the comments that suggests that bigger changes are required.
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.eu