Dear team,
I trust you are well. Congratulations on your 4.6.0 release, it is very impressive!
On a different note, what is the functional form of the proposal density used for the independent MH? Is the normal distribution with a mean and variance obtained from the maximisation step (posterior mode)?
Many thanks in advance for your time and help.
Kostas
Do you really mean the independent MH or the default Random Walk MH?
I mean the independent MH, please. My idea is to use the Laplace approximation of the quasi bayesian IRF matching estimator proposed by CTW as the proposal density to derive the posterior sample (discussed also in the paper). RW takes ages and (at the end) doesn’t converge (I have modified the dsge_likelihood and endogenous_prior functions to implement their approach). I want to see if I can remove (or at least reduce) the serial correlation by using this trick.
I found the answer to my question, it is in (the new version of) the manual 
.
Many thanks
Kostas
Dear Konstantinos,
I actually face a very similar problem. I also use the quasi bayesian IRF matching estimator by CTW and the MH algorithm realy takes ages to run, although the mode finding is quite quick. I am wondering why and so far I couldnt figure it out. How did you solve that and what did you find in the manual? 
I found how I could change the proposal density. The difference wasn’t substantial, so I used the RW MH at the end.
Alright thanks a lot. I guess you simply weighted ages for it to complete then? I am wondering if there is a more efficient sampler than the random walk metrpolis for the bayesian IRF matching.
Why does it take ages? Have you profiled the code?
Dear Prof. Pfeifer,
thanks for stepping in. The model is modestly complex (approximately 150 equations). By ages I mean the fact that I let it run over night (8 hours) in order to generate 100 000 draws and now it just finished with the first 8000. I am wondering why this is the case. When I do only 2000 draws (in order to check if it runs) it takes about 5-10 minutes. If that would be linear it should reach 8000 draws after max 80 minutes instead of taking 8 hours.
With that being said, what do you mean by “profiled” the code. Sorry I am not an expert but couldnt find the practice you are aluding to in the manual. Please enlighten me
Currently I am working on setting up the paralell computing capabilities to see how far I get with that.
Best,
Ben
That sounds strange. The Profiling is not Dynare, but Matlab. In Matlab there is a “Run and time”-command in Home-Panel.
Regarding run-time: does the acceptance rate drop a lot over the chain? Are you using any numerical solvers when computing a steady state?
Der Prof. Pfeifer,
thanks a lot for your guidance in this forum. I really appreciate it and scan through your advices quite a lot.
Regarding your question:
- The acceptance rate stabilizes at 0.2 while in the very beginning showing 0.5 and 0.3 but then falls of quickly
- The steady state is largely analytical but two problems are solved numerically using fsolve. Those are usualy solved in a few second when I use it. Also mode-finding works smoothly.
I guess I would need to see the files.
Dear Professor,
thanks for your guidance. I managed to paralellize the bayesian impulse response matching estimator of CTW in dynare (which was tougher than expected, given that they relied on using global variables). Anyways, this way I got to know the source code of Dynare and now the estimation takes a more reasonable amount of time. I followed your guidance and tracked which step takes such a long time and it tends to be the steady state solution, which is done in a seperate m.file. In particular I use the levenberg-marquardt algorithm of matlab to solve for the relative price and labor input of one of the two countries. Conditional on these variables the steadystate for the remaining variables can be calculated recursively. This simply takes quite an amount of time to do repetedly I guess. Do you have any idea if the estimation is going to be much faster if I use the steadystate model block instead?
Ben
Maybe as a follow up question:
Just to make sure I understood the workings of dynare correctly. Is dynare going to distribute the amount of draws specified in mh_replic to the chains? I.e. is each chain generating mh_replic/nblocks amount of draws. Or is each chain generating mh_replic draws on its own such that the overall amount of draws is mh_replic*nblocks?
Thanks a lot for your help!
- If the problem is the solver, then using
steady_state_model-block may not gain too much. On the other hand, the effect is largest for big models as you are avoiding loops over variables and parameters. -
mh_replicis the number of draws per chain.
Dear Prof. Pfeifer,
thanks i will give the steady state model block a try.
Regarding mh_replic: I ran the random-walk-metropolis-hastings algorithm using mh_replic = 25000 and nblocks =4. This should correspond to 100 000 draws if my understanding is correct. I found it weird that in the end I got a message stating that there are not enough draws to compute the HPD-Intervalls and other quantiles. Although in the output I got some estimates of the intervalls. Do I need to increase the number of draws? Sorry for asking these silly questions, but I am just learning to use dynare for estimation.
Are you using the most recent stable version of Dynare?
Unfortunately not. CTW use 4.4.3 for their algorithm and the codes they provide rely on the structure of 4.4.3. I figured it might be easier to use that version instead of thinking about how to transfer it to the most recent one.
If I remember correctly, that was a bug in the display:
When computing posterior moments, Dynare falsely displayed that moment
computations are skipped, although the computation was performed correctly
Wow this is great news! Thanks a lot for your help