I am using Bayesian estimation to estimate some parameter and shock values and calibrate some other parameter values. I use the commands in the estimation block as following:

estimation(datafile=trial_data, mode_compute = 6, mh_nblocks = 2,moments_varendo,conditional_variance_decomposition=[1 2 4 8], mh_replic=50000, conf_sig=0.95, bayesian_irf)y n pi_c_h r c i_d;

However, I get bad convergence result with regards to the red line and blue line. To be more specific, the red line and the blue line can get convergence for the shock parameters, but do not converge for the the coefficients of the shock process and other parameters.

Q1: Is there any method to improve the convergence results? I noticed that in this forum, someone use the posterior mean as the initial value to start a new estimation round. If it helps, should I replace all the estimated parameter values or just the parameters of bad convergence results?
If it does not help, are there any other ways to do? Increase the number of replication or try other mode computation method?

Q2: I am confused about the difference between the parameters which need to be estimated in the parameters block and those in the estimated params block. I know that Dynare will take the parameterization before the model-block as the starting point and keep those parameters at their values unless they are estimated using the estimated_params-block. Does it mean that the parameter values in the parameters block is the same as the initial value in the estimated params block? If not, what’s the difference between the value in the parameters block and the initial value in the estimated param block? Because I fount that in some schlar’s code, the value in the parameters block is different from the corresponding initial value in the estimated params block.

Q1. Just use the mh_mode file as the mode_file for a new estimation run. A lot of additional draws should also help. Also, have you checked identification?

Q2. Parameters initialized in the estimated_params or estim_params_init block overwrite the values initialized in the parameters declaration. It is common practice to set both to your best guess of what the correct parameter is. But there is no other reason they should be the same.
If you are interested in e.g. the IRF for rho=0.9, because you put stoch_simul before estimation, it might make sense to start estimation at a different values you consider more likely. In that case, the parameter values will differ

However, I am still a bit confused about the Q1. Using the mh_mode file as the mode_file for a new estimation run just remain the posterior mode constant. If my understanding is right, do I need to replace all the initial value of estimated parameters by the posterior mean for a new estimation run? If it helps, should I replace all the estimated parameter values or just the parameters of bad convergence results?

In addition, I will check that whether all the parameters are identified using the “identification” command. If I find that some parameters are not identified, I should calibrate the corresponding parameter? Am I right?

The mh_mode file is the mode after the MCMC run, not after mode-finding. Using it as the mode_file and them running mode-finding again (potentially with a different mode-finder) should increase your chances of finding a better mode and getting quicker convergence. If your posterior mode stays constant, your mode-finder most probably got stuck. Otherwise, the issue is not about convergence of the chains to the same mode, but about mixing. In that case, you might want to try using a user-defined jumping covariance matrix.

Since I am not good at program coding, I am not able to change the file that creates the mh_mode file according to your suggestion. Can you explain the method in a bit more detail? Does it need to code in Matlab command window directly?

Besides, I tried to set mode_file = code_mode, mode_compute = 6, and run my program, I found that the convergence improved a lot. Is this result reliable?

Thanks for your help. And I notice that in the dynare manual, it is said that loan_mh_file is to tell dynare to add to previous MH simulations instead of starting from scratch. Does this command have the same meaning as your suggestion?

Although I have fixed the convergence problem, the impulse response functions’ graphs seem weird. The impulse response seems to fluctuate up and down around the some values, for example, zero, rather than to smooth back to the steady state. Is this result reliable? If not, what’s the problem and how to fix it?

Your estimate implies a complex eigenvalue, leading to oscillatory behavior. These type of oscillations are very uncommon in economics, so something is most problabyl still wrong. Unfortunately, it is impossible to tell what. Anything that affects your estimation results from wrong equations (for example wrong timing in feedback equations) to non-convergence can lead to this issue.

As for the complex eigenvalue, I guess it may be related to the mode file. Because before I use the mode file of last estimation round as the mode file for a new estimation run, the impulse response is normal, even though the convergence problem remains unsolved. But when I fixed the convergence problem, the impulse response became weird. So do you have any idea about it?

Besides, as for the model, the household faces a collateral constraint, as other literature does which contains a durable goods sector or housing sector. However, I did not include the collateral constraint or borrowing constraint as a log-linearized equation in the model block. I just combined the collateral constraint with other first order conditions together to get a equation, which equates the marginal utility of non-durable consumption to the shadow value of durable services. But I found that Iacoviello&Neri (2010) and Funke&Paetz(2013) use the collateral constraint as a separate equation in their code. Is there any problem with what I have done?

It might be that you have converged to a local maximum of the likelihood, which is not the true one. This would explain the behavior. In this case, use a calibrated version of your model with the most recent mode and find out which parameter causes the problem.

I am not familiar with those papers so I cannot answer your question. But when in doubt, try to follow the literature and see whether that solves your problem.

I am just saying you should try to find out which estimated parameter is responsible for the oscillations. And you are correct: the posterior mean should be better as it is used for the IRFs.

When I run my code for the first time, the identification analysis told me that All parameters are identified in the model (rank of H) as well as All parameters are identified by J moments (rank of J). But when I use the mh_mode file as the mode_file for a new estimation run for the second or third time, the identification analysis are shown as:

All parameters are identified in the model (rank of H).