The Rank Condition Again

Hi there,
I searched the forum regarding this and I saw that the best advice was to :
-double check parameters - then chek timing -then check model - then change model…

question is: if I checked all these and I am about to change model (unfortunately !) because I am getting only 9 eigenvectors outside unity for 13 forward variables… in which way do I want to change it ? I mean when you want to fix an error you want to know first what is correct …what are the factors that would contribute to stability and what are those that contribute to instability ? is it the number of forward looking variables ?

Thank you all .

j.

Hi,
your problem could be everywhere and unfortunately, the potential issues are usually interrelated. 4 forward variables too many sounds like a fundamental issue either with your model or the way you implemented it. Try posting your model file and explaining what you are doing. Probably someone spots the mistake and is able to help you.

Thank you for your answer. my model is quite complicated (albeit small) so if you don’t mind let me ask a couple of questions first:

  • How good Dynare is in solving for steady state of say 20 non-linear equations. I know fmincon is not good for that, and you have to give really good initial values. Is the function used by Dynare similar in that sense ? I see some people log-linearizing their model before putting it into fortran, I assume this is not needed right but done for simplicity of steady state if at all ? ( sorry very much a beginner )

  • The way I am doing things is that I am feeding my steady state values… In fact, even when i simplify my model considerably (down to 6 equations) it never manages to compute the steady state and it gives me errors as shown below. I assume this means it is just not converging right ?

Warning: Divide by zero.

In benchmark_static at 83
In dynare_solve at 70
In steady_ at 124
In steady at 52
In benchmark at 176
In dynare at 132
Warning: Divide by zero.
In benchmark_static at 83
In dynare_solve at 70
In steady_ at 124
In steady at 52
In benchmark at 176
In dynare at 132
Warning: Divide by zero.
In benchmark_static at 84
In dynare_solve at 70
In steady_ at 124
In steady at 52
In benchmark at 176
In dynare at 132
Warning: Divide by zero.
In benchmark_static at 84
In dynare_solve at 70
In steady_ at 124
In steady at 52
In benchmark at 176
In dynare at 132

  • Dynare is as good or bad as the optimization routine and the starting values you use. The problem with nonlinear equations is that there are often many possible solutions, while linear ones should have only one unique solution. Have you tried all of the available options for computing the steady state (see manual)? In particular, have you tried

steady(solve_algo=3).

  • When the algorithm is not converging, Dynare usually tells you so. So the error message rather tells you that either your starting values are wrong in the sense that you divide by a variable that is initialized as 0 or that the model is wrong.

I would recommend posting the mod-file of the simplified version.

Thanks again.
Actually I am using the function “steady” and I am not giving any starting values. The person who gave me a first crash course in Dynare told me I don’t need one.

What I will do, is I will take a second crack at it, and if it still doesn’t work, I will post a simplified version of it.

Merci enormement.

OK it seems that the timing in Dynare is such that:

  • a state variable at time t is written t-1
  • a state variable at t+1 is written t

( i think that the document “practicing dynare” has a mistake in model 1 ftp://zia.stanford.edu/pub/sargent/webd … _tom16.pdf
where they actually call k(-1) for k_t+1 !! . otherwise other examples I have seen are consistently as stated above).

So I have made these changes and now it is working, but can you please confirm whether the statemnent above is correct ?

Hi,
your above statement is correct and “Practicing Dynare” has a mistake.