It is common for simulating models in continuous time to involve numeric solution of Ordinary Differential Equations (ODE) -- they are needed more often then not if there is any feedback in the model.
The process of calcuating the best direction to move during an ODE simulation step involves creating a least-squared solution to some calculations -- to find the best solution to something of the form A*x = b where the system might possibly be overdetermined. At the MATLAB level, this would typically be handled by the calculation x = A\b (see mldivide, \ ) .
In the case where the matrix A involves large numbers multiplied together, you can encounter loss of precision on the calculations, leading to inf or nan or to answers that might be mathematically pretty wrong compared to theory.
There is a calculation that can be done to estimate how vulnerable a \ calculation will be to numeric uncertainty; that estimate is known as the "condition number". And for various reasons, it is often easier to look at the reciprical of the condition number, 1/condition_number, the Reciprical Condition Number, RCOND . When rcond is "small" then the matrix is probably effectively singular even if its determinant is not exactly zero.
How bad is the matrix in your case? Well in your case, a single bit difference in one of your inputs will result in a change by a factor of about 1/5.507637e-17 which is about 1.8E+16 . So whatever is being calculated by the \ operation is almost certainly numeric garbage.
You can get rcond problems on the very first step if your initial conditions are not set up correctly -- for example the model might call for a division by a value that was initialized by 0. But typically those immediate problems show up differently than what you have observed.
If, though, your model is unstable and some of your signals are growing large in magnitude, then you can get small rcond.
Sometimes you can get around rcond problems by either
- Using a smaller step size; or
- Configuring a different solver. In particular, stiff solvers tend to be more resistent to this than non-stiff solvers.
By sometimes you just have to fix your model because the control equations are unstable over the domain of operation.
