Error during estimation: Log data density [Laplace approximation] is NaN

Greetings to all,

I wish to replicate Fernández-Villaverde’s 2010 work by modifying the NK_baseline.mod file and bringing it to estimation. However, I encounter the following errors, even after consulting the Pfeifer 2021 guide on specifying obs equation. Could you kindly advice me where the problem might be? Thanks a lot!

The problems are

  1. The rank of Gbar (Jacobian of mean and spectrum) is deficient!

    (minus) the hessian matrix at the “mode” is not positive definite!
    => posterior variance of the estimated parameters are not positive.
    You should try to change the initial values of the parameters using
    the estimated_params_init block, or use another optimization routine.
    Warning: The results below are most likely wrong!

  3. Log data density [Laplace approximation] is NaN.
    Error using chol
    Matrix must be positive definite with real diagonal.

the consturctions of variables are as follows:
obs1 = log difference of the proxy of relative price of investment w.r.t. that of consumption
obs2 = log difference real output per capita
obs3 = log difference of real wage p.c.
obs4 = log difference of CPI
obs5 = log( 1+ federal funds rate /(4*100))

Uploading: NK_baseline.mod…
NK_baseline_steadystate.m (5.3 KB)
obs_data.csv (20.1 KB)

looks like the previous upload was not successful
NK_baseline.mod (12.8 KB)

Try mode_compute=5. When I do that, I get corner solutions for the parameters due to the bounds you set.

Thank you for the kind help! After using mode_compute = 5, I receive some warnings as follows:

Sequence of univariate steps!!
Actual dxnorm 1.1848
FVAL -583.2591
Improvement 651.5467
Ftol 1e-05
Htol 1e-05
Warning: Matrix is close to singular or badly scaled. Results may be inaccurate. RCOND = 1.185787e-21.

In mr_hessian (line 220)
In newrat (line 260)
In dynare_minimize_objective (line 326)
In dynare_estimation_1 (line 221)
In dynare_estimation (line 118)
In NK_baseline.driver (line 538)
In dynare (line 278)
In runDynareNK (line 3)


Estimation::mcmc: Write details about the MCMC… Ok!
Estimation::mcmc: Details about the MCMC are available in NK_baseline/metropolis\NK_baseline_mh_history_0.mat

Exiting fzero: aborting search for an interval containing a sign change
because complex function value encountered during search.
(Function value at -0.07 is -66.0853+37.6672i.)
Check function or try again with a different starting value.
Exiting fzero: aborting search for an interval containing a sign change
because complex function value encountered during search.
(Function value at -0.07 is -73.7422+49.7878i.)

May I ask what these warning implies, and are these warnings important?

The first one is a warning from the mode-finder that can happen during hard problems. It’s nothing to worry about.
The second message comes from the fzero call in your steady state file. For some draws, the steady state could not computed.

Thank you very much, Professor Pfeifer. I have now expressed all the variables as logarithms (I substituted exp(x) for all variables x). However, when I rerun the estimation, it still gives the same error as before. I am having difficulty understanding how I should map the variables to observables with this expression. Could you kindly give me some comments on the expression of the measurment equations (if I am doing them correctly), and how to overcome the error?

Thank you for the kind guidance!

NK_baseline_log_steadystate.m (5.6 KB)
NK_baseline_log.mod (13.7 KB)
obs_data.csv (20.1 KB)

Why did you go for a full substitution? That is not recommended. See Question about understanding irfs in dynare - #4 by jpfeifer

It is because I would like to work with models that are already log-linearized at a later stage. This is why I performed step 2 as mentioned in the previous post - substituting exp() for all variables so that they are equivalent to the log-linearized model expression. However, I still do not understand how to map the variables to observables or where the estimation error arises.

As mentioned above, the problem happens during mode-finding as the parameters run into the prior bounds you explicitly set.