Several beginner questions about DSGE models

[Hector Herrada]

Hi folks, I was wondering if the community could help me answer the following questions.

1. Monthly vs. quarterly data? Can we obtain a good DSGE BC model using monthly data instead of quarterly data (using production index as a proxy for GDP)?
   
2. ‘=#’ – I understand we need this language for non-linear simulation. Should this be used with EVERY non-linear equation in our model? If not, why shouldn't we use it with all of them? I noticed that in the SPBC example the Phillips curve does not have ‘=#’ and it looks like it is a nonlinear equation.
   
3. ‘!dtrends’ – Could someone please explain to me why we use ‘dtrends’ in the SPBC example, and what is the economic meaning of the estimated parameters for these deterministic trends?
   
4. ‘!links’ – From help guide: The dynamic links relate a particular parameter (or steady-state value) on the LHS to a function of other parameters or steady-state values on the RHS. Could someone please give me an example of when we should use this feature? 
   

Thank you so much for your time!

Hector

[Antti Ripatti]

4. This is useful when you (log)linear model manually. You need then solve the deterministic steady-state manually and you can code the ss solution. ie the steady-state point using !links

Antti

2013/10/8 Hector Herrada <hector....@gmail.com>

--
You received this message because you are subscribed to the Google Groups "iris-toolbox-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iris-toolbox...@googlegroups.com.
To post to this group, send email to iris-t...@googlegroups.com.
Visit this group at http://groups.google.com/group/iris-toolbox.
For more options, visit https://groups.google.com/groups/opt_out.

[Michael Johnston]

1. I've never tried, perhaps others can comment. Whatever monthly production index you use is probably going to be substantially noisier than quarterly GDP, so you probably want to deal with this. Measurement error, filtering... not sure what would work best in your case. 

2. Typically the quantitatively important nonlinearitites in a model will come from only a few equations (e.g., lower bound on nominal rates). Non-linear simulations increase the computational burden and also are not functional in all areas of IRIS (e.g., doesn't really make sense to do a shock decomposition with a nonlinear model). 

3. This can be used to linearly de-trend data before it meets your structural model. The economic content? That you are imposing a linear time trend which is going to automatically de-trend your measurement variables before they get linked to the structural model, and the deterministic trend will also show up in your forecasts of those measurement variables. For example, suppose that you want to linearly de-trend output where y_data is your observable and y_model is your structural variable so that y_data = a + b*t + y_model. In this case, you would code it as

!parameters

a,b

!measurement_variables

y_data,

!measurement_equations

y_data = y_mod ;

!dtrends

y_data += a + b*!ttrend ;

You can either assign the parameters a and b directly to the model object, or you can call filter() with the option 'outOfLik=',{'a','b;} and it will estimate them in a single call. It is also important that you not list these variables in your estimation structure when calling estimate(). 

4. Antti already covered this. :) I will just add that order of execution matters. E.g., 

!links

y = f(x) ;

z = g(y,x) ;

works, but

!links

z = g(y,x) ;
y = f(x) ; 

does not. 

--

[Hector Herrada]

Thank you both for your replies. As an exercise to get better with DSGE and IRIS I'm replicating Smets-Wouters model of the US economy in IRIS. Their model is linearized manually before it is input into the Dynare toolbox. With this in mind could someone please give me an example of how I could use !links in this case?

Thank you so much for your time!

Hector

[Michael Johnston]

If the model is already linearized, then you don't need a steady state in order to solve the model and the !links section is really not necessarily that useful. You can use it to define some parameters in terms of other parameters, but I can't come up with a situation where you could do this because it really depends on how you choose write the model. That is, if you are able to write c = f(a,b,...) then you could equivalently write your model file entirely without the parameter c. 

--

[Antti Ripatti]

If the model is large enough it is sometimes easier to use c. Mirek tried repeated substitutions in my recursive system of steady-state. It resulted more that 2 million digits ;-)

2013/10/10 Michael Johnston <mkjo...@gmail.com>

[Hector Herrada]

Thank you both. I think I am in the right direction. I found dynamic links useful in replicating Smets-Wouters model. The parameters in the 'dynamic links' depend on parameters that are included in the 'transition equations' section of the .model file. I am getting an error* when I try to estimate some of the parameters and I wonder if the reason is that some of the parameters in the 'transition equations' section depend on parameters being calculated in the 'dynamic links'. For example, I might have 'alpha', 'beta' and 'pie 'in 'transition equations', and 'theta' in 'dynamic links. 

'Transition Equations'

