Dynare 4.4.3 and unstable versions

[sadia]

Dear Johannes,

It looks like the same mod file can give different results in Dynare 4.4.3 and in unstable versions. The posterior estimates are slightly different but acceptance ratio in each chain varies a lot. Is it unusual? I was estimating a linear dsge model. I do not know much about inside technicalities of Dynare.
First, I used Dynare 4.4.3 in Mac and found that in theoretical moments median covariances are all zero, although mean covariances are there. Then I estimated the same model in unstable version in windows. In the latter case, both median and mean covariances are there. Parameter estimates are slightly different. Acceptance ratios are also different. Is this an indication of problem in my work?

Thanks,

Sadia

[jpfeifer]

Could you please provide me with the file?

1. Due to randomness of the MCMC slight differences in posterior estimates are normal. These should vanish with more draws.
2. I don't know which change affects acceptance rates. I have to check.
3. That median covariances are not there sounds like a bug in 4.4.3. Again, I would have to check.

[sadia]

Please find attached. IRFs also look different in some cases. I once changed the mh_j_scale to improve the acceptance ratio because keeping them produced very low ratio in unstable version. Other wise specifications were same. Thanks.

[jpfeifer]

1. We changed the way the jscale-parameter is treated. That should explain the difference in acceptance rates
2. The different IRFs may be due to different to different modes being found. Have you checked whether they are different?
3. Thanks for reporting the 0 covariances. It helped identifying a bug in Dynare 4.4.3 that is in principle still present in the unstable version (https://github.com/DynareTeam/dynare/pull/1423). However, in the unstable version, you would need a model orders of magnitude bigger than yours to actually trigger this bug.

[sadia]

2. I checked modes, they were different. Slight different magnitudes of IRFs may not be problematic but moving totally different direction is indeed problematic.
3. Median covariance: Yes, when I estimate a shorter version of the model there is no such problem in Dynare 4.4.3. The problems appears with the bigger model. Also the calculated mean covariances are different than those calculated in unstable version. It looks like calculating moments is a tricky part in Dynare.

So, in this case should I rely on unstable version more? I think although 4.4.3 reports mean covariances, they aren't reliable as it failed to calculate their mean measure.

Thanks.

[jpfeifer]

2. Then you should use the unstable version with the mode of the highest posterior density.
3. No, calculating moments per se is not a problem. The problem is the bug in version 4.4.3.

Yes, you should use the unstable version due to numerous bugs having been fixed (see http://www.dynare.org/DynareWiki/KnownBugs). Note that the above bug does affect both median and mean covariances. It is only for the median where you could easily spot the problem.

[sadia]

Dear Johannes,

My post is lengthy, sorry about that and please read when you have time.

1.Is using

Code: Select all

mode_file

option in estimation with a mode file from a previous estimation same as using

Code: Select all

estimated_params_init(use_calibration)

with calibrated values in parameter block taken from modes of a previous estimation?
2. Using filename_mode.mat file from the previous round estimation sequentially in mode_file option in current round estimation should produce different results? I read previous discussion http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5866 but not sure.
3. Someone told me to use higher value for investment adj cost parameter to reduce investment volatility. So I wanted to use:

Code: Select all

tau, normal_pdf, 2, 0.05;

instead of

Code: Select all

tau, normal_pdf, 0.67, 0.05;

. It returns an error

Code: Select all

Error using check_prior_bounds (line 39)
Initial value(s) of tau are outside parameter bounds. Potentially, you should set prior_trunc=0. If you used the mode_file-option, check whether your mode-file is consistent with the priors.

So I set

Code: Select all

options_.prior_trunc=0;

. Although it runs, but says parameter values are not compatible with some equations:

Code: Select all

"STEADY:  numerical initial values or parameters incompatible with the following equations
    17    23

Check whether your model is truly linear. Put "resid(1);" before "steady;" to see the problematic equations.\n

.
I guess this is due to using

Code: Select all

prior_trunc=0

?

4. When observing wage price index, w_obs, that has missing values with endogenous_prior option, I get

Code: Select all

Error using print_info (line 114)
Prior density is not a number (NaN)
Error in print_info (line 114)
        error('Prior density is not a number (NaN)');
Error in initial_estimation_checks (line 169)
    print_info(info, DynareOptions.noprint, DynareOptions)
Error in dynare_estimation_1 (line 149)
    oo_ =
  initial_estimation_checks(objective_function,xparam1,dataset_,dataset_info,M_,estim_params_,options_,bayestopt_,bounds,oo_);
   
Error in dynare_estimation (line 105)
    dynare_estimation_1(var_list,dname);

Error in model (line 901)
oo_recursive_=dynare_estimation(var_list_);

Error in dynare (line 223)
evalin('base',fname) ;


But estimation works without any trouble with w_obs if I don't use endogenous_prior option. Is missing value in a series can be a problem with this option?
Thanks,

Sadia

[jpfeifer]

1. Yes, the two should be equivalent
2. If you found the true mode already in the first round, there should be no difference. Otherwise, you hope for an improvement in the posterior density.
3. I would need to see the mod-file to reproduce the issue. Given the narrow standard deviation, I am not surprised that shifting the mean so far up creates problems with the old posterior value. But I am a bit surprised why this shows up as a problem in steady state computation.
4. Indeed,

Code: Select all

endogenous_prior

does not yet support missing values.

[sadia]

1, 2. I tested them and wanted to be confirmed from you. I found similar to what you said. Thanks for this.

3. After using wider prior for that parameter, I don't need to use truncation option. And the associated warning message relating to steady does not show up today. So, I am not going further with the previous warning message at the moment.

Thanks again, Johannes. Have a nice weekend!