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?

1. 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.

2. 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?

Best

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?

1. 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?

...

...

2. 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

Hi Sebastien,

thanks a lot! Sorry for the late reply. I'm in Brussels. I will begin testing the staff next week best wishes Marco

On Wed, 14 Oct 2009 16:20:33 +0000, Sébastien Villemot sebastien.villemot@ens.fr wrote:

Hi Marco,

Le mardi 06 octobre 2009 à 10:39 +0200, Marco Ratto a écrit :

...

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.

I have added these four options ("ar", "useautocorr", "load_ident_files", "prior_mc") to "identification" keyword. They accept integers as arguments.

...

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.

This is the way I have implement that. Note that I don't pass default values: it is up to you to detect which fields are missing and to set the default values when relevant.

...

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

I did that, except that instead of "options_ident.nlags" the name used is "options_ident.ar" (the same name than the "ar" option)

...

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;

This is normally done.

...

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;

I added the three "ar", "useautocorr", "load_ident_files" to "dynare_sensitivity".

I have not tested all these changes, so please tell me if something doesn't work as expected.

Best,