alpha = f (beta, trans variables)  ; shouldn't be a problem, but I wonder if...

pie = f (theta, trans variables); is causing a problem in the estimation procedure

'Dynamic Links'

theta = f (alpha) 

Thanks again! 

Hector

*Warning: Matrix is close to singular or badly scaled. Results may be inaccurate. RCOND =

2.129260e-16. 

> In ped at 258

  In model.mykalman at 268

  In estimateobj.objfunc at 63

  In nlconst at 740

  In fmincon at 841

  In estimateobj.myestimate at 45

  In model.estimate at 385 

On Tuesday, October 8, 2013 2:51:33 PM UTC-5, Hector Herrada wrote:

[Michael Johnston]

This error occurs because the model is numerically stochastically singular, at least at the current parameter values. This means the Kalman filter is not able to explain the observables using the shocks in the structural model. 

If the number of shocks is less than the number of observables then you will have stochastic singularity by construction. Since the condition number of the matrix is not NaN, I think this is not the case. 

If the number of shocks is exactly equal to the number of observables then it is fairly common to encounter this problem, particularly if the number of shocks and observables is large. There are alternative means of calculating the prediction error covariance matrix which attempt to deal with the problem, and I experimented with some of them in IRIS (e.g., square root form of the Kalman filter) but without a ton of luck. Usually it's better to just change the model. You could do things like add small values to the diagonal of the prediction error covariance matrix to make it invertible, but this is effectively just adding measurement error, so in that case better to just do that. 

If the number of shocks is greater than the number of observables then you are in better shape, but it's still easy to encounter numerical stochastic singularity in some parts of the parameter space. For example, the numerical effect of shock E on observable Y may be so small at some parameter values that the Kalman filter regards it as having no effect at all. 

Please provide more information about your model. Do you encounter this message immediately when you call filter() or does estimate() walk you into a bad part of the parameter space? If the latter, you can use the 'chkFmse=',true in the 'filter=',{} list of options when calling estimate(). 

 

--

[Hector Herrada]

I had attached the wrong version. Here's the is the right one.

Thanks!

On Tuesday, October 8, 2013 2:51:33 PM UTC-5, Hector Herrada wrote:

[Hector Herrada]

I have attached the Dynare version and the read_data_SW file. Thanks again!

On Tuesday, October 8, 2013 2:51:33 PM UTC-5, Hector Herrada wrote:

[Michael Johnston]

For some reason the Dynare code included doesn't work with the latest version of Dynare. I'm not up for sorting it out at the moment. 

But with estimate_SW.m I am unable to replicate the stochastic singularity problem. In fact, with pretty minor modifications I get convergence and at least technically everything works fine. 

I have attached a slightly modified version of estimate_SW.m. Could you please run this in the latest version of IRIS and confirm it runs without issue? 

--

[Hector Herrada]

Having the code working is exciting! Thanks, Michael! The dynare version of SW is indeed outdated (won't work with the current version of the toolbox). I am curious what made you think that changing the 'optimset' options would make the code work. 

Hector

On Tuesday, October 8, 2013 2:51:33 PM UTC-5, Hector Herrada wrote:

[Michael Johnston]

When I first tried to run it, I got a no solution error almost immediately. The initial value is apparently close to a region of the parameter space where the model will not solve. Using 'noSolution=','penalty' (the default is 'error') assigns a bad likelihood value to parts of the parameter space where the mode will not solve. 

After changing this option the code failed because the maximum number of iterations of the optimization algorithm was exceeded. The 'optimset=" option allows you to pass a cell array of options to whatever optimizer you are using. Increasing the maximum number of function evaluations and iterations gave convergence. 

I did not verify that it matches the Dynare results since I was not able to run that code. Perhaps you can do this? I am still perplexed I was not able to replicate the numerical stochastic singularity issue; even if the 'chkFmse=' option is false I never get a warning about the prediction error covariance matrix being ill conditioned. 

--

[Hector Herrada]

I ran the package of files that I sent you and did not get the singularity error either. I might have done something that got rid of it before sending the files. I am still getting slightly different results than the dynare code. SW include 'mode files' that are used in the estimation procedure, so I think that this might be the source of the differences. Do you know why they use mode files to initiate the parameter estimation procedure instead of letting the toolbox functions do the job? I have not found any option in IRIS that would allow me to input a 'mode file' into the estimation procedure.

Thanks,

Hector

On Tuesday, October 8, 2013 2:51:33 PM UTC-5, Hector Herrada wrote:

[Michael Johnston]

I think the mode files are just Dynare's way of initializing estimation at some saved values. 

How different are the results relative to Dynare? Post numbers. Are the priors, initial values, and optimizer the same? We can at least narrow down the possible reasons for differences. 

--

[Hector Herrada]

You are right in regards to the 'mode files'. This significantly reduces the time required to run the estimation procedure. Smets and Wouters are not clear in regards to how they obtain these files (they are just part of the download package). I have attached an excel file with numbers comparing 1) the table published in the paper, 2) dynare w/ mode file, 3) dynare w/o mode file, and 4) IRIS results. (all files needed to get these numbers are also attached).

