Energy Output to D3PLOT Files

Several options exist in LS-DYNA to output the energies, stress and strain information for shells, solids and beams depending on the choice of parameters in *DATABASE_EXTENT_BINARY keyword. These are important to understand and enable proper postprocessing of the results when using any post-processors to read in D3PLOT. It must also be noted that increased output is extremely beneficial during early design studies but may result in poor performance and the use of excessive storage if continued for the entire design cycle.

Default Output
By default the following occurs when no non-default values are chosen in *DATABASE_EXTENT_BINARY

• No strain tensor is output to D3PLOT
• Only one intergration data is output for solids. If a solid uses multiple integration point, then an average value is output
• Shell output consists of only 3 integrations points – lower, middle, upper
• Only 1 integration point data is output for beams
• No hourglass energy density is output
• No shell element timestep, mass and added mass is output
• No peak pressure or surface energy density is written for individual contact interfaces
• No nodal mass scaling information is output

Optional Output

MAXINT, Integration points for Shells
Using MAXINT, users can specify exactly how many integration point data must be output into D3PLOT. The default is 3.

CMPFLG, Local system output when using orthotropic material
Using CMPFLG, the stresses can be output in either global or local material axes.

BEAMIP, number of beam integration points (not applicable for resultant beams)
Using BEAMIP, multiple integration point along the axis of the beam or across the cross-section can be output

SHGE, Shell hourglass energy density
Using SHGE, shell hourglass energy density can be output to identify execessive hourglassing regions of the mesh.

STSSZ, Shell timestep, mass and added mass
Using STSZ, shell elements timestep, mass and added mass (if DT2MS <0) is written.

PKP_SEN, Peak presure and surface energy density
Using this option, peak pressure and surface energy density for individual contact interfaces can be output.

MSSCL, Nodal Mass Scaling Info (Works for LS-DYNA 971 R2 and higher)
Using MSSCL, node-based mass scaling values (absolute and percentage increase) can be output

Accelerometer Mass

Starting 971, LS-DYNA allows the direct input of the physical accelerometer mass in the *ELEMENT_SEATBELT_ACCELEROMETER keyword which is lumped equally to the three nodes that is used in defining the accelerometer. This eliminates the need to create additional *ELEMENT_MASS keywords to account for the physical accelerometer mass.

Nodal Time History in Local Coordinate System

In several simulations, the response of a nodal point (displacement, velocity, and acceleration) is helpful to be output in a user-defined local coordinate sytem. LS-DYNA offers several options to enable the local system output of nodal time history data and here are some examples of it. All nodal time history data is output to either NODOUT or NODOUTTF (971 and beyond) only.

1. ELEMENT_SEATBELT_ACCELEROMETER
This is one of the most commonly used feature where a nodal rigid body is first defined use three nodes such that N1 and N2 form the local X-Axis and N3 lies in the XY plane. With this information, LS-DYNA first computes the cross product of N1N2 and N1N3 to determine the local Z and this step is followed by a cross-product of local ‘X’ and local ‘Z’ to determine the local ‘Y’. The node N1 is then referenced in *DATABASE_HISTORY_NODE whose output is then output in a local coordinate sytem.

2. *DATABASE_HISTORY_NODE_LOCAL – REF = 0.0
Alternatively, one can reference a local coordinate sytem using *DEFINE_COORDINATE_NODES to create a local coordinate system and reference this id in *DATABASE_HISTORY_NODE_LOCAL keyword which will then cause the nodal output in local system. Using this option, the paramter REF plays an important role in determining how the local system data is output. To illustrate this, lets consider a simple rail crush example (as shown below) in which a node time history is output at the initial and final state in the NODOUT file.

(Click image to enlarge)

When using *DATABASE_HISTORY_NODE
When using the non-local option of the history output, LS-DYNA, outputs the nodal time history in the global system. This is the default behavior for all non-accelerometer nodes. This is shown in the following figure.

(Click image to enlarge)

When using *DATABASE_HISTORY_NODE_LOCAL with REF = 0.0
In this case, the local system is fixed in space at all times and the nodal output is the with respect to the local system which does not translate or rotate based on the local system. This is shown below.

(Click image to enlarge)

When using *DATABASE_HISTORY_NODE_LOCAL with REF = 1.0
In this case, the local system rotates based on the nodes that is used to define this (must use *DEFINE_COORDINATE_NODES) to account for any change in the orientation of the system. This is shown below.

(Click image to enlarge)

When using *DATABASE_HISTORY_NODE_LOCAL with REF = 2.0
In this case, the local system both translates and rotates based on the three nodes that are used to define the coordinate system. This update results in a relative output of the nodal time history data wrt to the local system. This is illustrated below.

(Click image to enlarge)

Notes
For a collection of nodes to be output in a local system, you can use *DATABASE_HISTORY_NODE_SET_LOCAL.

