RE: NaN ERROR
James M. Kennedy
Dear Rosaria,
-------------------------------
A note taken from the LS-DYNA support site:
http://www.dynasupport.com/faq/general/have-you-any-tips-on-how-to-to-combat-instability
“First and foremost, use the latest version/revision of LS-DYNA available.”
-------------------------------
Please see if the following “general” suggestions helps:
1. 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. Nevertheless, by activating ISNAN (*CONTROL_
SOLUTION), nodes with force or moment arrays are reported (out-of-range ...) in
the message files.
*CONTROL_SOLUTION
$# soln nlq isnan lcint lcacc ncdcf
$ 0 0 0 100 0 1
0 0 1 100 0 1
*** termination due to out-of-range forces
number of nodes having out-of-range forces 8056
-------------------------------
It would appear that you have a numerical instability.
http://ftp.lstc.com/anonymous/outgoing/support/FAQ/instability.tips
https://www.dynasupport.com/howtos/material/negative-volume-in-soft-materials
-------------------------------
Some possibilities for the instability:
http://www.dynasupport.com/tutorial/contact-modeling-in-ls-dyna/how-contact-works/
Though sometimes it is convenient and effective to define a single contact that will handle any potential contact situation in a model, it is permissible to define any number of contacts in a single model. It is generally recommended that redundant contact, i.e., two or more contacts producing forces due to the same penetration, be avoided by the user as this can lead to numerical instabilities.
To enable flexibility for the user in modeling contact, LS-DYNA presents a number of contact types and a number of parameters that control various aspects of the contact treatment. In the following sections, contact types are first discussed with recommendations regarding their application. A description of the contact parameters then presented.
http://www.dynasupport.com/faq/contact/have-you-any-tips-on-how-to-to-combat-instability/
Contact. Set number of cycles between bucket sorts to zero so that the default sort interval will be used. If the relative velocity between two parts in contact is exceptionally high, it may be necessary to reduce the bucket sort interval (for instance to 5, 2, or even 1). If visible contact penetrations develop during the simulation, switch to *contact_automatic_ surface_to_surface or *contact_automatic_single_surface with SOFT set to 1. Make sure geometry takes into account thickness of shells. If shells are VERY thin, e.g., less than 1 mm, scale up or set the contact thickness to a more reasonable value.
http://www.dynasupport.com/howtos/general/not-a-number-nan-1/
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.
Nevertheless, 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.
http://www.dynasupport.com/howtos/contact/shooting-node?
"Shooting node logic" can be beneficial in the case where a slave node suddenly finds itself well behind it's master segment (whereas there was no penetration in the preceding cycle). In such a case, the logic prevents a huge contact force that might otherwise cause an instability. The penetrating node is simply placed back on the master surface.
-------------------------------
Sincerely,
James M. Kennedy
KBS2 Inc.
January 7, 2021
p.s.
2. 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.
From: ls-pr...@googlegroups.com [mailto:ls-pr...@googlegroups.com] On Behalf Of Rosaria Palumbo
Sent: Thursday, January 07, 2021 12:05 PM
To: LS-PrePost <ls-pr...@googlegroups.com>
Subject: NaN ERROR
Hi everyone, I am working on a project using a FE model of an already existing studio,
the same error always occurs:
"termination due to out-of-range forces
number of nodes has out-of-range forces 8"
I tried to reduce the TSSFAC to 0.5, I checked the ELFORM, but I can't solve. Do you have any other suggestions for me to solve the problem?
Thanks in advance.
Best regards
--
--
You received this message because you are subscribed to the LS-PrePost Google Group | http://groups.google.com/group/ls-prepost
---
You received this message because you are subscribed to the Google Groups "LS-PrePost" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ls-prepost+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ls-prepost/d151f070-faf3-4890-8ba1-f9f3d099822dn%40googlegroups.com.