Dynare++: NaN or Inf asserted in TensorContainer::insert

[OndraKamenik]

This thread is a reply to the following Pawel's message:

However, in the meantime, I've been experiencing other sorts of unexpected dynare++ behaviour, which, I thought, you might be able to help with.

The most serious of these problems is that I have several models that run smoothly when expanded to second order, but crash when I try to do a third order expansion. I was wondering if you've experienced that sort of behaviour before (the error message I'm sometimes getting is: Caugth TL exception: At ./t_container.hweb:223:NaN or Inf asserted in TensorContainer::insert).

I'd be happy to send you the files that cause trouble if you'd like and if that's ok (unfortunately, due to security restrictions in place on all PC's at work I'm unable to upload any files to the forum).

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.

Perhaps this helps.

kind rgrds

Ondra K.

[pawel]

Ondra,

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 .

Thanks a lot and will be back soon,
Pawel

[OndraKamenik]

Pawel,

you can always send me the model file via email. I am ondra.kamenik aaattt volny.cz. I can look at it.

Ondra K.

[OndraKamenik]

Pawel and others,

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 ukacinvt*ukacinvt, 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.

Ondra K.