Principal Stress Calculator for Shell Elements in DYNAIN File

Recently, there was a request to ouput the principal stresses for each element at lower and upper surfaces of each shell element in DYNAIN file to use in some failure theories. I beleive this feature is a routine output in PamStamp simulations. To enable this, the attached ‘C’ code can be used that reads in a DYNAIN file (valid output from LS-DYNA) to use the stress-tensor and output the principal stresses for each element at lower and upper surfaces.

Principal Stress Calculator (Version 12)

Monitoring Incremental Elapsed Time as a Function of Simulation Time

When running explicit simulations in LS-DYNA, it is very important to understand the total CPU clock and the total Elapsed time used by the solver. This information is available at the bottom of every D3HSP file written by LS-DYNA as shown below. The total elapsed time reported in the file is the difference between the times of termination and execution. This report of Elapsed time is a static number and gives a good overview of the turnaround time for the simulation. It however, lacks the ability to provide insight at incremental intervals that is sometimes very useful to verify that it did not spend too much time during the solution. There are two ways to view incremental elapsed time and they are briefly discussed below.

1. Time Per Zone Cycle (TZC) in GLSTAT output
LS-DYNA outputs a variable called ‘Time per zone cycle’ in nanosecond as a function of simulation time into the file GLSTAT. TZC represents the elapsed clock time for each cycle at the time of output and can be plotted as a function of the simulation time in any pre-processor.

2. Incremental Elapsed Time based on D3PLOT File TimeStamp
To better understand the turnaround time, we can use the TIMESTAMP of the D3PLOT files (output at least 10 per simulation using a frequency of ENDTIM/10) and plot the incremental time difference using two successive D3PLOT’s TIMESTAMP starting from the first D3PLOT. For example, if we have 10 states of information (D3PLOT[geometry], D3PLOT01, D3PLOT02, ….., D3PLOT10), then the successive incremental elapsed time can be computed by taking the TIMESTAMP difference of D3PLOT01_TIMESTAMP, D3PLOT02_TIMESTAMP-D3PLOT01_TIMESTAMP, ….., D3PLOT10_TIMESTAMP-D3PLOT9_TIMESTAMP. This information can then be plotted against the respective actual simulation time at which the D3PLOT was written as shown below.

(Click image to enlarge)

There may be several factors that could lead to slower progression when compared with the starting point. Dropping timestep, adaptivity (where more elements are being added dynamically), varying contact-impact conditions are some of the few possible causes. Some of the causes may be unavoidable, such as adaptivity, but other causes such as dropping timestep or inappropriate contact defintions which could lead to large bucket-sizes must be reviewed and fixed to improve the overall job turnaround time. Since we run a number of design iterations over the course of the product design cycle, any improvement early on during the debugging phase can signficantly improve the overall turnaround time.

Mapping of Deformed Nodal Coordinates for SubSystem/Component Analysis

Several analyses sometimes requires the mapping of nodal positions (coordinates) from a previous run for use in current run. For single component this is a rather easy task since it just involves writing a DYNAIN file for part(s) of interest using *INTEFACE_SPRINGBACK_LSDYNA keyword which would consist of final deformed nodal coordinates and element history variables. One major drawback with DYNAIN file is its inability to write information about nodes not used by the part referred in PSID. This causes issues for nodes used in other definitions such as *CONTRAINED_EXTRA_{OPTION} , beam third node, joint nodes, etc. Consequently, storing the deformed nodal coordinates using this approach or by any other external pre-processors soon becomes an issue. There are two options to map nodal coordinates. The first one is the ability to use the full-restart capability in LS-DYNA. This approach allows the mapping not just the nodal coordinates but also all other history variables. If the interest is only on the nodal coordinates, then the keyword *INTERFACE_COMPONENT_NODE is a more elegant approach that allows to define a set of nodes (any list of nodes) and using the “z=filename” at the command line argument during the first run to store the nodal information into a interface file whose default name is “isf1″. The file “isf1″ is a binary file and consists of nodal coordinates of the node set at every output state which is specified using OPIFS in *CONTROL_OUTPUT. We won’t be using the ISF1 file directly but will only extract the nodal-coordinates for a particular state of interest (usually the last state). If only the final nodal coordinates are of interest, then using OPIFS can be set to ENDTIM. The binary interface file can then be used to extract the final nodal coordinates which can then be embedded into the second run. Using the interface force file approach, the element history variables can also be mapped using the “dynain” file (output using *INTERFACE_SPRINGBACK keyword) but without the nodal coordinates that is included in the “dynain” file.

Note: The process of mapping nodal coordinates using methods other than a full-restart fails if the subsystem of interest in the second run consists of new nodes whose information may not be available in the original run. I wrote a simple ‘C’ program that provides the conversion of the interface force file to a LS-DYNA format where the nodal coordinates are written for each time state of output specified using OPIFS. If you are interested in the program, feel free to contact me.