I’m trying to run a robustness check of my DSGE model using a DSGE-VAR since the shock decomposition is producing a very high degree of volatility and potentially strange results.* I’ve seen a couple sources suggesting that if you don’t have stochastic singularity this is likely the result of model misspecification, and that all models have some level of misspecification. They suggested that running a DSGE-VAR and comparing against the DSGE can help figure out how bad the misspecification is because DSGE-VARs have more stringent restrictions on the parameters. Is this an accurate assessment of both the potential for misspecification in the model and the utility of a DSGE-VAR in helping to quantify this misspecification in a certain sense?
However, when I try to run the DSGE-VAR, I get the repeated error “Warning: Matrix is close to singular or badly scaled. Results may be inaccurate.”
If I try to run the DSGE-VAR with the “bayesian_irf” estimation option enabled, I get the error “ERROR: When estimating a DSGE-Var and the bayesian_irf option is passed to the estimation statement, the number of shocks must equal the number of observed variables.” It doesn’t matter how many shocks I enable or disable in my program though, I always get the error, so I’m not sure what’s going on.
Program and data are attached**. I am running Dynare 4.4.3.
*Some of this is likely due to using a two-sided HP filter for my data. I understand this is wrong, but I have not had time to implement a one-sided HP filter yet.
**See this post for updated data and code.
Yes, the loosening of cross-equation restrictions will alleviate model misspecification, but it can be hard to figure out where it actually is. Moreover, are you sure estimation really worked? Your data still looks somewhat strange. It is not mean 0 and might have a seasonal pattern. Were the mode_check plot ok?
You currently have 12 observables. For that reason, you can only have 12 defined
varexo. Setting variances to 0 is not sufficient here.
Are the warnings there occasionally or do they happen for every iteration?
It seems like the error appears every iteration.
[quote=“jpfeifer”]Moreover, are you sure estimation really worked? Your data still looks somewhat strange. It is not mean 0 and might have a seasonal pattern. Were the mode_check plot ok?
The model estimated and produced results, so I assumed it worked. I didn’t look at the mode_check plots, so I’m not sure on that point, I will check. I also assumed that an approximation of mean 0 as a result of HP-filtering would be okay, but I went back and re-demeaned the data.*
As for the data, the base data is strange in general. We used the X13-ARIMA seasonal adjustment method (in E-Views) to seasonally adjust it, and then a two-sided HP filter to detrend it. There’s a lot of volatility in that time period though, and I’m not an expert on either seasonal adjustment or data filtering methods so I can’t really comment on why the data looks strange. Other than looking at the mode_check plot what would you recommend?
Just for clarification,
This restriction only applies for the DSGE-VAR with Bayesian_IRF, it does not apply to a general DSGE?
Thank you for your help!
*Updated data is attached. The first set of data I posted was a truncated data set, this is the full series for each variable. I have also attached the demeaned 1-sided HP filtered data, and a version of the model that removes two of the exogenous variables, eps_sh_i and eps_sh_m.
DSGEVarTest2.mod (32.2 KB)
TestData2SidedHP.xls (33 KB)
TestData1SidedHP.xls (36 KB)
So please check whether the mode was found.
If you did seasonal adjustment, then this is all you can try. The two sided HP-filter should give you mean 0 data, that’s why I was puzzled by the non-zero values. But if you only showed me part of the data, that might explain the difference.
A VAR must have exactly as many shocks as observables. With fewer, there is stochastic singularity, with more the shocks would not be identified. That is where the restriction comes from. It is not present in DSGE models as you are estimating a VARMA model instead (there are still conditions on identification).
The mode was not found for a relatively large number of parameters. I’ve attached a sample.
This is using the two-sided HP filter, I’ll be running the one-sided again later to check that. This is estimated using the program with all 14 exogenous variables (rather than the truncated version posted for the DSGE-VAR) because the truncated version would not estimate using the two-sided HP filter (Log data density [Laplace approximation] is -Inf).
What can be done if the model isn’t finding the mode? I don’t have another option other than this data set and model for right now.
Mode check plots.pdf (8.44 KB)
Could you please provide the most recent version of the mod-file and the data for the DSGE model?