Not a Number (NaN)

Velocities reported as NaN (Not a Number) indicate that the analysis has gone unstable for any number of reasons. Tracking the root cause of NaNs reported late in the calculation can be difficult. Nethertheless, by activating ISNAN (*CONTROL_SOLUTION), nodes with force or moment arrays are reported (out-of-range ...) in the message files.
It is always recommended that state data be dumped to the d3plot database more frequently leading up to the instability. This can be done by way of restarting from a D3DUMP or RUNRSF file and changing the output interval in a small restart deck via
*CONTROL_BINARY_D3PLOT, or by specifying the output interval via a curve. Having frequent plot states allows the user to see
the evolution of the model instability thus narrowing down its origin.
Examples of root causes are a breakdown of contact, or severely distorting elements arising from nonphysical loads, badly conceived material input, or severe hourglassing. Nonphysical damping parameters can also cause an instability to develop as can a timestep that too large. For parts where large physical deformations are expected, it's best to stick with the default element formulations as those tend to be the most robust.

If you're using deformable spotwelds (beam type 9) together with *CONTACT_SPOTWELD_TORSION, it's recommended that you invoke *DAMPING_PART_STIFFNESS for the shell parts (use at damping factor of 0.1).

Automatic contact can break down if VERY thin shells are involved. In those instances, increase the contact thickness of the thin shells (see *PART_CONTACT).

If you suspect the composite material is creating problems, try substituting mat 1 (*MAT_ELASTIC) for mat 54/55 as an experiment to see if the instability still occurs.