Some comments:

1. The numbers obtained with the mode file are pretty much the same as in the paper;
   
2. Not using a 'mode file' results in bigger differences vs the numbers published in the paper;
   
3. Priors, initial values, and the options for the optimizer are the same. There are a couple of extra inputs in dynare that I could not figure out and may be causing these differences. These options are the following: presample, lik-init, prefilter.
4. I noticed that the first output of 'estimate' is described as point estimates and these sometimes differ from the new parameters estimated (see Excel file). All this time I was assuming that the new parameters were the modes of the posterior distributions. Could you please shed some light on the differences between modes, the new parameters, and the first output of the 'estimate' function?
5. 'constelab' was the parameter that had the biggest differences.
6. I made some trivial modifications to the original dynare file so that you can now run it on the latest version.

I hope you are having as much fun as I am. 

Thanks!

On Tuesday, October 8, 2013 2:51:33 PM UTC-5, Hector Herrada wrote:

[Michael Johnston]

Thanks for sending over the comparison. This is fun indeed. :) 

1-2. The model likely has a lot of local minima and hence starting values affect the results. I would at least hope that the likelihood value for the parameters in the paper is the better one. If you are having problems with local minima and initial values, the particle swarm optimizer can work quite well. It's far better at this than gradient based methods or pseudo-evolutionary parametric methods like CMAES, but non-parametric genetic algorithms (as in the Global Optimization Toolbox) offer good competition. 

3. I don't really know Dynare very well, so I'm just guessing at some of this based on my reading of the manual. The prefilter option will demean the data automatically. In IRIS you can do this using the !dtrends section with just an intercept and no time trend. Presample in Dynare seems to allow you to initialize the Kalman filter at the beginning of the sample but only calculate the likelihood over a portion of the range. You can do this in IRIS using the 'objRange=' option for the Kalman filter. Lik_init in Dynare has to do with the fact that when you initialize the Kalman filter you don't know the initial pseudo state or MSE matrix. Based on the description in the manual I'm not really able to say much about what those options do. But in IRIS you control this using the 'initCond=' option, again with the Kalman filter. See help model/filter for more info. 

4-5. The shock standard deviations may differ when 'relative=',true with the Kalman filter, but otherwise everything should be the same. The reason some other parameters differ between the values returned by the optimization routine and the estimated model object is that some of the parameters you are trying to estimate, like constebeta, constepinf, etc., are listed as left-hand-side variables in the !links section. Also not really clear why one would try to estimate things like constebeta which have no effect on the likelihood, at least the way the model is written now. If you deal with these cases then everything lines up perfectly. 

There are much easier ways of estimating things like constepinf and constelab. If you include these parameters instead in the !dtrends section and remove them from the !measurement_equations section (see attached example) then the Kalman filter can estimate these in a single pass. (Be sure not to include them in the list of parameters you want to estimate... just set the dtrends filter option to true.) You can't place a prior on it in this case, but it's not really clear why one would want to. I understand at present you're just trying to replicate what someone else did in another environment, but this is arguably a better approach going forward. 

6. Thank you!

This isn't really that important, but I noticed you're using str2dat() to create dates (e.g., S1 = str2dat('1966Q1')). Usually I find it faster to use the date functions, e.g., you can just write S1 = qq(1966,1) to the same end. 

--

[Michael Johnston]

Also I forgot to mention that the Hessian returned by model/estimate() is the one used by the Optimization Toolbox. This means that it isn't the true Hessian but is approximated by the last N steps the optimization routine took (or something like this... it's basically BFGS). As such it's going to be a pretty bad way to get standard errors for parameters. Anyway, the assumption of normality is also not typically very realistic for the samples/models we're dealing with, Hessian approximation errors aside. I realize it takes a lot longer, but for any statistical inference a long MCMC chain is absolutely preferable. In IRIS this is implemented in poster/arwm, and there is information in Jaromir's Simple SPBC tutorial. 

[Hector Herrada]

Good stuff, Michael. Thanks!

