Question on estimation options

[kgarb]

Under the estimation block, there are a ton of options and I have questions on a couple.

My first question relates to the "loglinear" command. The default is for Dynare to linearize the model and the data, but what happens if your model and data are already log-linearized? Does Dynare's linearization affect the model/data specification at all, and if so is there a way to turn this off?

mh_replic, mh_nblocks and mh_drop: In my model, if I set mh_replic to 60,000, mh_nblocks to 15, and mh_drop to .3, Dynare accepts 13 of the blocks, and then uses blocks 4 through 13, before accepting 42,000 replications. How does this work? That is, what are the conditions under which it accepts blocks, and then does it draw only the best replications from each block to get the (60,000 - (60,000*.3))=42,000 best replications? Or does it use each block that it accepted as a unique, separate set of data to increase the "observational" size of the estimation?

As a side-note, should I be worried if the model says there are not enough replications to compute the posterior densities (I think that's what it said? I'll double check later, running another estimation right now and it takes about four and a half hours given the above MH conditions). I'm considering increasing the number of replications to 100,000 and leaving mh_drop at .3, or is this a situation in which I would need more actual observations? I have 52 data points across five variables for estimation right now.

Finally, can high volatility or structural breaks in a supposedly log-linearized data series cause problems with the estimation? One of my series is oil prices (pr_O) in domestic currency, and the (deviations from steady state - steady state calculated as the average over the time period) series causes all kinds of problems once I try to incorporate it into and otherwise-working estimation. The error it produces if oil prices are included (given the above estimation conditions) is "Estimation::marginal density: There's probably a problem with the modified harmonic mean estimator."

Relevant files are attached.

[jpfeifer]

- loglinear
There is no "loglinear" command, only an option of that name so your question is ambiguous. If your model and data are already log-linearized, you cannot use the "loglinear" option. The reason is that your loglinearized variables have mean 0 and taking the log of them is impossible. If you mean your model is already linearized and you wonder what happens during regular linearization (without "loglinear"): a linear model is invariant to linearization. So nothing happens. That's why you don't need to do anything. Regarding data: you need to specify a correct observation equation. Your observation equation seems incorrect as you have mean 0 model variables and non-zero data. See Pfeifer 2013: A Guide to Specifying Observation Equations for the Estimation of DSGE Models" at https://sites.google.com/site/pfeiferecon/Pfeifer_2013_Observation_Equations.pdf

- mh_replic, mh_nblocks and mh_drop:
What do you mean with Dynare accepts 13? Could you provide the output from the logfile, please. mh_drop specifies the burnin for each MC Markov Chain. This is supposed to assure that the chain has converged to the ergodic distribution. Thus, from each chain, Dynare drops mh_drop percent of the mh_replic total draws. mh_nblocks specifies the number of independent Markov Chains. As all chains converge to the same ergodic distribution after a sufficient burnin, Dynare simply pools the remaining draws. In your case, you should have 15*60000 total draws if which in the end 15*60000*(1-0.3) should be available.

- Sidenote: in Dynare 4.4.3 there is a bug that makes this error message appear even when the moments are actually computed. Check whether the moments are in their respective fields.

- Yes, breaks and incorrect adjustment as well as incorrect observation equations will lead to problems. Try fixing the observation equations first.

[kgarb]

Thank you for your response!

-Yes, I meant the loglinear option under the estimation command. I read your guide previously on correctly matching the data to the model and detrended/demeaned my data (data detrended using an HP filter, etc.), but it looks like I forgot to make sure that applied after the conversion to percentages. Will fix.

- mh_replic, mh_nblocks, mh_drop: I'll post a log file sometime this weekend, currently running a host of other tests. I will double check whether the moments are in their respective fields though.

[kgarb]

I corrected my data to being mean zero, measured as (log) percentage deviations from the steady-state (and thereby having observation equations in which [data = variable], eliminating the need for explicit observation equations), but I'm running into three different, related (I believe) errors depending on which shocks I choose to use in the model.

Summary: I have five observed variables in my model, and the original model specification has seven shocks. To avoid stochastic singularity, I select exactly five of these at a time to incorporate in the model. Depending on which ones I select, I either get immediate errors telling me the matrix is singular to machine precision (but the estimation process continues), an error after about an hour telling me that the cholesky input matrix must be positive definite, or an error after the mh_blocks process telling me the log posterior likelihood is -inf, that there is a problem with the modified harmonic mean estimator and (if I let it keep running) that the habit formation parameter is equal to unity (which is impossible, since that necessarily implies a divide-by-zero error in the MRS equation (line 108, equation 13). I believe all of these errors are in some way linked to the model attempting to set the value of the household's habit formation to values centered at or near unity, but I don't understand why it is attempting to do that.

Clearly something is wrong, but after trying the set of suggestions here I am at something of a loss. I tested with up to 120,000 replications across 15 blocks using mode_compute=6, mode_compute=9 doesn't solve the problem, I am at least relatively certain that the data matches the model, and I tried updating the parameters to match the estimated values from one of my very few completed estimations (the values of which are likely spurious, but I had to see if that would help convergence, which it didn't).

What am I missing?

