- Dev - dynare.org

[Trac] #168: steady_state operator + oo_.steady_state versus dr.ys
by Trac Dynare 14 Mar '11

14 Mar '11

#168: steady_state operator + oo_.steady_state versus dr.ys --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: enhancement | Status: new Priority: major | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- The steady_state operator is currently implemented via the global variable oo_.steady_state in *_dynamic.m It would be preferable to pass it as argument It is also necessary to clarify the respective role of oo_.steady_state and dr.ys In perfect foresight models where the terminal steady state is different from the initial one, we need to clarify which steady state the steady_state operator refers to. Whatever change is made, must be done for *_dynamic.m *_dynamic.mex* and in bytecode -- Ticket URL: <https://www.dynare.org/trac/ticket/168> Dynare <http://www.dynare.org> The Dynare project

1 3

steady state operator
by Michel Juillard 14 Mar '11

14 Mar '11

The temporary fix used to solve the bug for the steady_state operator (updating oo_.steady_state in resol.m) created a problem for estimation when the steady state is recomputed numerically at each iteration. Before the change, numerical computation of the steady state was always using the same intial value (oo_.steady_state) for the nonlinear solution algorithm. After the change, the initial value was the steady state at the last evaluation. It appears that it deteriorates in an important manner the performance of the optimizer, that stops before reaching the mode. at least in some examples that where working fine before the change. I have now made the steady state vector an additional argument to the *_dynamic() function and changed all the calls accordingly. The changes have been uploaded to GIT. There is a remaining problem for bytecode that is currently broken, but Ferhat is looking into it. Then, I reverted the change to resol.m and, in estimation, the nonlinear function for finding the steady state again starts always from the same initial point. Best Michel

3 4

[Trac] #169: recent change to oo_.steady_state breaks estimation
by Trac Dynare 14 Mar '11

14 Mar '11

#169: recent change to oo_.steady_state breaks estimation --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: critical | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- The commit 9f7cfaec007f0d4aa805047823c3fb4ce020d6b9 has broken estimation, in particular of fs2000.mod. The mode optimization fails: {{{ POSTERIOR KERNEL OPTIMIZATION PROBLEM! (minus) the hessian matrix at the "mode" is not positive definite! => posterior variance of the estimated parameters are not positive. You should try to change the initial values of the parameters using the estimated_params_init block, or use another optimization routine. warning: The results below are most likely wrong! }}} Commenting out line 123 of resol.m fixes the problem: {{{ oo_.steady_state = steady_state; }}} -- Ticket URL: <https://www.dynare.org/trac/ticket/169> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] bug in resol
by Michel Juillard 09 Mar '11

09 Mar '11

Thanks Marco for finding this tricky bug. It is a complicated issue that stems from two poor design decisions: 1) using the global variable oo_.steady_state in *_dynamic.m 2) an unclear distinction between oo_.steady_state and dr.ys: the rule that I had in mind was - oo_.steady_state is set by instructions initval and steady - dr.ys is the steady state computed for local approximation But this is not good enough and as you found out creates problem for steady_state operator What makes the problem complicated is that the solution must work both for the simulation of deterministic models where dr.ys is not computed and for the (repeated, in estimation) local approximation of stochastic model where oo_.steady_state is currently not updated for new values of the parameters. A temporary fix is to set oo_.steady_state in resol.m. I will make that change and update to GIT today. In the long run, we have to find a way to pass the steady state values to *_dynamic.m as an argument and not as a global Best Michel On 3/8/2011 9:54 PM, Marco Ratto wrote: > Dear Friends, > > playing quite intensively with a model including the STEADY_STATE > syntax in model definition, I stepped into a subtle bug: > > when dynare_resolve is called, the resol routine checks if ys is the > steady state, if not it re/computes it and updates dr.ys and oo_.dr.ys. > However, oo_.steady_state is not updated and the latter is used in > <model>_dynamic.m. This implies a wrong model solution. > In order to fix it I would simply update oo_.steady_state before > calling dr1 or dr_block in resol.m. > Otherwise, if there is a reason why only dr.ys should be kept updated > laving oo_.steady_state as it is now, then the pre-processor has to be > changed and the use of oo_.steady_state in _dynamic and param_derivs > files should be replaced by oo_.dr.ys. > > Just let me know how I should proceed. > Many thanks for your help > best > Marco >

3 2

