Example of *DEFINE_CURVE_FUNCTION

Starting in LS-DYNA version 970 and later, we can now use expressions instead of digitized values to define an XY curve. Optionally, the expressions can refer to other curves which could be defined using either digitized points or using expressions themselves. Here is an example of its usage:

Polynomial Expressions
You can define a generic polynomial of any order upto a maximum of 30 using the general expression label “POLY” (Please note that the current ls-dyna manual shows this as POLYL which is incorrect) and its argument list is given by:

POLY(abscissa, abscissa0, coeff0, coeff1, coeff2,..., coeff30)
or
POLY(x, x0, a1, a2,..., a30)

The built-in expression used is:

P(abscissa) =
coeff0+coeff1*(abscissa-abscissa0)+coeff2*(abscissa-abscissa0)*power(2)+...
or
P(x) = a0+a1(x-x0)+a2*(x-x0)*power(2)+...+an*(x-x0)*power(n)

Below is an example that prescribes a displacement to a node using some arbitrary coefficients. You can monitor the displacement history of node #1 which is prescribed.

Modeling Friction in Contact

In contact-impact interactions, friction plays an important role in accurately capturing the sliding behavior. In LS-DYNA, the coulomb treatment of friction is used where a static and a dynamic friction can be defined which are used to determine the shear force while resisting penetration. By default, all contact definitions model a friction-less sliding which is a good start for initial models. The first step in activating friction in contacts is to use a non-zero static friction parameter, FS, in the *CONTACT_{OPTION} keyword. Optionally, one can define a dynamic friction, FD, which will only be used for a non-zero decay coefficient, DC. It is common to see a positive sliding energy when using non-zero friction parameters. It must be noted that non-zero friction parameters do not apply for FORCE_TRANSDUCER and TIED contacts which remain tied for the duration of the simulation. When TIED contacts are defined with failure parameters and are defined to be converted into penalty-type contacts after failure, then the non-zero friction parameters will be used to determine the shear contact forces. Figure 1 illustrates the nature of the penetration removal process when a node is detected as penetrating the closest master segment. When a penetrating node is first detected, by checking the sign of the projected normal distance to the closest master segment, a penalty force is first calculated based on the stiffness and the absolute penetration value. This force is then resolved in a local coordinate system embedded at the master element (contact point) to determine the normal and shear components. The sliding resistance is then computed using the friction parameters of the master segment and the normal force component as shown.

(Click image to enlarge)

Transitioning from Static to Dynamic Friction
By default, LS-DYNA considers only a static value (FS). In reality, the friction is dependent on relative velocity with which the parts are sliding and this friction is usually less than the static friction value. To model this behavior, two parameters, FD and DC. The transition from static to dynamic friction is modeled using an exponentially decaying function, , that is based on the instantaneous relative velocity of the sliding node and the corresponding master segment. The transition from static to dynamic friction is as shown below.

(Click image to enlarge)

Part Based Friction
By default, the non-zero friction parameters defined in the *CONTACT_{OPTION} keyword are used for all segments. This may be acceptable when all parts involved are composed of similar material, but it may be inaccurate when dissimilar materials are defined to interact using SINGLE_SURFACE contact definitions. In such cases, LS-DYNA provides an option to define friction parameters at the component level using the *PART_CONTACT keyword. To let LS-DYNA use the values defined at the component level, FS must be set to -1. When FS=-1, a quick look-up is done prior to computing the shear force magnitude to determine the frictional parameters using the master segment’s part definition.

Part Pair Based Friction
While the part based friction parameter definition is an improvement compared to the global values, which is applied to all parts(segments), the concept of choosing the master segment friction values can still over/under predict the sliding resistance. To illustrate this, consider two dissimilar materials such as foam (F1) and steel (S1) that interact purely by contact treatment. Using component based definitions, we can input frictional values of 0.6 and 0.2 (using FS) for the respective materials using the *PART_CONTACT keyword. Now lets consider the case of S1 sliding on F1 which will cause LS-DYNA to look up the friction parameters of the master segment (F1 in this case) to give a value of 0.6. Next consider the case of F1 sliding on S1 which will result in a friction value of 0.2. As you can see, we come up with two different frictional parameters for the same PAIR of materials interacting with each other. This is easily overcome by using the *DEFINE_FRICTION keyword available in LS-DYNA versions 970 and later. The *DEFINE_FRICTION keyword allows us to define an unlimited number of interacting part pairs and their corresponding friction parameters. When using this option, the parameter FS must to set to -2, and the parameters defined in *DEFINE_FRICTION will override all values defined using the *PART_CONTACT keyword. Now using the earlier example, lets pick a pair of F1/S1 and define an average friction value of 0.4. With this definition, when either F1 slides on S1 or S1 slides on F1, instead of looking up the part based contact parameters, LS-DYNA looks up the pair definition and uses the average value of 0.4 which provides more accurate resistance.

