How to choose prior means?

General DSGE Modeling Replication Attempts
1

Hello,

I am replicating a paper similar to Smets and Wouters (2007) with my own data. I have measurement equations and the data. I guess the prior distributions can just be set to standard ones. But I would like to know how to specify prior means? I have read the dynare manual and the guide to observation equations, but did not find much on that topic. I would be looking forward to your answer.

Best

Jing

2

This is pretty well documented in the reference manual - which you suggest you have read - as well as in many of the tutorials, guides, and examples. Can I ask what you have tried? It’s hard to know exactly the source of confusion here is. Are you asking the positive question “how do I implement a given prior for a particular parameter in dynare”? Or are you asking the normative question “how should I go about deciding on the prior I want to implement”?

3

Hi bdombeck,

Thanks very much for your prompt reply. I am just wondering if the prior mean should be related to my data, and how. For instance, suppose I have a measurement equation for output. dy = y - y(-1) + ctrend. And I have a time series for dy. Is there some rule that I need to stick to when I set the prior mean for “ctrend”?

My problem is that the estimation code works for the original data (for US), but not for my data (for UK). The error message is that the Hessian is not positive. So I am trying to find out why.

And I have another question: Does it matter if one mode check plot has some red dots? If so, how should I fix the problem?

Best

Jing

4

Based on this my suspicion is your issues are to do with the data you are feeding in rather than the specification of priors. As a first step I would recommend calculating and comparing the means and standard deviations of the corresponding observables from each (e.g. “consumption series for US” and “consumption series for UK”).

Issues with mode-finding frequently arise from issues of scaling or trying to match demeaned data to a positive-meaned model variable. In your example above, it looks like dy has a steady state value of zero, assuming ctrend is a mean-zero exogenous stochastic process. In that case you should make sure your empiric counterpart for output growth has also been demeaned.

See remarks 13 and 10 in A Guide to Specifying Observation Equations for the Estimation of DSGE Models, which deal with the issues of forgetting the mean and scaling, respectively.

These should be simple to diagnose: the theoretic moments are calculated from the stoch_simul command and contained in “oo_.mean” and “oo_.var” respectively. If these values for your model-observables are quite different than those of your actual data, you have likely found your problem.

EDIT: You also asked

This depends on what ctrend is supposed to measure. Is it measurement error? In that case you would use your understanding of the actual data gathering process for guidance. Do you have a reason to suspect that there are systematic mistakes made in measuring the data? My sense is generally we assume measurement error shocks are mean zero. But there are cases in which a reasonable person could probably make an argument for non-zero mean shocks. For example it is well known that measuring inflation using the CPI biases the inflation rate upwards.

I will leave it to others on the forum to comment on this idea.

5

Thank you very much for your detailed answer! I’ll try out these thoughts soon. :grinning:

6

I had another thought about this: you have not described what ctrend actually is. My answers above assumed it was some kind of exogenous stochastic shock such as measurement error. But the name you have given it suggests it may be an endogenous variable related to the trend growth rate of non-demeaned data used to detrend non-stationary model variables, such as the growth rate of output term \mu^{y}_{t} in e.g. Schmitt-Grohe and Uribe (2012) and Born, Peter and Pfeifer (2013). As you can see in these papers, the steady state value for this variable is calibrated to the sample average of the corresponding data series.

7

I see! Thanks a lot! I will try this out immediately

8

Hi bdombeck,

Would you like to take a look at my code, when you have some free time, please?

Following your thoughts, I have checked the oo._ sections and changed some of the initialized parameters in the parameter block so that they are close to my sample means, but the code still doesn’t work. You could just give me a brief impression what you think the problem is, and how I could fix it, if time is tight.

Posterior_Generation.mod (22.3 KB) data.mat (5.4 KB)

9

There are significant differences in the means given by your data as compared to the means of the corresponding observable model variables. For example, the mean of the variable rspreadobs is 0; the mean of the corresponding data is 0.7427. The problem is reversed for the labobs variable, where you’ve tried to match a model variable with positive mean (0.10) to a data series with a mean of zero. There are also orders of magnitude differences in the volatility between some of your data and the corresponding model observables.

Essentially you are forcing the estimation routine to try to account for means and volatilities which are very different. This frequently pushes parameters to their boundaries which results in a non-pd Hessian.

2 Likes
10

Thanks very much, bdombeck! I am currently trying to match those values carefully.

May I ask you another question? Suppose that I have such time series data. What are the differences between the values to be entered in the 1. parameter block (initialize parameters which are to be estimated); 2. initval block (initial values for the observables); and 3. the estimation block (initial values)? Do they all have to be the same with the sample means of the time series? I have seen some discrepancies in the original paper, which is why I am wondering about this.

Best

Jing

11

The initval block is about finding the steady state for the endogenous variables and has nothing to do with the estimation of parameters.
The parameter initialization is for simulating the model. The estimated_params-block is about the starting value of the parameter for mode-finding. Those two are often the same, but there is no strict necessity. Sometimes you are interested in simulating the model before estimation with a parameter value different from what you think the mode might be.

12

Hi bdombeck,

Thanks to your help–after changing the initialized values of the parameters in the model, the code could work, but there are still red dots in some mode check plots. Just now you mentioned that the volatility between my data and the model observables are also different. And I can also see this from using the oo._var command. But how can I match them? I mean–how to change the theoretical volatility once I know the volatility of the data? I guess the theoretical volatility comes from the shocks, but the link with that of the data doesn’t seem very straightforward, or does it?

Best

Jing

13

If it’s orders of magnitude, then typically there is some scaling error (usually a factor 100)

14

Hi jpfeifer,

Thanks for your reply. What I am wondering is that I have changed a different dataset for the model, and whether I need to make changes to the standard deviations of the shocks in the model, according to my own data too, and how?

Best

Jing

15

Please see

Everything should be explained there. Data and model need to be consistent.

17

Hi jpfeifer,

I am very sorry to bother you again. I have compared the theoretical standard deviation of the model variables and that of my data. I think there is a difference of 5 times at most. Would you please show me just one observable which has “a difference in orders of magnitude”, when you have some time to look at my code? (I think a scaling error of 100 is unlikely to arise because I had compared my measurement equations and data with those of the author before I put them in.)

And in general I am very curious about how to match the standard deviation of the model shocks to my data.

And the theoretical mean of the model variable robs is 1.17 compared to 0.58 in my data. Do you think problems could arise from there?

The problem is that I still have red dots in three of the mode check plots.

Posterior_Generation.mod (22.7 KB)
data.mat (5.3 KB)

Best

Jing

18
  1. When I use mode_compute=5 the model works.
  2. When adding options_.debug=1 you will get information where the red dots in the mode_check-plots come from. In your case, the model does not satisfy the Blanchard-Kahn conditions for those parameter values.
19

Hi JPfeifer,

Thanks very much for your time!

Does that mean that the boundaries for the prior distribution are not appropriate?

If I am unable to erase the red dots in the very end, are my estimation results ineligible?

Best

Jing

20
  1. The prior bounds seem unproblematic to me.
  2. It is completely normal that not the whole parameter space leads to unique stable solutions. So some red dots are normal.
21

Hi JPfeifer,

I see. So my estimation is successful. Thanks very much for your patience!

Best

Jing