This thread is a reply to the following Pawel’s message:
Pawel, I have experienced all dynare++ errors
The message means that when solving higher order approximation, NaN or Inf values occurred in tensors (large multidimensional matrices). This can be caused by few operations.
The first possibility is an addition and multiplication of tensors. If the overflow happens in this case, then it is very likely that higher order derivatives of the solution explode (grow faster than factorial), which is a sign of non-stationary or non-existent solution. If the model is standard, check sizes of the shocks.
The second possibility is a higher order Sylvester equation. This solves deterministic part of the model, so the sizes of shocks do not matter. However, if your model is very persistent (i.e. the largest eigenvalue of the first derivative with respect to the states is close to 1), then higher order Sylvester equation can (in presence of roundoff) have eigenvalue equal to exact zero, which implies NaN or Inf in solution.
You can look to the journal file to know where the exception was thrown, whether it was just after Sylvester or somewhere else.
Also, a good way how to debug is to start with very small shocks and increase them. You should always try this first, if you have some problems connected to the solution.
Thanks a lot for your reply. Checking different shock sizes was the first thing we tried, as we’ve noticed before that weeeird things can happen if the variance is too big. Unfortunately that didn’t do the trick.
I’ll revisit the journal files and tell you exactly where the crash occured - you should here back from me within a day or two (this happened for a number of model files and I’d like to check them all).
As to your experiencing all dynare++ errors - I pray to god that I’ll never be in a position to say the same thing .
The problem is dynare++ problem, but not very serious. In both capital accummulation equations, you have terms ukacinvt^2 and rowacinvt^2 resp. which are diffrentiated in dynare++ as 2*(2-1)*(2-2)ukacinvt^(2-3). Since ukacinv is 0 at the steady state, then the derivative is evaluated to NaN, because of ukacinvt^(2-3). I changed the evaluator so that if some part of the product evaluates to 0, then other parts are not evaluated and the result is zero. Another fix might be rewriting the term as ukacinvtukacinvt, this makes no problems for the evaluator, because the third derivative is exactly 0.
The problem is solved in version 1.3.4, which is going to be released soon (hopefully). However it is already in svn.