Replication of FRBNY DSGE model (Del Negro et al. 2013)

Dynare help (legacy posts)
1

Hi everyone!

I am trying to replicate with Dynare the DSGE of the NY Fed, as published in Del Negro et al. (2013)(econstor.eu/bitstream/10419/93628/1/771940254.pdf). I am referring to the loglinearised version of the model, so in the model block I use the option ‘linear’. For the parameters values and the steady state quantities I am using the information in the Matlab code the authors published (the code doesn’t run properly with the recent versions of Matlab apparently): some parameters come from an optimisation routine therefore. At first, I tried to play with the parameters but the only way to get around this issue was to change the time index of capital (kbar) in two equations so to turn one equation into a forward looking one (so, 9 eigenvalues >1 and 9 eqs).

At this point, the problem is the results of the IRFs, that turn out to be clearly wrong. Could you help me skimming through the code to check for some errors I cannot see?
I also tried to go on with the Bayesian estimation and get the following error: “Warning: Matrix is close to singular or badly scaled, results may be inaccurate” during the MCMC iterations.

Thank you!
Chiara
FRBNY_ATTEMPTV4.mod (11.4 KB)
datadelnegro2.xls (54.5 KB)

2

Dear Chiara,
the timing for the predetermined capital stock in your mod-file does definitely not conform to Dynare’s end of period stock notation. You need to fix this.

3

[quote=“jpfeifer”]Dear Chiara,
the timing for the predetermined capital stock in your mod-file does definitely not conform to Dynare’s end of period stock notation. You need to fix this.[/quote]

Dear jpfeifer,
Thank for your reply! I fixed the timing as you suggested (now the capital stock is lagged) and also reset the gamma parameter (st.st. growth rate) to 2.75/100. What it’s not clear in my mind about the capital is the fact that there is capital stock (kbar in the code) which must be lagged of 1 period to comply to the Dynare language, but also the effective capital (simply k, in the code) used in the intermediate good production: is the latter a variable that - in Dynare convention - must be lagged too?

Secondly, as some of the st. st. values and parameters are derived from the code, I’m not 100% sure about them, honestly - for example r_ss turns out to be equal to 1.5 from authors’ matlab code. With these modifications the code matches BK condition but the resulting IRFs are silly and puzzling, as the response oscillates. I attach this version of the code. Moreover, when going for the bayesian estimation, the option mode_compute=4 fails when initialising the MH with the following error:

[code]Warning: GAMINV did not converge for a = 0.003025, b = 9.09091, p = 1e-10.

In gaminv at 95
In prior_bounds at 94
In dynare_estimation_1 at 754
In dynare_estimation at 89
In frbny_v9 at 552
In dynare at 180
Error using chol
Matrix must be positive definite.

Error in metropolis_hastings_initialization (line 68)
d = chol(vv);

Error in random_walk_metropolis_hastings (line 62)
ix2, ilogpo2, ModelName, MetropolisFolder, fblck, fline, npar, nblck,
nruns, NewFile, MAX_nruns, d ] = …

Error in dynare_estimation_1 (line 782)
feval(options_.posterior_sampling_method,objective_function,options_.proposal_distribution,xparam1,invhess,bounds,dataset_,options_,M_,estim_params_,bayestopt_,oo_);

Error in dynare_estimation (line 89)
dynare_estimation_1(var_list,dname);

Error in frbny_v9 (line 552)
dynare_estimation(var_list_);

Error in dynare (line 180)
evalin(‘base’,fname) ;[/code]

When using mode_compute=6 the estimation starts but take literally forever to complete. What could be the cause for this error?

Thank you again,
Chiara.
frbny_v9.mod (13 KB)

4

Your oscillating IRFs from stoch_simul indicate that there is still a timing mistake in your model.

The capital stock is predetermined. You cannot change it within the period as investment today would only affect the capital stock used in tomorrow’s production.

However, capital services

where k is the capital stock and u the utilization rate, is not predetermined. Due to u being selected within the period, k_serv can be adjusted within the period as well.

5

have you resloved the problem?