Could you please have a look the attached mode check plots figure? I have read your “An Introduction to Graphs in Dynare”, but still have some questions about the mode check plots figure…

1.SE_y_Me figure is the standard deviation of Measurement error to y. Does it look weird ?Since it is always straight and has no blue curve.

In terms of rhoa , which is the persistence of transitory productivity shock, no matter I use mode_compute=4 or 9 or 6, it always generate the almost same mode check plot for rhoa. Am I right to use it as a mode to start mcmc ,even though it does not find the highest point of blue curve?

if estimation results show that rhoa is very large , about 0.996, would that be a serious problem? (No matter how I change the initial values, rhoa always reaches that large after several rounds of mode finding)?

The first 3 pics are all standard deviations of shocks, where blue curve and green curve are almost PERFECTLY overlapped. Does it mean the data fail to provide much information to find mode? Would that be a problem?

Yes, they look weird, most probably because of problems in mode-finding.

1.) Look at the scaling. Because the x-axis and the y-axis scaling are tiny it is hard to tell what is going on. There being no blue curve means that the green curve is on top of the blue one. This happens when the prior does not introduce additional curvature, e.g. when using a uniform prior.
2.) This is hard to tell. Looking at the correlations, the mode is at a corner solution (the red dots). Given that you are at a corner in some dimension, you won’t have a nice peak for all parameters. This will create problems in the MCMC because the Hessian is clearly not positive definite.
3.) In principle, such a high value is not an issue. But what you report is a clear warning sign that there is something still off. Usually, there is still a problem with the observation equations.
4.) No, it means the prior does not add information, typically, when you use a diffuse or uniform prior. That is not a problem.

Summary: check your model for typical issues like non-identification and wrong observation equations.

1.) Look at the scaling. Because the x-axis and the y-axis scaling are tiny it is hard to tell what is going on. There being no blue curve means that the green curve is on top of the blue one. This happens when the prior does not introduce additional curvature, e.g. when using a uniform prior.
2.) This is hard to tell. Looking at the correlations, the mode is at a corner solution (the red dots). Given that you are at a corner in some dimension, you won’t have a nice peak for all parameters. This will create problems in the MCMC because the Hessian is clearly not positive definite.
3.) In principle, such a high value is not an issue. But what you report is a clear warning sign that there is something still off. Usually, there is still a problem with the observation equations.
4.) No, it means the prior does not add information, typically, when you use a diffuse or uniform prior. That is not a problem.

Summary: check your model for typical issues like non-identification and wrong observation equations.

Many thanks for your detailed reply .

In terms of your answer for 2), sometimes we always get the result “the hessian matrix at the “mode” is not positive definite”, even though the mode check plots like fine… Like the following “Measurement error” pdf, measurement errors.pdf (9.93 KB) all SE of measurement errors hit upper bound,In that case, and Hessian is not positive definite, therefore mode_compute=4 or 9 fail to run MCMC, so can I just run MCMC with mode_compute=6 to get the posterior mean ?

By the way, could you please also have a look at the attached two figures. I am wondering if the SE y_ME ( measurement error to output growth rate) looks fine, since it is weird in the posterior figure, and in univariate diagnostic it seems not converge…Would that be a problem? (I have already run 500000 draw and discard first half. ) univariate diagnostics.pdf (12.5 KB)Prior and posterior.pdf (17 KB)
Kindest regards,
Catherine

None of these figures look fine. As soon as you hit the boundary for one parameter, you are going to have trouble. A different mode_compute then is unlikely to help if there are deeper underlying problems.

Yes, convergence is a problem. This open happens when initial mode-fining was not successful.