Question on lik_init = 2

Hi everyone,

I’m having an issue with the smoothing of unobserved variables in nonstationary models when using the option lik_init = 2.

I think that the variables are not correctly smoothed for the first period in the sample: the smoothed values do not seem updated by the algorithm and stay at zero whatever the subsequent values. I don’t have the same issue when using the diffuse_filter option instead, which updates first-period estimates of unobserved variables. I’m working on Dynare 4.4.3.

I include an example file below with a very simple model and simulated data. You have to run the matlab file MTL.

Any clue on what happens whould be much appreciated.

AM
Test.zip (2.18 KB)

Hi,
this seems to be no bug. lik_init=2 follows Harvey and Phillips(1979) in setting the initial forecast variance of the error to a diagonal matrix with 10 on the diagonal. In contrast, the diffuse_filter’s diffuse initialization (lik_init=3) uses a non-diagonal matrix for your model. This difference matters here, because with a diagonal matrix, the first observation for Y does not contain any info for updating the initial values. Only in the second iteration will the forecast variance of the error be non-diagonal and updating takes place. Is there a particular reason you cannot use the diffuse_filter?

1 Like

Thanks for the fast reply. I was not aware that the first observation carries no information on the state in that case and I’m not sure I undertsand why.

I am not using the diffuse filter because I got weird results with it in multivariate estimation, which was not the case with lik_init = 2. I will try to cook up a simple example of this tomorrow.

Thanks again JP.

AM

You can check the problem by setting a breakpoint in missing_DiffuseKalmanSmootherH1_Z.m. You will see that in

PZI = P(:,:,t)*ZZ'*iF(di,di,t); atilde(:,t) = a(:,t) + PZI*v(di,t);
At time 1, the forecast error v is 10. The updating matrix PZI = 1 0 0 0 0 0
i. e. only the first variable in atilde is updated. But you are interested in the second entry, it seems. With diffuse filter in contrast

PZI = 1 1 0 1 0 0

Thanks.

If I understand correctly, lik_init = 2 results in not updating the estimate of the state vector at the first period.

What I don’t understand is why it does not update at the first place. If I call y(1) the first observation, s(1) the hidden state, and I assume a Gaussian distribution for [s(1), y(1)], my guess is that observing y(1) would help forecasting s(1) through the standard expressions of conditional means in Gaussian vectors. Why isn’t it the case here?

Regarding the question of why not using the diffuse_filter option, I include an example of the issue I have. Basically, in a threevariate setting, using diffuse_filter results in unplausible smoothed estimates. When I turn instead to lik_init = 2, I get reasonable results. Any clue on what happens with the diffuse option is welcome.
Test2.zip (3.57 KB)

You are right. There is something very weird. We will investigate the issue.

Thanks.

I think your observation equation is wrong. v1, v2, and v3 have steady state 0, but your data says something different. I simply put

v1=v1-v1(1); v2=v2-v2(1); v3=v3-v3(1);
at the end of your mod-file and things looked quite reasonable in that case. The problem seems to be less the filter than the model specification which non of the filters is able to handle. Even with lik_init=2, there must be huge shocks to push the model on the data trajectory.

Thanks Johannes.

It’s true that the model is nonstationary, as the trend is I(2). Since the model is linear, I thought this would not be an issue as there is no need to perform an approximation around a steady state.

Regarding the size of the shocks, I don’t think they are particularly relevant as I keep many standard deviations arbitrarily fixed at very low values in the code. Freeing those parameters in estimation would likely help generate smaller shocks.

Also, I noticed that the smoother results with the diffuse option depend on the ordering of the variables in that it gets correctly the trend of the first variable, and not those of the remaining ones. For instance, if you switch v1 and v2 in the data file, the smoother will keep generate a nice trend for v1 even though this is no longer the same variable. I don’t understand this pattern as my prior would be that the ordering of the variables should not matter for the results.

Furthermore, I am pretty sure that this class of models can be estimated by likelihood-based methods using Kalman filtering (see eg. stat.yale.edu/~lc436/papers/ … rs1990.pdf). Do you think that Dynare is able to correctly perform such an estimation in levels and if yes, under which options?

Finally, I didn’t get where you put the
v1=v1-v1(1);
v2=v2-v2(1);
v3=v3-v3(1);
command. You mention the mod file, but it generates an error when I try it…

Hi,
I have traced the source of the problems to the initialization of the diffuse filter not preserving the recursive structure of the problem. See github.com/DynareTeam/dynare/issues/1312. This may either be due to a bug or numerical issues. We are still investigating the problem.
And please forget what I said above. I meant to write that you can add the code I posted at the end of the data file. But obviously that is superseded by the problem I identified.

Hi Johannes,

Many thanks for your help.

I will wait for the problem to be solved before carrying on my estimation.

Hi,

I come back with a comment about option lik_init = 2 in Dynare.

In the current implementation, this option initializes the variance-covariance matrix of the vector of variables with a diagonal matrix with a large number on the diagonal. This violates the structure of the model along two dimensions:

  • if there are both stationary and nonstationary variables in the model, it is possible to compute the variance of the stationary components without setting it to an arbitrary number,
  • if the variables are correlated in the model, the zero nondiagonal entries ignore these patterns, potentially preventing the updating of unobserved variables via the Kalman smoother.

I give an example in the attached file. Run as it is, the mod file generates results plotted in Trend1.pdf and Cycle1.pdf. It can be seen from Trend1.pdf that the starting point of the trend is not updated by the smoother and stays at zero. Likewise, the smoothed cycle starts at zero.

The model being quite simple, I have modified the Dynare files dsge_likelihood.m (lines 361-375) and DsgeSmoother.m (125-139) manually to initialize correctly the variance matrix for the filter and smoother. Essentially, this requires:

  • initializing the variance matrix of nonstationary states as currently done in Dynare for the full vector,
  • initializing the variance matrix of stationary states using the theoretical moment,
  • and initializing the variance matrix of the controls and its covariance with the state using the theoretical moments.
    Run with these modified files, the mod file generates figures Trend2.pdf and Cycle2.pdf. It can be seen from these plots that the starting points of both the trend and the cycle are now updated by the smoother, and that this has some (small here, but perhaps larger in other settings) effects on the full path of the smoothed variables.

I think Dynare would benefit from an automatic implementation of this approach, which would make option lik_init = 2 more consistent with available theory.
TestLikInit2.zip (24.8 KB)

Hi,
in theory you are correct. In practice, this is not easy to do and we are working on it. The problem is to separate the stationary variables in the state-space system from the non-stationary one in a generic way. It is particularly in that step that the bug in the diffuse_filter implementation occurs. What the diffuse filter does is initializing the stationary variables in the normal way and the non-stationary one with “infinite variance”.
In your example, you know the first variable is the non-stationary one. But in general you do not know this.

Hi,

Thanks for the answer. I was wondering if it was possible to do this in an automatic way but I understand it’s a rather difficult problem.

The underlying bug is hopefully fixed in tomorrow’s unstable version. Could you please try whether it works in your case?

Hi Johannes,

Everything seems to run correctly on my computer now using the unstable version.

Thanks!

Alban