Seeing as Dynare is a popular and robust estimation framework (and the model of interest was originally estimated in Dynare) I'm guessing that the problem rests in the model or the data. I've successfully run the model using stoch_simul and the results seemed reasonable (though I am uncertain over which variable to force to "end of time period" conventions to match # of eigenvalues and # of forward looking variables; see lines 75-78), so that leaves the data. Is 52 observations enough to estimate 24 parameters? Does the low number of observations necessitate stronger priors for identification, or is there something else I'm not aware of?

Which diagnostic commands will be particularly useful for helping with this?

(files are attached)

Thank you in advance for your comments!

Edit: Just ran the model with one observed variable (y_GDP), one shock (epsilon_ppistar), 20,000 iterations and 8 mh_blocks as a test, and got the following error message under the identification analysis: "The number of moments with non-zero derivative is smaller than the number of parameters up to 10 lags: check your model
Either further increase ar or reduce the list of estimated parameters." What specifically are these moments associated with (i.e. the data? or the parameters?), how are they defined, and what is their relation to the data being used for the observed variables? Does this imply that I don't have a long enough data series?

Thanks again!

[jpfeifer]

First things first: I find it strange that some steady state values of your linearized models are calibrated as parameters that are kept fixed during estimation. This is generally wrong unless you estimate only parameters that do not affect steady states. For example, how can

Code: Select all

c_Hy_Hsteady

be fixed when you estimate alpha?

Forget about multiple chains. Only use one (long) chain for now until you have solved the issue.

Stochastic singularity only tells you that you need at least as many shocks as observables. You can have more shocks than observables.

It is strange that you fix the standard deviations of the shocks to 1 instead of estimating them. You will force the persistence to account for the movement then.

Regarding diagnostics: look at the mode_check plots whether they make sense.

Given the relatively few observations, you might need goods priors.

Regarding the error message from identification: that is to be expected. A parameter is identified if and only if it affects at least one first or second moment independently (the stochastic disribution of a linear model is fully characterized by its first and second moments). When you observe only output, every parameter needs to independently affect the mean or one of the autocorrelations. By default, Dynare considers up to 10 autocorrelations. It should be clear that this won't work with 24 parameters.

[kgarb]

First things first: I find it strange that some steady state values of your linearized models are calibrated as parameters that are kept fixed during estimation. This is generally wrong unless you estimate only parameters that do not affect steady states. For example, how can

Code: Select all

c_Hy_Hsteady

be fixed when you estimate alpha?

These steady-state values are explicitly fixed as time-invariant parameters in Beidas-Strom and Poghosyan (2011) based on observed data, which is the methodology I am currently applying. I will keep your comment in mind for future work with the model; would the solution here simply be to incorporate them under the "estimated_params" block?

Forget about multiple chains. Only use one (long) chain for now until you have solved the issue.

I will try this.

Stochastic singularity only tells you that you need at least as many shocks as observables. You can have more shocks than observables.

I initially thought that the identification problem I've been experiencing was a result of attempting to incorporate more shocks than observed variables, since the first (mis-specified) estimations converged when n(varobs) = n(shocks) but not when n(varobs) < n(shocks), but I've been running estimations in the days since with far more iterations and see now what was going wrong.

It is strange that you fix the standard deviations of the shocks to 1 instead of estimating them. You will force the persistence to account for the movement then.

Initially this was just for purposes of testing whether the model was working. How would I estimate the shocks though? The Dynare reference manual (version 4.4.3) is unclear on the point.

Regarding diagnostics: look at the mode_check plots whether they make sense.

Ok

Given the relatively few observations, you might need goods priors.

I'll see if there's anything I can do on this point, but two questions: is it bad practice to estimate the parameters in a DSGE and then feed those posterior means back into the model as new prior means? And are "good" or "stronger" priors defined based on how close they are to the "true" mean (I realize this concept is a little strange in Bayesian terms, but I don't have a better way of expressing it), or by how small the standard errors can be set (and remain viable) to represent the confidence in a particular value being close to the true value?

Regarding the error message from identification: that is to be expected. A parameter is identified if and only if it affects at least one first or second moment independently (the stochastic disribution of a linear model is fully characterized by its first and second moments). When you observe only output, every parameter needs to independently affect the mean or one of the autocorrelations. By default, Dynare considers up to 10 autocorrelations. It should be clear that this won't work with 24 parameters.

Is setting the ar command to some large-ish number (i.e. ar=30) in the estimation block the proper way to fix this? When I run the model with far more iterations in the second burn-in phase (the one that estimates the covariance matrix that the cholesky matrix that's used for the later parameter estimations is calculated from, if I'm understanding the process correctly) this seems to become less of a problem. Why is that, if the number of autocorrelations doesn't change? Also, do you have any good sources on these points related to identification in DSGEs? I've read through some working papers here and there, but none of them have gone particularly in-depth on the point of identification, so I don't understand very well the underlying mathematics/statistics that create the rules that you've specified here.

Thank you for your comments!

[jpfeifer]

1. For estimating standard deviations, see the fs2000.mod in the Dynare examples folder.
2. Yes, it is bad practice to feed posterior means back into the model as new prior means for the same data. Your prior is supposed to not depend on the data. "Good" priors in your case are informative ones, i.e. ones that have a low standard deviation of the prior distribution.
3. You are confusing something. The ar-option of the estimation command has nothing to do with how many moments identification considers. It is only for reporting posterior autocorrelations. Please have a look at the references for identification in Pfeifer (2014): An Introduction to Graphs in Dynare available at my homepage. There you can already find some intuition.