Dynare Website
by stephane.adjemian＠gmail.com 26 Feb '11

26 Feb '11

Dear all, We have just changed the first page on the Dynare website. Please have a look, all feedbacks are welcome. Best, Stéphane. -- Stéphane Adjemian Université du Maine, GAINS & CEPREMAP http://www.dynare.org/stepan

4 3

Re: [DynareDev] identification/sensitivity
by Michel Juillard 22 Feb '11

22 Feb '11

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 >

4 7

Dynare Quickstart
by Sébastien Villemot 21 Feb '11

21 Feb '11

Hi all, Vincent Crevot has written a "quick start" page for Dynare: http://www.dynare.org/documentation-and-support/quick-start It is targetted for Windows users (which represent the vast majority of our users). Please let us know if you have any comments or suggestions of improvements. Best, -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: sebastien.villemot(a)ekiga.net PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

2 1

Re: [DynareDev] prior specification on SBVAR coefficients
by Michel Juillard 19 Feb '11

19 Feb '11

Hi Jake, I know that you all are busy with the new release, but I wanted to try and keep things moving on the ms-sbvar code. Excellent! > I wanted to make a suggestion on the pre_processor inputs to handle > some of the new functionality that we wanted to be have in ms_sbvar. > > 1.) Instead of having "estimate_model" could this be changed to > "mode_file=FILENAME" similar to the estimation command for dsge models? > It needs to be coupled with mode_compute=0, even if there are not alternative algorithms for computing mode for MS SBVAR models > 2.) To have a user be able to load previous simulations could they > specify "load_mh_file" Yes > > 3.) For the Impulse Response Functions, should the user specify > "irf=INTEGER" or "bayesian_irf" > irf=INTEGER specifies the length of the IRF (in solving/simulation and in estimation) bayesian_irf requests the posterior distribution of the IRFs (in estimation) so in estimation context, both options may be used > 4.) Should "optim=()" be added for the user to be able to adjust > csminwel options (maximum block iterations, convergence increment > value, etc.) > optim=() was designed a long time ago to pass optimization options for Matlab's fmincon(). It has the advantage of passing option names that are not known from the preprocessor. It would certainly be desirable to let the user specify options for csminwel. I'm a bit hesitant about just passing arbitrary option names as in in optim=() or putting in the preprocessor the list of options for each optimizer known to Dynare that can be changed by the user. What do you think? > 5.) The simulation options can be simplified to work with Dan's new code: > > n_draws=INTEGER (draws to save) Should this be changed to mh_replic= ? yes > burnin=INTEGER we use drop=INTEGER > thinning_factor=INTEGER what exactly does thinning_factor? > mh=INTEGER (Tuning period for adaptive MH), perhaps another name > 'adaptive_mh_draws'? adaptive_mh_draws is OK by me We should probably also use adaptive_mh_draws in DSGE estimation > (thin*n_draws+burnin = total number of draws) > > The current options in the preprocessor that relate to simulation options: > > n_draws > thinning_factor > proposal_draws > draws_nbr_burn_in_1 > draws_nbr_burn_in_2 > draws_nbr_mean_var_estimate > draws_nbr_modified_harmonic_mean > dirichlet_scale > > All the best, Michel > Jacob Smith > Quantitative Research Analysis Specialist > Federal Reserve Bank of Atlanta > 1000 Peachtree St NE > Atlanta, GA 30309-4470 > Phone: 404.498.8093 > Email: Jacob.Smith(a)atl.frb.org <mailto:Jacob.Smith@atl.frb.org> > > On Feb 16, 2011, at 5:20 AM, Sébastien Villemot wrote: > >> Hi Jake, >> >> I didn’t merge your changes. To achieve your goal, you don’t need to >> introduce a new "vec_float" rule and all the associated logic (by the >> way, >> we should not use floats but doubles). >> >> A very easy way to achieve the same goal is to use "vec_value" in the >> Bison file. It is already used by "o_gsa_threshold_redform" option, and >> I think it does what you need. The strings are never converted to >> doubles, but we don’t need to have them converted: we just pass them >> over to MATLAB. >> >> Please update your changes (which should now become very minimal). >> Sorry for the inconvenience. >> >> Best, >> >> Jacob Smith <jacob.smith(a)atl.frb.org >> <mailto:jacob.smith@atl.frb.org>> writes: >> >>> Hi Michel, >>> >>> These changes have been pushed. >>> >>> Jacob Smith >>> Quantitative Research Analysis Specialist >>> Federal Reserve Bank of Atlanta >>> 1000 Peachtree St NE >>> Atlanta, GA 30309-4470 >>> Phone: 404.498.8093 >>> Email: Jacob.Smith(a)atl.frb.org <mailto:Jacob.Smith@atl.frb.org> >>> >>> On Feb 13, 2011, at 12:41 PM, Michel Juillard wrote: >>> >>> Hi Jake, >>> >>> thanks. I understand now. I looked at your last changes pushed to >>> dynare-jake.git >>> 1) your changes to ParsingDriver.cc (+hh) remove void >>> ParsingDriver::add_steady_state_model_equal_multiple() at the very >>> end of the file. I don't understand the change >>> 2) There is also a change to spaces in add_expectation() >>> 3) I prefer the longer option name >>> "coefficients_prior_hyperparameters" to the more cryptic "sz_prior" >>> >>> Could you please modify your last change and push it again? >>> >>> All the best >>> >>> Michel >>> >>> On 02/11/2011 10:11 PM, Jacob Smith wrote: >>> >>> Hi Michel, >>> >>> My apologies for the confusion in my last email, my addition >>> was to the ms_sbvar options list, so that the user just adds an >>> option if they want to change the hyper >>> parameters that relate to the Sims/Zha prior. I have pushed >>> these changes to the repository. >>> >>> To use Stephane's example on how you would modify the >>> hyper-parameters of the ms_sbvar model you would do the following: >>> >>> ms_sbvar(datafile = data_59Q2_05Q4, >>> freq=4, >>> initial_year=1959, >>> final_year=2005, >>> initial_subperiod=2, >>> final_subperiod=4, >>> nlags=4, >>> draws_nbr_modified_harmonic_mean=100, >>> sz_prior=[1.2,2.1,1.2,2.1,1.2,2.1] >>> ); >>> >>> The default has been set to sz_prior = [1.0 1.0 0.1 1.2 1.0 >>> 1.0], in the global_initialization.m file. >>> >>> Currently there are some bugs in the repository though that >>> have been introduced by the directories being renamed. I have not >>> wanted to step on anyone's changes so I >>> haven't made a commit to fix the problems with the >>> subdirectories (identification,etc.) in ms-sbvar not being loaded >>> into the user's path. >>> >>> I will be happy to make any modifications that you need if >>> this is not what you would prefer as it relates to how you specify >>> these hyper-parameters. >>> >>> Jacob Smith >>> Quantitative Research Analysis Specialist >>> Federal Reserve Bank of Atlanta >>> 1000 Peachtree St NE >>> Atlanta, GA 30309-4470 >>> Phone: 404.498.8093 >>> Email: Jacob.Smith(a)atl.frb.org <mailto:Jacob.Smith@atl.frb.org> >>> >>> On Feb 11, 2011, at 3:15 PM, Michel Juillard wrote: >>> >>> Hi Jake, >>> >>> currently, in Dynare, the main entry point is >>> >>> swz_sbvar(ms_flag, M, options) >>> >>> whith >>> >>> ms_flag = 1: Markov Switching; =2: simple SBVAR >>> M: parameters from the *.mod file (probably the only one >>> that one needs is M.fname) >>> options: all options >>> >>> 1) we should rename swz_sbvar() to ms_sbvar() and make >>> other changes required by the renaming of the directory >>> 2) your example seems to have only a small list of >>> options, how do you pass the other ones that are listed on the wiki? >>> >>> All the best, >>> >>> Michel >>> >>> On 02/11/2011 04:01 PM, Jacob Smith wrote: >>> >>> Hi Stephane, >>> >>> I have added this capability to the version I was >>> working on with other changes for the new code from Dan. Currently I >>> had named the option 'sz_prior' but could >>> easily change it to the name you suggest Michel. It >>> allows the user to to specify a vector of 6 floats, like so: >>> >>> ms_sbvar(datafile = data, >>> freq=4,initial_year=1959, >>> final_year=2005, >>> nlags=5, >>> draws_nbr_modified_harmonic_mean=10000, >>> sz_prior=[1.2,1.1,1.2,1.1,1.2,1.1]); >>> >>> I will be happy to push the changes to the >>> preprocessor along with the changes to some Matlab files to use >>> these options to the Dynare repository. >>> >>> Jacob Smith >>> Quantitative Research Analysis Specialist >>> Federal Reserve Bank of Atlanta >>> 1000 Peachtree St NE >>> Atlanta, GA 30309-4470 >>> Phone: 404.498.8093 >>> Email: Jacob.Smith(a)atl.frb.org >>> <mailto:Jacob.Smith@atl.frb.org> >>> >>> On Feb 11, 2011, at 7:32 AM, Michel Juillard wrote: >>> >>> Hi Stephane, >>> >>> thanks for reporting the problem. I think that we >>> should do both as we have only suggested priors for monthly and >>> quarterly. The code should fail and ask the >>> user to set his/her own values for the mu's when >>> the frequency is not monthly or quarterly. >>> I suggest to call the option >>> "coefficients_prior_hyperparameters" and require the user to supply >>> a vector of 6 real numbers. >>> >>> Please, always include houtan.bastani(a)ens.fr >>> <mailto:houtan.bastani@ens.fr> in the messages relative to this project. >>> >>> Best >>> >>> Michel >>> >>> On 2/11/2011 1:20 PM, T. Zha wrote: >>> >>> Jake: >>> >>> Please investigate the following problem. >>> >>> Thank you. >>> >>> Tao >>> >>> --------- >>> On Feb 11, 2011, at 5:35 AM, >>> <Stephane.LHUISSIER(a)banque-france.fr >>> <mailto:Stephane.LHUISSIER@banque-france.fr>> >>> <Stephane.LHUISSIER(a)banque-france.fr >>> <mailto:Stephane.LHUISSIER@banque-france.fr>> wrote: >>> >>> Dear Michel and Tao, >>> >>> The dynare interface does not let the user to >>> change the prior specification on SBVAR coefficients. In the file >>> “msstart_setup” (from line 112), you can see >>> that the priors (mu) are defined for monthly >>> data. If the user wants to use quarterly data, he has to change the >>> values of mu_i directly on this file. >>> In order to improve this, I think that two >>> solutions are possible : >>> 1) Adding an interface in dynare for >>> defining its own values. >>> 2) Following Sims and Zha (1998) ‘s >>> suggestions and in this case, here is an example : >>> >>> % === The following mu is effective only if >>> options_.ms.bayesian_prior==1. >>> if (options_.ms.freq==12) >>> mu = zeros(6,1); % hyperparameters >>> mu(1) = 0.57; >>> mu(2) = 0.13; >>> mu(3) = 0.1; >>> mu(4) = 1.5; >>> mu(5) = 5; >>> mu(6) = 5; >>> elseif (options_.ms.freq==4) >>> mu = zeros(6,1); % hyperparameters >>> mu(1) = 1; >>> mu(2) = 1; >>> mu(3) = 0.1; >>> mu(4) = 1; >>> mu(5) = 1; >>> mu(6) = 1; >>> else >>> disp('Warning: this code is only good for >>> monthly/quarterly data!!!') >>> return >>> end >>> >>> Stéphane >>> >>> ************************************************************** >>> Ce mel est a l'attention exclusive des >>> destinataires designes. >>> Il peut contenir des informations >>> confidentielles. >>> Si vous le recevez par erreur, merci d'en >>> informer sans delai l'expediteur. >>> >>> Le contenu de ce mel ne pourrait engager la >>> responsabilite de la Banque de France >>> que s'il a ete emis par une personne dument >>> habilitee agissant dans le strict >>> cadre des fonctions auxquelles elle est >>> employee et a des fins non etrangeres a ses attributions. >>> ************************************************************** >>> >> >> -- >> Sébastien Villemot >> CEPREMAP - Paris School of Economics >> Homepage: http://www.dynare.org/sebastien >> Landline phone: +33 1 40 77 49 90 >> SIP phone: sebastien.villemot(a)ekiga.net >> <mailto:sebastien.villemot@ekiga.net> >> PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/) >

