I am doing a stoch_simul at the mode of the posterior distribution using the commands
estimation(graph_format= (pdf, fig), plot_priors=0,mode_file=mcmcmode,datafile= data1993q1to2018q2, mh_replic=0, mode_compute=0);
stoch_simul(irf=41) aw ac aik aih g ax am armon arh as aph lnmig pxstar pmstar ;
Dynare 4.5.6 loads the mode file (which was also used for successful MCMC and bayesian IRFS) and then produces the figures for smoothed shocks, but then the Blanchard-Kahn indeterminacy happens.
This is a bit bizarre because I thought Dynare only picks those parameter sets that satisfy the determinacy conditions.
MCMC works fine! So the model obviously offers a unique solution for many parameter sets!
Also, I noticed that the posterior mode estimation works well at the parameter values declared in the estimated_params_init block…However, if we do a stoch_simul using the same values for calibrating the parameters, again, I see the indeterminacy problem.
I would be interested to hear your views on this…Never encountered this problem before…
I agree this should not happen because during the estimation (mode finding step or MCMC) we reject the vectors of parameters such that BK are not satisfied (since we do not know what to do with these parameters). So the posterior mode has to be clean with respect to BK conditions.
If you call
stock_simul after the MCMC (I believe that) Dynare will use the posterior expectation for the parameters. Since this vector of parameter was not tested during the MCMC (in a class it may happen that none of the students obtain the average grade), it may happen that for this vector the BK conditions are not fulfilled… But this is not very likely and I have never encountered this situation while estimating a DSGE.
Would you mind sharing the codes? There must be something wrong somewhere, but it is difficult to say without the codes.
Thanks Stephane. I just checked doing stoch_simul after mcmc…and the same thing happened
Bayesian (posterior) IRFs… 100% done
Estimation::mcmc: Posterior (dsge) IRFs…
Estimation::mcmc: Posterior IRFs, done!
Error using print_info (line 45)
Blanchard Kahn conditions are not satisfied: indeterminacy
I will send you the code, once i make it more readable!
Thanks a lot
I think i found the problem…
In the code, there was an auxiliary variable for a kind-of expected cumulated sum
sumr1 = 0.99999999sumr1(1) - (1-h)(1-cla)/(sigma)*(rh-dpe)
The near unit-root here seems to be the problem.
When the cumulated sums were commented out in the code, the model solves nicely without given the B-K indeterminacy error.
However, it is still puzzling why the same code works fine when we use the estimation command (smoothing out the shocks, posterior mode finding, mcmc)…
I will send you the code as soon as I clean it up.
Now I get it. It is because we do not use the same threshold level to count the number of explosive and stable eigenvalues when we do the estimation and when we simulate the model. This threshold level is controlled by the value of
options_.qz_criterium. When we simulate a model (using
stoch_simul command) or compute the eigenvalues with the
check command this option is slightly greater than 1 (by default it is then equal to 1+1e-6). Meaning that by default we do accept the unit roots as stable eigenvalues (you can change this behaviour by lowering the value of
qz_criterium which is an option of
stoch_simul). When we estimate a model with the
estimation command this parameter is slightly smaller than 1 (1-1e-6 by default), except if you evaluate the likelihood with a diffuse filter. The reason is that with a starndard Kalman filter is not able to handle unit roots.
That is a very valuable insight, Stephane. A million thanks!
@stepan-a I thought this cannot happen as
qz_criterium should not be empty after
stoch_simul will only reset it if that were the case:
options_.qz_criterium = 1+1e-6;
@jpfeifer I may be wrong but I thought we reset
qz_criterium at the end of
dynare_estimation_1 (to the value before entering in the estimation stage). So when we enter in
stoch_simul after the estimation of the model,
qz_criterium is empty… I would need to check.
@stepan-a I checked. Indeed we reset
qz_criterium. That explains the difference