convergence

[iacoviel]

When I estimate the same model (same mod file) using the default options in Dynare two or three times, sometime the estimation ends at a value of the objective function (and estimated parameters) which is much smaller than the value I obtain in other cases (say, -4100 vs -4150). What are the options that I can use to avoid running into these problems?

Also, looking at the estimation log, I often read values of the objective function which are lower than the one achived at the mode. For instance, after 87 iterations, Objective function at mode: -4147.421412. Yet at iterations 75 (and other iterations..), I have:
[...]
lambda = 0.0067914; f = -4147.3805831
lambda = 0.0058901; f = -4163.3558896
lambda = 0.0064154; f = -4163.9938501
lambda = 0.0069876; f = -4147.3805829
[...]
Does it mean anything?

Thanks

[MichelJuillard]

In some circumstance, the csminwel takes random moves in the parameters. Two replications won't give you the same results, unless you seed the normal random generator before estimation()

I don't know why in some circumstances, the optimizer doesn't accept what seems to be a better point.

Posterior maximization isn't perfect. I use the following procedure

1) look for posterior mode
2) run Metropolis iterations with 10000 or 20000 iterations. Check if the mode of the posterior densities is close to the computed mode (the green vertical line). If it isn't the case, use estimated_params_init to set better initial value for the optimization step and look again for the posterior mode

In any case, when you believe that you found a good mode, either use it always afterwards with options mode_compute=0,mode_file=.... or use
estimated_params_init to start posterior mode optimization close to a good location

Best

Michel

[psummers]

I don't know if this is the same thing you're experiencing, but it sounds similar to the csminwel bug that C. Sims reports on his web page:

"As of this writing (August 19, 2005) there is a bug in csminwel.m that has been repaired in csminwel.R. When the routine encounters a "wall", it tries three search directions in the process of trying to "slide along" the wall. In order to stay clear of the wall discontinuity, it may choose as its next x value the value from a search direction that is not the lowest function value of the three. The bug is that the code should insist that, if available, a function value that improves f by more than the convergence criterion crit be chosen. Otherwise, the routine may halt the search, declaring "Improvement less than crit convergence", even though it is evident that it could have chosen a function value that improved by more than crit. The workaround, until csminwel.m is repaired, is to locate which of the three search directions delivered an improvement by more than crit, then restart, using the x and H values in whichever of the files g1, g2, or g3 has the best f value."

Certainly the behavior that you describe sounds similar to this.

PS

[MichelJuillard]

Chris Sims has now kindly updated the Matlab version of csminwel.m. It is used in the last version of Dynare (3.064)

Best

Michel