Bug in "check;" or "resolve.m" (64-bit)?

Hello,

I have a large scale New Keynesian model where I computed the steady state by hand. While trying to debug the model and its parametrization I encountered three problems (Dynare 4.1.1, Matlab2009b 64bit,Win XP Professional):
[ol]
*]When using

as the last command in my model-file after

[code]model;

end;

shocks;

end;
steady;[/code]

it tells me

[quote]There are 41 eigenvalue(s) larger than 1 in modulus
for 42 forward-looking variable(s)

The rank conditions ISN’T verified![/quote]

When putting

after the check command, I get

[quote]There are 40 eigenvalue(s) larger than 1 in modulus
for 42 forward-looking variable(s)

The rank conditions ISN’T verified![/quote]

and when putting the second order approximation

I get;

[quote]There are 42 eigenvalue(s) larger than 1 in modulus
for 42 forward-looking variable(s)

The rank condition is verified.[/quote]

How can it be that the output of the check command depends on the following commands invoked? Is there maybe a bug in the .mex64-files invoked by “check;” or “resolve.m”?/*:m]
*] For a somewhat different parametrization

check;
tells me that

[quote]There are 43 eigenvalue(s) larger than 1 in modulus
for 42 forward-looking variable(s)

The rank conditions ISN’T verified![/quote]

However,

nevertheless computes the model solution and gives impulse responses. However, they look completely different than the ones on Matlab 2009a 32 bit machine. Moreover, the check command on the latter Matlab version says

[quote]There are 42 eigenvalue(s) larger than 1 in modulus
for 42 forward-looking variable(s)

The rank conditions is verified![/quote]

which would be consistent with the Blanchard-Kahn conditions being satisfied./*:m]
*]While the latter parametrization produces prima facie sensible output on the 64bit machine with

the standard second order approximation

fails as all impulse responses in oo_.irfs are NaN. Moreover,

fails with

While there is most probably still a problem with the model parametrization, troubleshooting is complicated by the contradicting outputs. Which ones should I trust?/*:m][/ol]

Hi,

Indeed the output of “check” should not be affected by the commands following it, so this is probably a bug in Dynare or a pathological case. But it is normal that this output changes when you change the parametrization.

Please post your MOD file so that we can see where the problem is.

Best

Hi,

There are at least two issues:
[ul]
] The first issue is auxiliary variables (see dynare.org/DynareWiki/AuxiliaryVariables) which are created for variables with leads or lags greater than 2. The point is that aux vars (and their associated auxiliary equations) are created only when there is a stoch_simul. So, in the output of the preprocessor, you can see that there are 107 equations whithout stoch_simul and 111 with stoch_simul. This explains the first discrepancy that you pointed./:m]
] The second discrepancy seems related to the numerical instability of the steady state. My understanding is that your steady state file doesn’t always return exactly the same value (when you swith from order=1 to order=2 for example). You can experiment with that by using the save_params_and_steady_state and load_params_and_steady_state (see the reference manual), which will help you to use exactly the same steady state across specifications. If you use exactly the same steady state for order=1 and order=2 (using the previous commands), then you get the same output concerning eigenvalues./:m][/ul]

There may be other problems related to the numerical instability of your model, but it didn’t investigate them.

Best

Hi Sébastien,

thank you for your help. The first part of your answer mostly clarifies the issue. Unfortunately, the second issue still puzzles me.

  1. The steady state is numerically stable. Although I use fsolve in the steady state-file, I always get the same steady state values for all variables. In contrast to csminwel, fsolve works deterministically, so there is no random element, if I keep parameters constant. I explicitely checked for the stability of the steady state estimates by saving oo_.steady_state from order=1 and order=2 and comparing it in Matlab with the isequal command. They are identical. I did the same with Matlab 2009a 64bit and 2009b 64 bit and the steady states are also identical. The same applies to the eigenvalues saved in oo_.dr1.eigval. Hence, the steady state should not be the issue.

  2. The problem with the different IRs is not due to 32-bit vs. 64-bit systems. Rather, there is a difference in the IRs between Matlab 2009a and 2009b, but I do not know why this is the case.

  3. I could trace back the third issue in my initial post (second order IRs do not work while first order IRs do) to the NaNi in the eigenvalues as described in a related post [NaN in the list of eigenvalues) .