Alternative to modecompute=6?

[t-razafindrabe]

Dear all,

I am actually estimating a simple model (like SW2003 and SW2007 but with import sector) but unless using "modecompute=6", I always get the following error message:

??? Error using ==> chol
Matrix must be positive definite.

The problem is that with modecompute=6, parameters seem to badly converge (I am refering to "mdiag" plot).

I see in some post that it might come from initial value or observation equation specification. However, I use estimated value of SW2007 as starting value and I carefully follow advices given in J. Pfeifer manual for setting obervation equation.

I am pretty new in using dynare so any help would be gratefully appreciated.

Best regards,

[t-razafindrabe]

Any help please,

does it have anything to do with initial value or equation or anything else?

thanks for any help,

Best regards,

[jpfeifer]

It is hard to tell. What often works best is a sequence of different mode_compute. For example, run mode_compute=4 first and then use the generated mode_file as the starting value for running mode_compute=6,8, or 9.
But before doing this, try to check whether something else is wrong. For example, check the parameters at the detected mode whether they hit a bound and test whether they are identified at all.

[t-razafindrabe]

Thanks a lot Pfeifer,

Running mode-compute=4 first generates error message. Even if I run first mode-compute=6 before running mode-compute=4, 8 or 10, I still get the same error message. I have used the identification command and all parameters are identified both for H and J (even using Monte-Carlo as option).

However, parameters may hit a bound but I don't exactly how I will recognize it. Is it for example the case for the variables SE_E_R and SE_E_PIBAR (which are respectively the interest rate and inflation objective shocks). If it is the case, should I decrease the mean of the prior?

Thanks in advance,

[jpfeifer]

Given that the shock standard deviations seem so different from your prior, are you sure that your scaling is correct? How do the persistence parameters look like?

[t-razafindrabe]

Thanks again for your response,

Persistence parameters hit also bounds (please see the file "PriorPosterior(rho)), most of the time the upper bound but sometimes I have a very low estimates. I have seen your remark concerning the scaling of standard error in your notes on observation equations. Unlike Smets and Wouters 2007, I do not express observable variables in percent (that is, not multiplied by 100). In this case, should I divide or multiply the prior mean of the standard error by 100? In my mode file (attached below), I took exactly their prior because it seems that the priors they use in the published version (2007) is for observables that are not expressed in percent. This is because I've compared with priors from the NAWM (New Area Wide Model of Christoffel et al. (2008)) which used observed variables not in percent and it is similarly the same prior in terms of scaling.

Many thanks,

Best regards,

[t-razafindrabe]

Dear all,

I've checked the scaling of the std prior. I compare it with a corresponding std from an AR(1) estimation using observable variables. There is a scaling difference but after fixing this difference (I divide the std prior by 100 compared to Smets and Wouters 2007), I still get the error message when using "modecompute=4".

Meanwhile, I have seen that some parameters' eigenvalues have an imaginary part (please see the attached file). Is it correct to interpret it as a mis-specification problem (prior, equation, ....) ? I'am wondering if it the source of the error message.

Thanks for any help,

[jpfeifer]

Do not worry about the eigenvalues. They can be complex. Rather, that rho_g hits the upper bound is worrisome. Check what is going on there.

[ZBCPA]

It is hard to tell. What often works best is a sequence of different mode_compute. For example, run mode_compute=4 first and then use the generated mode_file as the starting value for running mode_compute=6,8, or 9.
But before doing this, try to check whether something else is wrong. For example, check the parameters at the detected mode whether they hit a bound and test whether they are identified at all.

Dear Johhanes,

Here you said "run mode_compute=4 first and then use the generated mode_file as the starting value for running mode_compute=6,8, or 9". If I understand correctly, the generate mode_file here is either

Code: Select all

mode_file=xxx_mode

after mode finding or

Code: Select all

mode_file=xxx_mh_mode

after mcmc.(xxx is the code name)

Idealy, they are the same , but gennerally xxx_mh_mode would be more accurate than xxx_mode . However, to get the file of xxx_mode.mat by mode finding , only using replic=0 would be enough, so it saves more time comparing to get the file of "xxx_mh_mode.mat" which is after MCMC using replic>0.

So what is your suggestion for the first step to find mode?
1.just run mode finding with replic=0 to save time and get xxx_mode.mat file , then use that mode file to run a different mode_compute?

OR

2. Firstly run MCMC with replic>0 to get xxx_mh_mode.mat file, then use that mode file to run a different moe_compute?

Sorry that it is very long due to my poor English.

Best regards,
Huan

[jpfeifer]

the mh_mode one will only be better than the _mode one if you did not find the mode and the MCMC moves to a region of higher posterior likelihood. The latter is essentially a shortened version of a simulated annealing or mode_compute=6. It is often more efficient to run a different optimizer than using the MCMC run. Thus, my suggestion is to use mh_replic=0.