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

[jpfeifer]

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):

1. When using
   

   Code: Select all

   check;

   
   as the last command in my model-file after
   
   

   Code: Select all

   model;
...
end;

shocks;
...
end;
steady;

   
   
   it tells me
   
   

   There are 41 eigenvalue(s) larger than 1 in modulus
   for 42 forward-looking variable(s)
   
   The rank conditions ISN'T verified!

   
   
   When putting
   

   Code: Select all

   stoch_simul(irf=20,nomoments,nocorr,order=1,nofunctions,noprint) y_H;

   
   after the check command, I get
   
   

   There are 40 eigenvalue(s) larger than 1 in modulus
   for 42 forward-looking variable(s)
   
   The rank conditions ISN'T verified!

   
   
   and when putting the second order approximation
   
   

   Code: Select all

   stoch_simul(irf=20,nomoments,nocorr,order=2,nofunctions,noprint) y_H;

   
   
   I get;
   
   

   There are 42 eigenvalue(s) larger than 1 in modulus
   for 42 forward-looking variable(s)
   
   The rank condition is verified.

   
   
   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"?
2. For a somewhat different parametrization
   

   Code: Select all

   check;


   
   tells me that
   
   

   There are 43 eigenvalue(s) larger than 1 in modulus
   for 42 forward-looking variable(s)
   
   The rank conditions ISN'T verified!

   
   However,
   

   Code: Select all

   stoch_simul(irf=20,nomoments,nocorr,order=1,nofunctions,noprint) y_H;

   
   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
   

   There are 42 eigenvalue(s) larger than 1 in modulus
   for 42 forward-looking variable(s)
   
   The rank conditions is verified!

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

   Code: Select all

   stoch_simul(irf=20,nomoments,nocorr,order=1,nofunctions,noprint) y_H;

   
   the standard second order approximation
   

   Code: Select all

   stoch_simul(irf=20,nomoments,nocorr,order=2,nofunctions,noprint) y_H;

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

   Code: Select all

   stoch_simul(irf=20,nomoments,nocorr,order=1,aim_solver,nofunctions,noprint) y_H;

   
   fails with
   

   Error in AIM: aimcode=3 : Aim: too many big roots.

   
   While there is most probably still a problem with the model parametrization, troubleshooting is complicated by the contradicting outputs. Which ones should I trust?

[SébastienVillemot]

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

[SébastienVillemot]

Hi,

There are at least two issues:

• The first issue is auxiliary variables (see http://www.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.
• 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.

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

Best

[jpfeifer]

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 http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=1814 .