Stoch_simul after estimation with MH algorithm uses mode


I execute estimation and simulation of my model by

estimation(datafile=usmodel_data,mode_compute=6,first_obs=68,nobs=176,presample=4,lik_init=2,prefilter=0,mh_replic=100000,mh_nblocks=2,mh_jscale=0.20,mh_drop=0.2,nodisplay,mode_check,bayesian_irf) y labobs pinfobs c robs rk kp k pk inve w mc gamma;

stoch_simul(conditional_variance_decomposition=[1 4 8],nodisplay) y labobs pinfobs c robs rk kp k pk inve w mc gamma dy dc dinve;

I gather from the manual and forum discussions that stoch_simul uses the posterior mean if executed after estimation that involves the Metropolis-Hastings algorithm. However, the policy and transition functions, the IRFs stored in oo_.irfs, the theoretical moments, the variance decompositions, etc. are all based on the mode.

Do I miss something obvious? If not, I’m happy to provide more details including the mod-file.

Thank you very much for your time!

Best, Christian

dynare_estimation_1.m contains the code

[quote] xparam = get_posterior_parameters(‘mean’);
M_ = set_all_parameters(xparam,estim_params_,M_);

which sets the parameters to the mean. So I don’t see how what you describe can happen. Please provide me with the files to replicate the issue.

Please find attached the mod file and the data file as well as the log file of my last run (for which I set the MH replications to only 2000). The problem seems to persist.

Thank you! (26.4 KB)

I ran your code and got the mode

prior mean mode s.d. prior pstdev

crhoa 0.500 0.9604 0.0138 beta 0.2000 [/quote]

and from the MCMC


Log data density is -1033.335028.

prior mean post. mean 90% HPD interval prior pstdev

crhoa 0.500 0.9574 0.9390 0.9767 beta 0.2000[/quote]

When now checking the value of M_.params at the end of your mod-file I get

is equal to

[quote]ans = 0.9574

which clearly is the posterior mean, not the mode.

Thank you for your response!

Still, it seems to me that, after estimation, the log-file reports the policy and transition function based on the mode and the IRFs saved in oo_.irfs are based on the mode as well.

If I calibrate my model at the estimated mode and run a simple simulation, I get exactly the same policy and transition functions as well as IRFs that I get after calling stoch_simul after estimation. To verify that claim please find attached a zip-file containing:

  • the mod-file of the estimated model
  • the log file of running this mod file (which at the end seems to report the policy functions based on the mode)
  • the mod-file of the model calibrated at the mode
  • the log file of running tis mod file (which at the end reports the same policy functions as before)
  • a text file containing one IRF for the simulated model (taken from the workspace) and for the estimated model (taken from oo_.irfs). They are the same.

Thank you!
Best, Chr. (22.1 KB)

But the IRFs are not identical in the text-file. There are small differences. Given that the posterior mean and the posterior mode are really similar in your case, what makes you think that the mode is erroneously used?

I think the differences might be rounding errors. The IRFs based on the posterior mean are more different. Please find attached files that now also include the simulation for the posterior mean. Comparing the files suggests that Dynare reports, after the estimation, the IRFs and policy functions based on the mode and not the mean.

Best, Christian (28.5 KB)

Can you please provide your mode-file. I still cannot replicate the issue.

My previous post included the file ‘’. It includes the file ‘ExoG_Estimation.mod’ which, after execution, produces the file ‘ExoG_Estimation.log’ which was also attached.

I am pretty sure that the policy and transition functions of this log-file and the IRFs saved in oo_.irfs are based on the mode and not the mean. I arrive at this conclusion after simulating the model at the mode and at the mean and comparing these to the simulation after estimation.

When you say that you cannot replicate this issue, this, then, has to mean that you get a log-file after running ‘ExoG_Estimation.mod’ which is different from the one I have posted. Is that the case? If this is the case I will try to run it on a different computer.

Thank you for your time!

I already got a different mode than you. Thar’s why I asked for the mode-file, not the mod-file.

Ok, sorry I missunderstood. Attached a few files that are generated when I run ExoG_Estimation.mod including the mode file.

Thank you! (28.8 KB)

Hi Johannes,
many thanks for responding to Christian’s post so quickly. I would just like to ad one more thing: The point Christian is making can also be seen from the ExoG_Estimation.log file included in (which as your probably already noticed is associated with the estimation of a Smets-Wouters model). We know from the measurement equations of the model that the intercept of the Policy and Transition equation has to equal constelab. Line 182 reports approximate estimate of the mode of constelab (i.e. before the MH algorithm is started to generate the full posterior distribution), which equals 0.4142. It is thus identical to the intercept of laobs in the policy and transition function (see line 303, column 45). By contrast, the posterior mean equals 0.8987 (see line 262). The same is true for constepinf. This very much suggests that dynare is uses the (pre-MH algorithm approximation of) the posterior mode to calculate the policy and transition functions.

Let us know what you think!

Which Dynare version exactly are you using?

Hi Johannes,
4.4.3 (as it says at the top of the .log file).

sorry, this took a lot longer to sort out than expected. In Dynare 4.4.3 there is indeed a bug:

It turns out that the smoother also resets the global variable to the posterior model.
If you don’t want to use the unstable version, you can alter the lines

xparam = get_posterior_parameters('mean'); M_ = set_all_parameters(xparam,estim_params_,M_);
in dynare_estimation_1.m to

xparam1 = get_posterior_parameters('mean'); M_ = set_all_parameters(xparam1,estim_params_,M_);

I updated the description of the bug. Thanks for pointing this out.

Hi Johannes,
thanks a lot your help, and the service to the profession you are providing here.