Dynare forums

Yes, it can go both ways. The only problematic warning of the three warnings you refer to is the second.

The first is just a warning during the solution of the steady state, but there is still a check whether the solution actually is a steady state. So nothing can go wrong here.
Similarly, the third one refers to the initialization of the Kalman filter. Any problems here should be minimal as initial conditions usually die out quickly.

The warning about an inaccurate solution is more tricky. In theory, the results may be inaccurate and the effect on the likelihood might go both ways. Unfortunately, there is no way to know the size of the error as there is no other way to compute the actual correct solution. The accuracy of the likelihood depends on the accuracy of the solution and is of the same order (see also http://onlinelibrary.wiley.com/doi/10.1111/j.1468-0262.2006.00650.x/abstract and http://onlinelibrary.wiley.com/doi/10.3982/ECTA7669/abstract). So unless you think there is a massive problem with your solution for some parameters you should be fine.

I tried out different parameter vectors, for the model, in order to get different log likelihood values. I got values around the interval (-1700,-2300). And then I also got a few values of 0.01- and -10. Since this deviated so much I figured something was wrong and restarted everything and used the following command in the set up estimation

set_dynare_seed('clock');
estimation(order=1, datafile=usmodel_data_eget, mh_replic=10, mh_nblocks=2, mh_jscale=0.8, nograph, nodiagnostic);

Do you agree that this should do the trick of generating a slightly different initial estimation set up?

And then I compared all the parameter vectors in order to see if anyone gave a different likelihood value compared to the previous set up. As it turns out The extremely low values of 0.01- and -10 and maybe three other vectors generated the error value 1e+8 or values very close to 1e+8. I also noted some patterns in those extreme values regarding the warning in dyn_first_order_solver.m row 315: ghu = - A_ \ fu;. rcond(A_) was 1e-7. I usually don't see such low values for rcond(A_).

What do you say about an approach where I punish the likelihood function when rcond(A_) gets very low and therefore inaccurate?

Could you provide me with example codes?

Penalizing when the solution is inaccurate should work (if you know that a low rcond only means exactly this). But I was wondering whether your few outliers materially affect the posterior distributions.

When I run the code that I'm attaching I get.


rcond(jacob) rcond(A_) log likelihood
1,57584115349113e-10 0,000772325365577031 -1001,73193838161
4,84036186378225e-06 0,000423716426874983 -1174,39290562767
5,06986120088668e-06 0,000465094332509841 -1173,43665614883
5,84371209498350e-11 3,60035055286181e-09 -124,641919336953
6,56431006951448e-06 0,000759552906717238 -1177,21986016283
1,44535382775040e-06 0,000148846120569051 -1176,61074901448

As you can see, there are two columns that deviates from the rest when it comes to the log likelihood. Namely, column 1 and 4, especially 4. For 4 you see that the Jacobian in evaluate_steady_state.m row 86: ys = ys_init-jacob\fvec has a lower rcond value than the others and so does rcond(_A) in dyn_first_order_solver.m row 315: ghu = - A_ \ fu;

I attach my files in a zip file. All you have to do is run the m-file "AA_run.m" and you will get the minus log likelihood value in the vector "end_vec".


\\\Glm

Sorry, but there is at least one file missing in the zip-file. I cannot run the mod-file, because min_max_funk cannot be found.

Hiii, I have my model expressed in term of logs. so, ctilda=css*exp(c), where, ctilda is the values of the simulation in matlab and css the value of the steady state.
I want to recover my original "c", but when matlab simulates the serie gives me negatives values, so I cannot apply logarithm,

I want to know which transformation I can do to recover my "c".

THANKX!

@lilianagnr Please don't clutter old posts with new questions. This is not a catch-all post. That consumption becomes negative is strange and indicates more problems with your model. That investment sometimes becomes negative in first order approximations can happen, but for consumption this is strange and suggests a wrong shock size or something similar.

Sorry about the missing file it should be there now with this new attachment.

\\\Glm

I am investigating the issue, but I seems to be something else. For some reason, for those values the forecast error matrix becomes singular.

Could you please try putting

Code: Select all

use_univariate_filters_if_singularity_is_detected=0;


in the estimation command.

I entered it like this

estimation(order=1, datafile=usmodel_data_eget, mh_replic=10, mh_nblocks=2, mh_jscale=0.8,
use_univariate_filters_if_singularity_is_detected=0, nograph, nodiagnostic);

It seems like that did the trick. The extremly high likelihood values now got the error value instead i.e -1e+8.

Nice work!!

\Glm

I am trying to do do the exact same thing as earlier, i.e. running the mod-file with the purpose of getting the likelihood value only. The difference this time is that instead of a pure Maximum likelihood I've added the same priors as Smets and Wouters (2007). But now the usual way doesn't seem to work at all. Is there a way to fix this? I've attached both files, the usual maximum likelihood mod-file called "s_and_w_ml.mod" and the one with priors "s_and_w_prior.mod"

\\\Glm

I forgot to add one file, "min_max_funk". It's added here.

\\\Glm

What exactly is the problem?

I wanna get the likelihood value for some paramater vector "xparam". This works fine when I have a 100 % maximum likelihood mod file. But when I add priors, for instance if I replace the first row of the "estimated_params" block like this (in the s_and_w_ml.mod file):

csadjcost,6.3325,tres(1,1),tres(1,2);

and replace it with the prior

csadjcost,6.3325,2,15,NORMAL_PDF,4,1.5;

It doesn't work any more and I get the error that it can't find the distribution "NORMAL_PDF"