Tuning jscale inside MH loop

[tomiw]

Hi all,

since some DSGE models require large number of MH draws (>1.000.000) for convergence, I'm wondering whether it is conceptionally wrong to tune the jscale "inside" the MH loop. So that I do not have to run several trials to figure out the reasonable number of the jscale.

Basically it means that I would augment metropolis.m and start to calculate the average acceptance ratio after some burn-in replications in every MH step and automatically adjust the jscale when the average acceptance ratio falls out the reasonable bound, that say 0.2 to 0.5

This would mean that the jscale ist not a constant within MH algorithm. I couldn't find literature discussing convergence issue of such procedure.

Best, Tomi

[StephaneAdjemian]

Hi Tomi,

This is implemented somewhere in dynare but not (yet) documented. I have no theoretical hints about this but experience shows that we don't need to run a metropolis with 1,000,000s of draws in order to tune the scale parameter. I discard the draws used to choose the scale parameter (such that the acceptation rate is one third). The time devoted to the tuning the scale parameter is not so important.

Best,
St

[tomiw]

Hi Stephane,

thanks for the reply.
I've "found" metropoli99.m which is meant to tune the scale parameter right?

So now I call the metropolis99.m before the actual MH loop and initiate the scale parameter and covariance matrix with the results from metropolis99.m and provisionally it seems to work very well.

I've tried to understand the codes. The first 3 parts of metropolis99.m are quite selfexplanatory. But I do not understand the last part. What is meant by "Climbing the Hill"?

Best, Tomi

[StephaneAdjemian]

Hi Tomi,

metropolis99.m (gmhmaxlik.m in version 4) do the tuning of the scale parameter, but its main purpose is to give an evaluation of the posterior mode (or at least to find a point where the posterior density is important around which I start the metropolis chains). What is meant by 'climbing the hill' is that I refine the (stochastic) search of the posterior mode (by reducing the size of the jumping distribution continuously). You can call this routine by using the option

mode_compute = 6

in the estimation command. It may be a good idea to start from the posterior mode computed by the default optimizer (using the option 'mode_file =' in the estimation command).

Best,
St