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 seethe 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.