2 1

Release of Dynare 4.2.0
by Sébastien Villemot 15 Feb '11

15 Feb '11

Dear Dynare users, We are pleased to announce the release of Dynare 4.2.0. This major release adds new features and fixes various bugs. The Windows package is already available for download. The Mac and Linux packages should follow soon. All users are strongly encouraged to upgrade. This release is compatible with MATLAB versions ranging from 6.5 (R13) to 7.11 (R2010b) and with GNU Octave versions 3.0.x and 3.2.x (support for GNU Octave 3.4.x is not complete and will be added in the next minor release). Here is the list of major user-visible changes: * New solution algorithms: - Pruning for second order simulations has been added, as described in Kim, Kim, Schaumburg and Sims (2008) [1,2] - Models under partial information can be solved, as in Pearlman, Currie and Levine (1986) [3,4] - New nonlinear solvers for faster deterministic simulations and steady state computation [5] * Dynare can now use the power of multi-core computers or of a cluster of computer using parallelization [6] * New features in the user interface: - A steady state file can now be automatically generated, provided that the model can be solved analytically, and that the steady state as a function of the parameters is declared with the new "steady_state_model" command [7] - For non-stationary models, Dynare is now able of automatically removing trends in all the equations: the user writes the equations in non-stationary form and declares the deflator of each variable. Then Dynare perform a check to determine if the proposed deflators are compatible with balanced growth path, and, if yes, then it computes the detrended equations [8] - It is now possible to use arbitrary functions in the model block [9] * Other minor changes to the user interface: - New primitives allowed in model block: normpdf(), erf() - New syntax for DSGE-VAR [10] - Syntax of deterministic shocks has changed: after the values keyword, arbitrary expressions must be enclosed within parentheses (but numeric constants are still accepted as is) * Various improvements: - Third order simulations now work without the "USE_DLL" option: installing a C++ compiler is no longer necessary for 3rd order - The HP filter works for empirical moments (previously it was only available for theoretical moments) - "ramsey_policy" now displays the planner objective value function under Ramsey policy and stores it in "oo_.planner_objective_value" - Estimation: if the "selected_variables_only" option is present, then the smoother will only be run on variables listed just after the estimation command - Estimation: in the "shocks" block, it is now possible to calibrate measurement errors on endogenous variables (using the same keywords than for calibrating variance/covariance matrix of exogenous shocks) - It is possibile to choose the parameter set for shock decomposition [11] - The diffuse filter now works under Octave - New option "console" on the Dynare command-line: use it when running Dynare from the console, it will replace graphical waitbars by text waitbars for long computations - Steady option "solve_algo=0" (uses fsolve()) now works under Octave * For Emacs users: - New Dynare mode for Emacs editor (contributed by Yannick Kalantzis) - Reference manual now available in Info format (distributed with Debian/Ubuntu packages) * Miscellaneous: - Deterministic models: leads and lags of two or more on endogenous variables are now substituted by auxiliary variables; exogenous variables are left as is [12] [1] Kim, J., S. Kim, E. Schaumburg and C.A. Sims (2008), "Calculating and using second-order accurate solutions of discrete time dynamic equilibrium models", Journal of Economic Dynamics and Control, 32(11), 3397-3414 [2] It is triggered by option "pruning" of "stoch_simul" (only 2nd order, not available at 3rd order) [3] Pearlman J., D. Currie and P. Levine (1986), "Rational expectations models with partial information", Economic Modelling, 3(2), 90-105 [4] http://www.dynare.org/DynareWiki/PartialInformation [5] http://www.dynare.org/DynareWiki/FastDeterministicSimulationAndSteadyStateC… [6] http://www.dynare.org/DynareWiki/ParallelDynare [7] See the entry for "steady_state_model" in the reference manual for more details and an example [8] http://www.dynare.org/DynareWiki/RemovingTrends [9] http://www.dynare.org/DynareWiki/ExternalFunctions [10] http://www.dynare.org/DynareWiki/DsgeVar [11] http://www.dynare.org/DynareWiki/ShockDecomposition [12] http://www.dynare.org/DynareWiki/AuxiliaryVariables On behalf of the Dynare team, -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: sebastien.villemot(a)ekiga.net PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

1 0

Re: [DynareDev] [Trac] #5: Implement explicit writing of first order conditions of Ramsey problem
by Trac Dynare 10 Feb '11

10 Feb '11

#5: Implement explicit writing of first order conditions of Ramsey problem ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: enhancement | Status: accepted Priority: major | Milestone: 4.3 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by houtanb): * owner: sebastien => houtanb -- Ticket URL: <https://www.dynare.org/trac/ticket/5#comment:5> Dynare <http://www.dynare.org> The Dynare project

1 0