Dear Michel,
thanks a lot for your proposal. This would be an excellent solution also for me. Would you like me to try this? best Marco
On 2/19/2011 10:48 AM, Michel Juillard wrote:
I think that it is my mistake: I wrote dynare_estimation_init.m for sensitivity/identification but never end up using it in dynare_estimation_1.m
My preferred solution would be -to make a new version of dynare_estimation_init.m by using lines 1-303 of dynare_estimation_1.m -add an argument for gsa as in the current version of dynare_estimation_init.m -removes lines 1-303 from dynare_estimation_1.m and call dynare_estimation_init
Best
Michel
On 02/18/2011 04:00 PM, Marco Ratto wrote:
Dear Michel, Sebastien, I just realized that, a part from identification, also sensitivity analysis is broken under 4.2. It is my fault not having checked this before [at least they are not official features ...]. I hope to have time to work on it and fix all problems next week.
One point concerns dynare_estimation_init.m:
At some point in the past Michel did it, breaking dynare_estimation, in order to provide initialization of the estimation environment, then dynare_estimation would do actual estimation while sensitivity or identification would do other things. Now the 4.2 developments are such that dynare_estimation_init is isolated from dynare, except that it is called from identification/sensitivity and I have to replicate there all the initialization commands which are now done in dynare_estimation + dynare_estimation_1.
Essentially dynare_estimation_init is a dumplicate of a large portion of the dynare estimation routines.
My question is if I can study a way where dynare_estimation_init is simply eliminated and I directly use the common dynare estimaton routines to initialize the environment with some return commands that exit routines prior to estimation when we call them from identification or sensitivity.
Do you think this is something reasonable?
please let me know all the best Marco