File estimates nicely in dynare 4.5.7 and 4.6.4 but not 5.0+

Estimation
1

Hi All,

I have a file that estimates nicely in older versions of dynare (4.5.7 and 4.6.4). In dynare 5.4 the same file crashes (after a while) and throws the following error (I’ve checked 5.2 and 5.0 as well, with similar results):

Log data density [Laplace approximation] is NaN.

Error using chol
Matrix must be positive definite.

Error in posterior_sampler_initialization (line 84)
d = chol(vv);

Error in posterior_sampler (line 60)
    posterior_sampler_initialization(TargetFun, xparam1, vv, mh_bounds,dataset_,dataset_info,options_,M_,estim_params_,bayestopt_,oo_);

I’m a bit surprised because I thought fmincon is mainly doing the work, irrespective of dynare version, i.e., I would have expected similar behavior… I guess I’m hoping it’s not a bug that was subsequently fixed, but would be grateful for any pointers as to what could be the root cause of the issue (and how to fix it, ideally :slight_smile: ).

Thanks in advance, and attaching files to replicate the issue (in 4.6.4 this goes into the MH phase, in 5.4 it dies before getting there…). For quick reference, this is the estimation command, in case something in the syntax has changed:

estimation(order=1,  presample=5, datafile='PHL_obs_V6_upd_23Q2.csv', lik_init=2, first_obs   =1, nobs=93, mh_replic=1000, mh_nblocks=1, mh_jscale=0.25, mode_compute =1, optim=('MaxIter', 100000),irf=40);

Thanks in advance for any help!
Pawel

ps. Mod file and csv. data file are in the attached .zip file:
MWE.zip (24.4 KB)

2

So ok, I’ve started looking into this and I’m attaching the log files from running the attached minimum working example (MWE) under 5.4 and 4.6.4 respectively:

MWE54.log (25.6 KB)
MWE464.log (29.9 KB)

Long story short, and as expected, the mode optimization steps look exactly the same as does the final value of minus the log posterior (or likelihood):3169.065779.

When I ran visdiff on the two .log files the only differences reported were in the eigenvalue decomposition with 4.6.4 reporting three “negative” zeros, which under 5.4 show as zeros:

Clipboard01
Clipboard011864×903 104 KB

But I’m thinking that that’s more likely to be a reporting issue rather than a genuine difference in how different dynare versions represent the model (otherwise, I would expect small differences in the log posterior as well).

Which then begs the initial question of why does 5.4 have a posterior kernel optimization problem but not 4.6.4?

To try to narrow the issue down, I reran the whole thing in dynare 5.0 but the error log was identical to that in 5.4 (other than one formatting change).

So then I looked the 5.0 release notes / section on estimation:

Estimation

Performance optimization to pruned state space systems and Lyapunov solvers.

New option mh_posterior_mode_estimation to estimation to perform mode-finding by running the MCMC.

New heteroskedastic filter and smoother, where shock standard errors may unexpectedly change in every period. Triggered by the heteroskedastic_filter option of the estimation command, and configured via the heteroskedastic_shocks block.

New option mh_tune_guess for setting the initial value for mh_tune_jscale.

New option smoother_redux to estimation and calib_smoother to trigger computing the Kalman smoother on a restricted state space instead of the full one.

New block filter_initial_state for setting the initial condition of the Kalman filter/smoother.

New option mh_initialize_from_previous_mcmc to the estimation command that allows to pick initial values for a new MCMC from a previous one.

The xls_sheet option of the estimation command now takes a quoted string as value. The former unquoted syntax is still accepted, but no longer recommended.

New option particle_filter_options to set various particle filter options.

But none of what was listed seemed like an obvious source of the different behavior?

So unfortunately, I continue to be puzzled, and unless I get any better ideas, I will try to go through the posterior estimation routines line by line, because that’s where the devil seems to be hidden…

As always, if anyone has better ideas, suggestions would be gratefully received!
Pawel

3

I haven’t fully traced the issue down to the last line. But in both versions, the parameter xi_p runs into the upper bound (you did not use prior_trunc=0). In 4.5.7 Dynare seems to do a smaller step in computing the Hessian. In 5.x the corner solution causes a non-definite Hessian.

4

Thanks Johannes - this is amazingly helpful, as per usual!

And I guess it suggests we were lucky before, but not anymore… I’ll be looking into this over the course of this week (am trying to get the older codes to work under v5.4) and will post back if there are any broader lessons here that others could benefit from.

Good thoughts in the interim,
Pawel