Dynare forums

I am doing Bayesian estimation w.r.t. small open economy.

Althogh I tried numerous methods to improve convergence, results end up not very good.

For instance, I used the strategy to estimate part of parameters and then use this information by setting mode file next time estimations.
Also, I increased the iteration numbers by load_mh_file.

But, still results are not satisfactory.

I would like to learn practical tips to do successfully Bayesian estimation w.r.t. small open economy model lIke Aldolfson et al.

Thanks in advance.

First of all, check whether you really started at the mode. Look e.g. at trace-plots of the posterior density to see whether there is still a drift.

Thank you, Mr. Pfeifer.

But, I don't understand what means to check whether you really started at the mode.

Bayesian estimaton first starts to find log posterior's mode, and then mcmc begins from that mode??

Sorry, I am novice to Bayesian estimation.

Bayesian estimation starts at the point where the solver stops. Ideally this is the global mode, but it could also be a local one. If the latter is the case, the MCMC will tend to move to regions of higher posterior density, leading to parameter drift.

Thank you, Mr.Pfeifer.

I understand what you mean is to check if mode before mcmc is global mode by means of trace plot, etc.

So, following your advice, I obtained trace plot after estimation.

Then, I found that there are a lot of parametern drifts.

For example, upward or downward trends for xi_mi, xi_x, rho_ystar, drifit for kappa_mc,
and spikes for epsilon_tauc.
(see "attached file")

I realized something wrong those paramter's estimates,
however, I don't know how to fix it and where to start to do that.

Any advice will be a big help to me.

Thanks.

Run a better mode-finder like mode_compute=9, even it if runs some time.

Dear Pfeifer,
following your advice, I ran mode_compute=9 as mode_finder,
however, I got a message like "Error using chol. Matrix must be positive definite." .

As an alternative way, I used mode_file option setting mode as that previously run by mode_finder=6, and then ran mode_finder=9.
However, again I got a message like "Error using chol. Matrix must be positive definite." .

I think that given my models and datasets, only mode_finder=6 doesn't suffer from this problem.
However, convergence dignostics show mode by mode_fider=6 cannot be a global mode.

Are there any other ways to overcome this problem?

Sorry to bother you.

You should look at the mode_check plots after mode_finding. Also, compare the posterior density resulting from different mode-finders.

You should look at the mode_check plots after mode_finding. Also, compare the posterior density resulting from different mode-finders.

Dear Prof. Pfeifer,

As I said before, only mode_compute=6 didn't suffer from non-positive definite matrix for my codes and data.
All other mode finder ended up showing problem like "Error using chol. Matrix must be positive definite."

So, I attach mode_check plots from mode_compute=6.
(plz see attachment)

To my knowledge, it is good that peaks of blue lines are located at vertical sky-blue lines as close as possible having decent degrees of curvatures.
In these respects, it seems that mode I have is far from global mode, in particular, for shocks' AR(1) coefficients.

However, the most important and the most curious part but I didn'T find answers is what I should do to fix this problem as a next step.
For instances, should I exclude problematic parameters in terms of mode_check plot from model?
Should I add or drop observable data?
What else I should do?

As far as I know, I didn't make usual mitakes such as parameter dependece, undemeaned data, observation equations unmultiplied by 100, etc.
Furthermore, my program codes had been slightly modified from Macroeconomic Model Data Base site's Adolfon et al.(2007), thus I dont think they have significant flaws.

Any advice will be greatly appreciated, and the more detailed, the better.

Mank thanks and sorry too much.

You clearly haven't found the mode. That mode_compute=6 does not crash is irrelevant in that regard. Its covariance matrix is positive definite by construction, but that hardly helps as you will get problems with convergence. What happens when you run mode_compute=9 instead of or after mode_compute=6? Is the posterior density at the mode higher?
Your problem is high-dimensional. Finding the mode will be challenging. Relying on the Macroeconomic Model Data Base for estimation is problematic, because their models are typically not suitable for estimation as parameter dependence is not taken into account. For the Adolfson et al. model, there is also stochastic singularity without measurement error. Usually, it is a good strategy to start with a smaller model.

Thank you, Prof. Pfeifer.

After calibrating some problematic parameter in terms of mode_check or convergence dignostics, finally mode_find=9 began to work.
Results showed mode_find=9 is superior to mode_find=6.

However, I ran into problem, when I estimated another model by mode_find=9.

At the end of mode_finding, it didn't produce mode, but gave me following error message.


Reference to a cleared variable DH.

Error in dsge_likelihood (line 714)
tmp(j,:)=DH(j,j,:);

Error in dynare_estimation_1 (line 616)
[junk1, junk2, hh] = feval(objective_function,xparam1, ...

Error in dynare_estimation (line 89)
dynare_estimation_1(var_list,dname);

Error in soejptist_new2b_m2 (line 1083)
dynare_estimation(var_list_);

Error in dynare (line 180)
evalin('base',fname) ;

I have no clue what this error message means.

If you give any clue, it will be greatly appreciated.

Thanks.

Does this also happen with the unstable version? If yes, please provide the mod-file, the mode-file and the data.

I run this code only in stable version, dynare 4.4.3.

After deleting "identification;" in code, no error message showed up.

I don't know whether this error has something to do with "identification" command.

Thank you for your kind reply up to now.

This is an interaction between the two commands

Code: Select all

identification

and

Code: Select all

estimation

that has been fixed in the unstable version. No reason to worry here.