Non positive definite Hessian

[joepearlman1]

Occasionally I get a message that Dynare cannot continue on from calculation of the mode to MCMC because the Hessian is non positive definite.

However, this is almost certainly due to rounding error in the calculation of the Hessian, since almost all the optimization routines that Dynare uses have been around virtually unchanged for 40 years and have been rigorously tested, and will not stop at a saddlepoint. In other words, the mode has been correctly reached, but there is a numerical problem. The obvious solution to this is to use the approximation to the Hessian (or to its inverse) that is generated for all optimization routines except the Nelder-Meade simplex algorithm. May I suggest that this is done for the next version of Dynare, so that Dynare can progress seamlessly into MCMC. The only issue is that users would need to be informed that the calculation of the marginal likelihood at the end of the mode stage could be unreliable.

[jpfeifer]

I tend to disagree. When looking at the typical mode-check plot of users reporting non-positive definite Hessians the problem is more fundamental than just numerical error. Rather, there are various issues like the use of a wrong observation equation, nonidentified parameters, or the optimizer getting stuck without finding a minimum. Also, there are many cases where the approximated Hessian returned by optimizers are not correctly updated from the original one.

Doing what you suggest would allow inexperienced users to continue with a wrong model, which we have resisted to allowing since Dynare 4.0. You are right that this is restrictive for power users, but they can use the mcmc_jumping_covariance option.