The model is working now so I will spend sometime playing with it to understand its dynamics. I have a couple more questions:

1. I understand that because the model is linearized already and the steady states were derived manually we don't really need the functions 'sstate' or 'solve'. Right? When running the estimation procedure I do not need to have initially assigned values to the parameters that are being estimated (NaNs when called with 'get'). I only need initial values for those parameters that will remain fixed. If this is correct I guess that it implies that sstate/solve aren't needed.
2. How far back do practitioners go as far as data to estimate DSGE models? What factors play in this decision?
3. Any source you would recommend as far as 'well' accepted values for certain parameters in a certain economy?

Michael, Jaromir and Antti, you have been fantastic. Although I'm still feeling a little bit overwhelmed by all of the background workings in a DSGE framework, I find it extremely interesting. Without your help a person with an average economics background like me would have found it very hard to get his hands dirty with these models. THANKS!

[Michael Johnston]

1. 'solve=',true just re-computes the solution to the model. I would almost always leave this set to the default, true. I guess the only case where this would be relevant is if you're only estimating shock standard deviations. If you do not assign initial values to the parameters you want to estimate (you just set them to NaN) then IRIS will use the values in the initial model object. You're still supplying initial conditions, just by a different way. Any gradient-based optimizer needs some kind of starting point. :) 

2. Tricky question. Country-specific. Lots of factors including monetary policy regime changes, data measurement issues, amount of available data for the current regime, your ability to model those changes in a plausible structural way, etc. This choice is also nuanced in the sense that you can initialize your Kalman filter at one point in time and start computing the objective function at another. 

I'm currently working in South Africa and I would regard pre-1994 data (Apartheid-era) as not particularly valuable in building a business cycle model; the structural change is too great and there's no plausible way to model it and control for it. Most of the time I look only at the inflation targeting period (2000-present). I guess I could try to come up with a way to model the pre-inflation targeting regime using a time varying inflation target but it seems like a lot of work to get a few years of extra data, and there's the chance that I will bias my parameter estimates if I don't properly control for the regime change. Also the data definitions may change over time depending on your country and this also complicates things. 

3. No. Looking at single parameters in a general equilibrium model isn't going to tell you that much anyway. You're interested in the properties of the model as a whole and it's pretty hard to conclude much about a model by looking at individual parameters. This is one of the reasons it's difficult to map desired model properties into traditional priors, and one of the advantages of the work Jaromir and Michal Andrle have done on system priors (where one is able to place place priors on more general model properties than individual parameter values). A lot of how you evaluate the model depends on the secondary evidence you have and which key properties you need to match, and a lot of this is country-specific (or even institution-specific... maybe some senior person(s) have strong views on some aspect of the model). 

Glad you are having fun! 

[Hector Herrada]

Michael,

I followed your suggestion and used !dtrends instead of having constants in the measurement equations. This was handy because I now have individual dtrends for investment, output growth, real wages, and consumption (in SW the same single constant was shared among these four variables). On the other hand, the constant in the measurement equations was linked to the steady states parameters of the system (cgamma – ss value for output growth and cpie – ss value for inflation), so now the steady state values of the measurement variables are zero for all those variables that used dtrend (instead of values related to the ss parameters).

How can I make sure that the steady states of the measurement variables are related to the steady state parameters of the system and still use deterministic trends? Do I really need to achieve this? If variables revert to the dtrend values, what is the role of parameters such as cpie and cgamma?

I am hoping that the answer to the previous question might be related to the model’s performance on replicating first and second moments of the measurement variables (See ‘Christmas trees’ chart). Note that Consumption, Output, Investment, and Real Wages mean distributions show a gap (actual vs model-generated data), unlike the other three variables that seem to be more appropriate. The second moments for all variables are reasonable. Obtaining a model that explains well the data is of course one of my main goals with this exercise.

Also, I suspect my modification of the model with dtrends have affected the effectiveness of the estimation of gamma and cpie because the maximized modes are now especially sensitive to their priors. Data does not seem to be informative at all. Would this make sense? I understand, however, that either method (constant in measurement equation or dtrend) modifies the measurement variables before these are in contact with the model. The differences between the dtrends and the constant should therefore not be that different.

I feel that I am very close to understanding this particular model and the mechanics of any DSGE model in general. Your input or that of any member in the community would be extremely valuable. I have attached two sets of codes – one with the model using dtrends and the original one (SW). I would run everything in the following order:

1.        Load Data
   
2.        Calibration
   
3.        Estimation
   
4.        Filter
   
5.        Performance
   

Any input will be greatly appreciated. Thanks!