Understanding the role of initial values in shock decomposition

Hello, While implementing the “Bridging DSGE models and the raw data” paper by Fabio Canova (2014), I encountered unexpected behavior in shock_decomposition that I’d appreciate help understanding.

The Issue:

  1. My toy RBC model includes an AR(1) productivity process: z(t) = rho_z * z(t-1) + eps_z(t), where z doesn’t depend on any other endogenous variables. I expected the “initial values” contribution in shock_decomposition to decay monotonically at rate rho_z^t. However, it fluctuates non-monotonically.
  2. Furthermore, the smoothed z values don’t satisfy the AR(1) law: comparing oo_.SmoothedVariables.z(2:end) with rho_z*oo_.SmoothedVariables.z(1:end-1)+oo_.SmoothedShocks.eps_z(2:end) shows significant discrepancies.
  3. Finally, in initial_condition_decomposition, z’s own contribution decays as expected, but the aggregate “initial values” still fluctuates.

Model Specification: Following Canova (2014), I use log-level data with:

  • A random walk with drift for labor-augmenting productivity
  • Random walk “noise” components for measurement errors
  • The productivity and noise drifts sum to match observed output growth

Key Observation: When I remove the unit root from the noise components (v0 version), the problem disappears - initial values decay monotonically for z. My understanding is that the Kalman smoother jointly determines initial states and shocks using the full sample. But why would this create non-monotonic initial value contributions for a simple AR(1) process? And why does the presence of unit roots in other (seemingly unrelated) parts of the model affect this? Any insights would be greatly appreciated!

rbc_v5_v1.mod (3.9 KB)

rbc_v5_v0.mod (3.7 KB)

data_example.csv (5.7 KB)

This looks like a bug. Try using kalman_algo = 4.

This was indeed a bug. Thanks for reporting it. A fix is available at fix bug in diffuse smoother with algo=3. rank of PINF should be checked... (!2433) · Merge requests · Dynare / dynare · GitLab and will be in Dynare 6.5.

Dear Johannes

Thank you very much for looking into this. Indeed, changing to kalman_algo = 4 eliminates the problem. Once the 6.5 version is out, would you think that kalman_algo = 3should be preferable? I tried to look up the relevant parts in Durbin and Koopman textbook as referenced in the manual, but my econometrics has become a little rusty so I am not sure. My naive intuition is that multivariate should be “better” but perhaps slower.

Both yield identical results. For big models, the univariate version is often faster. But for a model like yours, that should be negligible.