Dear Sebastien,
here is a list of options that would be needed to run the new dynare_identification routine:
1) Monte Carlo sample (default = 2000): either we allow identification to set the options_.prior_mc option, or we define a new specific option for that (both these solutions would be OK to me); the dynare prior_draw utility is used as standard sampler in dynare_identification; 2) number of lags of computed autocorrelations (theoretical moments). Again: either we allow identification to set options_.ar or we set a specific option for that (default = 3); 3) load_ident_files: a new option to allow dynare loading previously computed analyzes (default = 0); 4) useautocorr: a new option to allow the user to choose between computing derivatives of autocorrelation (=1) or autocovariances (=0). Default would be =1.
Hew, I think we need also to discuss how we implement such options. If we use the same approach as for dynare_sensitivity, the options would have 'no memory', i.e. in any subsequent calls to dynare_identification only the options explicitly set in the identification(<options>) command would be triggered.
In such a case, a specific substructure of options may be advisable (like options_.opt_gsa for dynare_sensitivity)? That sub-structure would be made of four fields
options_ident.prior_mc options_ident.nlags options_ident.load_ident_files options_ident.useautocorr
And the call to the identification triggered by the parser would be
dynare_identification(options_ident);
Finally I would need a couple of new 'bridges' to identification options for the dynare_sensitivity tools:
1) when the identification=1 option is given to dynare_sensitivity, I would need that the model derivatives w.r.t. parameters are triggered as well; 2) a new option load_ident_files would also be needed for the sensitivity analysis (i.e. a new field in the options_gsa.load_ident_files, which is recognized by the preprocessor as an option in dynare_sensitivity). 3) the same identification options for number of lags and useautocorr should also be recognized as possible options in dynare_sensitivity;
Please let me know what you think. Many thanks for your help best wishes Marco
Dear Sebastien,
Le jeudi 24 septembre 2009 à 10:46 +0200, Marco Ratto a écrit :
may I ask for a couple of extensions of the preprocessor, in order to make the identification command more operational?
- when the identification keyword is present, the preprocessor
should always trigger the Hessian computation (g2 output from in <model>_dynamic.m), irrespective to the value of options_.order: the Hessian is in fact needed to compute the analytic derivatives;
Ok, I am going to fix that.
Many thanks for this. Also, I noted that the <model>_dynamic files is not always generated by the preprocessor. When I run the sensitivity analysis (i.e. dynare_sensitivity) without any stoch_simul or estimation command <model>_dynamic is not triggered and the analysis crashes. Would it be possible to fix also this?
- we may discuss the way the preprocessor triggers the call to
dynare_identification:
-) the simple and quick option would be to do the call from the main model script, (options to be defined) -) alternatively, we may think of adding it to the options of prior_analysis, to which it would fit, I think.
My idea was to use the keyword "identification" for that purpose. Currently it does nothing except triggering the derivatives w.r. to parameters, but we could add options to it and make it the entry point to dynare_identification. Is it ok for you?
Yes, I think this is OK. As soon as the routines are at a more advanced stage, I will prepare a list of options to be implemented for the identification keyword.
best wishes
Best