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
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
Hi Marco,
I just update dynare_estimation_init.m and now it is also used in dynare_estimation_1.m
Please, everybody, if you use optimizers different from mode_compute=4, test the new code to check that it is still working with your preferred optimizer.
This solution is not perfect: dynare_estimation_init is still setting globals and I'm not sure about what should be in dynare_estimation_init and what should be left in dynare_estimation_1.m. When GSA is fixed, I will try to improve on it.
When you have fixed GSA, could you please add a Wiki page explaining how to install GSA to work with Dynare and contribute a couple of test files?
All the best,
Michel
On 2/21/2011 9:17 AM, Marco Ratto wrote:
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
Great many thanks! I'll work on it tomorrow best Marco
On 2/21/2011 11:53 AM, Michel Juillard wrote:
Hi Marco,
I just update dynare_estimation_init.m and now it is also used in dynare_estimation_1.m
Please, everybody, if you use optimizers different from mode_compute=4, test the new code to check that it is still working with your preferred optimizer.
This solution is not perfect: dynare_estimation_init is still setting globals and I'm not sure about what should be in dynare_estimation_init and what should be left in dynare_estimation_1.m. When GSA is fixed, I will try to improve on it.
When you have fixed GSA, could you please add a Wiki page explaining how to install GSA to work with Dynare and contribute a couple of test files?
All the best,
Michel
On 2/21/2011 9:17 AM, Marco Ratto wrote:
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
Dear Michel,
I just committed in my personal repository (cherry-picked 4.2 as well) a bug fix related to dname. thanks for your help best Marco
On 2/21/2011 11:53 AM, Michel Juillard wrote:
Hi Marco,
I just update dynare_estimation_init.m and now it is also used in dynare_estimation_1.m
Please, everybody, if you use optimizers different from mode_compute=4, test the new code to check that it is still working with your preferred optimizer.
This solution is not perfect: dynare_estimation_init is still setting globals and I'm not sure about what should be in dynare_estimation_init and what should be left in dynare_estimation_1.m. When GSA is fixed, I will try to improve on it.
When you have fixed GSA, could you please add a Wiki page explaining how to install GSA to work with Dynare and contribute a couple of test files?
All the best,
Michel
On 2/21/2011 9:17 AM, Marco Ratto wrote:
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
Marco Ratto marco.ratto@jrc.ec.europa.eu writes:
I just committed in my personal repository (cherry-picked 4.2 as well) a bug fix related to dname.
Thanks, I merged the commits.
Dear Michel, Sebastien,
since I call dsgelikelihood and dsgesmoother from sensitivity/identification, information about steady-state, noconstant and missing values would be needed. What about considering to move things in dynare_estimation_1 up to line 119 (or 121) to the initialization function dynare_estimation_init and provide as additional output arguments of dynare_estimation_init all info for dsgelikelihood/smoother ? The same info could then be used by any other routine calling directly dynare_estimation_init and wanting to call KF or smoother. what do you think?
best Marco
On 2/22/2011 10:26 AM, Sébastien Villemot wrote:
Marco Rattomarco.ratto@jrc.ec.europa.eu writes:
I just committed in my personal repository (cherry-picked 4.2 as well) a bug fix related to dname.
Thanks, I merged the commits.
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
Hello,
The MS-sbvar code has been incorporated into the Dynare build system. As the code continues to be developed as an independent project, we decided to incorporate it into the Dynare repository as a git submodule.
What this means for you is that the first time you fetch and rebase these changes, you will need to run
$ git submodule update --init
from the root directory of the dynare directory. This will initialize the submodules and download the necessary files. After configuring, you should be able to compile the ms-sbvar code without a problem.
Henceforth, whenever you see a commit with the word 'submodule' in it, you will need to run
$ git submodule udpate
from the root dynare directory to obtain the updated files.
Best, Houtan
You can read more about git submodules here: http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
-
Houtan Bastani -
Marco Ratto -
Michel Juillard -
Sébastien Villemot