Graphical viewing of frictional energy
The frictional sliding energy is dissipative and can be optionally written out to binary file using the option FRCENG in *CONTROL_CONTACT which requires the parameters SPR and MPR to be set to unity along with using the command line argument “s=interface_file”. Once these options are used, LS-DYNA outputs a binary file named “interface_file” which can be viewed using LS-PrePost. Among other variables, the frictional energy is output as the component “surface energy density” which can be fringed on the contact surface.

Contact Thickness in Single Surface Contact

Single surface contacts have dramatically eased the way we currently model the contact-impact treatment for complicated simulation models in LS-DYNA. One of the important considerations is the final thickness used by contact algorithms especially for shell elements. By default, LS-DYNA considers the minimum of thickness specified in the *SECTION_SHELL or from *ELEMENT_SHELL_THICKNESS and the 40% of the smallest shell element edge length. The default logic is based on historical reasons where large penalty contact forces where applied for non-physical shell element thickness specified in SECTION_SHELL keyword to account for mass/stiffness of the component. The default logic greatly helps in overcoming instability related to improper shell thickness definitions. However, the dependence on mesh edge length could lead to different shell contact thicknesses for a part with varying mesh densities as shown in figure below. The minimum of both thicknesses (SECTION_SHELL, 0.4*shell_edge_length) could lead to a smaller thickness that could allow increased clerances. For a part with mesh densities, it is possible to have a varying contact thickness across part surface which could lead to oscillatory contact response especially for sliding dominated contact interaction.

(Click image to enlarge)

To override this, LS-DYNA allows the parameter SSTHK (Single Surface THicKness) in *CONTROL_CONTACT, which when set to 1 forces LS-DYNA to take the thickness value specified in the *SECTION_SHELL keyword or from *ELEMENT_SHELL_THICKNESS. ELEMENT_SHELL_THICKNESS values will override values used in *SECTION_SHELL keyword when SSTHK = 1. If OPTT parameter is non-zero in *PART_CONTACT, then OPTT will overeride values from both ELEMENT_SHELL_THICKNESS and SECTION_SHELL keywords. If care is not taken, SSTHK=1 could result in increased initial penetration and therefore requires a clean model when invoking this option. SSTHK=1 is usually accompanied by using IGNORE=1 to skip the geometry update step (to remove initial penetration) performed during initialization to preserve the original geometry.

(Click image to enlarge)

Note 1: SSTHK only applies for single surface contacts definitions.
Note 2: When SSTHK=1, the thickness specified in section shell keyword is scaled by SFST and SFMT to obtain the final contat thickness.

Identifying Problem Areas for Poorly Converging Implicit Solutions

For non or poorly converging implicit solutions, the parameter D3ITCTL parameter in *CONTROL_IMPLICIT_SOLUTION may come handy to isolate regions of interest. When D3ITCTL is non-zero, LS-DYNA outputs the model information at each Iterative step into a binary file named D3ITER which is in the same format as D3PLOT. The number of steps for which the iterative plots are to be stored is limited by the value of D3ITCTL. To save disk space, it is recommended to set D3ITCTL = 1, which indicates LS-DYNA to dump the iterative plots for every step with a maximum number of just 1 step stored into the database. With this definition, if LS-DYNA terminates abruptly without finding a converged solution, we can view the D3ITER files in LS-PREPOST to identify the problem areas. It may be necessary to scale the nodal displacements in order to visualize the movements of the nodes.

Note: There may be significant I/O issues when setting a non-zero D3ITCTL and is recommended only for debugging or when running implicit simulations with immature models.

(Click image to enlarge)

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.

Number of Shell History Variables in *INTERFACE_SPRINGBACK

*INTERFACE_SPRINGBACK provides an easy way to store a part’s state at the end of a simulation for later use. The part’s state consists of element history variables such as stress and strain tensor (in the form of *INITIAL_STRESS/*INITIAL_STRAIN) and also nodal values such as its final coordinates (*NODE). Optionally, when using the THICKNESS option, it allows to output the nodal thickness (in the form of *ELEMENT_SHELL_THICKNESS). One additional parameter that determines the number of shell history variables to be output is the NSHV. When NSHV=0, LS-DYNA outputs the stress tensor, strain tensor and effective plastic-strain at each integration point. This may be sufficient for most reuse but in some instances, such as mapping accumulated plastic strain, the default value of NSHV may be insufficient. In such cases, it is always recommended to set NSHV to a very large number to let LS-DYNA output ALL associated shell history variables depending on the constitutive model used by the shell.