LS-DYNA -- direct interface to LS-DYNA via user loading (experimental)
For more information regarding LS-DYNA, see http://www.lstc.com/products/ls-dyna
If you are interested in running MESHFREE and LS-DYNA together, please contact our Support team.
Please note that you need to have a valid license for LS-DYNA, which we cannot provide.
Currently, the following version(s) of LS-DYNA can be provided together with MESHFREE:
User loading needs to be switched on in LS-DYNA with the following lines in the keyword file (or any included file). The parameter values are ignored. All MESHFREE input is in the standard MESHFREE input files USER_common_variables and common_variables.
Geometry parts passed over to MESHFREE from LS-DYNA are assigned their part IDs as alias names. For each of these, you must assign an AliasForGeometryItems. These will be treated in the same way as any other geometry items with respect to the point cloud.
It is recommended to set MOVE-1, so that the movement from LS-DYNA is not overwritten by another MOVE statement in MESHFREE. Parts that appear in LS-DYNA but are not required for the MESHFREE part of the simulation, can be turned off with IGNORE or set to %IDENT_BlindAndEmpty%.
Additional BoundaryElements can be included as well.
Example:
If MESHFREE timesteps are smaller than LS-DYNA timesteps, one would like to interpolate the intermediate geometry positions coming from LS-DYNA at the specific intermediate MESHFREE times. MESHFREE supports such scenarios by activating the implicit run LS-DYNA flag, i.e. LSDYNA_UseImplicitRun > 0. In such situations, MESHFREE can automatically interpolate (linear interpolation) the intermediate structural positions.
1. If a user-defined MOVE$...$ statement is used, this will move the geometry in MESHFREE with the desired MOVE-flag, except when the new geometry update is received LS-DYNA (synchronization of timecycles). For more details refer to MOVE. Please note that this should be handled with care since it can lead to unphysical behavior.
Example:
It is recommended always to set the MOVE-1 since this will automatically take care of all scenarios.
LSDYNA_ForceToApplyOnBody_PC: Uses point cloud (PC) quantities to map forces onto boundary elements.
LSDYNA_ForceToApplyOnBody_BE: Directly maps quantities onto boundary elements based on intrinsic MESHFREE functionalities, such as monitor points. If LSDYNA_ForceToApplyOnBody_PC is present in the input files, it takes precedence over LSDYNA_ForceToApplyOnBody_BE.
Optional setting in USER_common_variables for LS-DYNA interface.
The default mapping uses the following equation to calculate forces on the center of gravity:
\begin{align} \mathbf{F}_\text{BE}= \left[-\left( p_\text{hyd} + p_\text{dyn} \right) \mathbf{n} + w_\text{s} \left(\mathbf{S}_\text{s}\cdot\mathbf{n} \right) + w_\text{t} \tau_\text{W} \frac{\mathbf{v}_\text{rel} }{\|\mathbf{v}_\text{rel}\|} \right] A_\text{BE}\end{align}The computed forces are then distributed across the boundary element (BE) nodes before being passed back to LS-DYNA.
The variables are
the hydrostatic and dynamic pressures \( p_\text{hyd}\) and \( p_\text{dyn}\). The precise equations to be used can be set via LSDYNA_ForceToApplyOnBody_PC. The defaults are Y%ind_p% and Y%ind_p_dyn%.
The unit normal \( \mathbf{n}\) of the boundary element.
A weight \( w_\text{s}\) to be used for the solid stresses. This can be set via LSDYNA_SolidStressWeight. The default is 1.0.
The solid stress tensor \( \mathbf{S}_\text{s}\), see StressTensorAlgorithm.
A weight \( w_\text{t}\) to be used for the turbulent wall shear stresses. This can be set via LSDYNA_TurbulentForceWeight. The default is 1.0.
The wall shear stress \( \tau_\text{W}\), Y%ind_tauW%, from the turbulence model.
The fluid velocity relative to the wall \( \mathbf{v}_\text{rel}\), see %ind_v(1)% and %ind_v_p(1)%.
The area of the BE \( A_\text{BE}\).
In particular, it might be helpful to try and smooth the dynamic pressure over a few time steps, for example:
Optional setting in USER_common_variables for LS-DYNA interface.
Optional setting in USER_common_variables for LS-DYNA interface.
In certain cases, users may want to map quantities directly from the PC index, Y%ind_Sn%, onto the boundary elements. No other PC index is used in this approach. This type of mapping can be enabled by setting the third optional argument of LSDYNA_ForceToApplyOnBody_PC to a value greater than 0.0.
When this setting is applied, the first two arguments are ignored. Instead, the following equation is implicitly mapped to the center of gravity of the boundary elements:
\begin{align} \mathbf{F}_\text{BE}= \left[ \mathrm{Y\%ind\_Sn(i)\%} A_\text{BE} \right]\end{align}where, i = 1,2,3, corresponds to the forces in the three directions. %ind_Sn(i)% denote the stress tensor times the boundary normal. In this formulation, users cannot specify weights or apply smoothing to the PC index over time. While this approach is straightforward, it lacks flexibility for advanced customization.
The syntax is follows :
Once the forces are computed per boundary element (BE), MESHFREE splits these forces across the BE nodes and sends them back to LS-DYNA. This method allows fine control over how forces are calculated and distributed, using intrinsic MESHFREE functionalities such as monitor points.
To activate coordinate transformation, set LSDYNA_Transform to 1 or 2. By default, LSDYNA_Transform is set to 0. For more information, refer to the LSDYNA_Transform documentation.
Misaligned geometries can arise due to various reasons when working with two different software environments. To address this, the user can define a unique triangle in each software, (i.e. LSDYNA and MESHFREE) which MESHFREE will interpret to synchronize the two geometries. Once the unique triangles are identified, MESHFREE ensures that the incoming geometry from LS-DYNA is transformed into the MESHFREE coordinate system for processing. At each time step, MESHFREE applies the necessary transformation to align the geometry, performs the computations to determine the corresponding forces, and then transforms these forces back to the original LS-DYNA coordinate system before returning them.
This process ensures consistency and accuracy in the interaction between the two softwares, effectively managing coordinate system discrepancies.This is achieved by associating a specific identifier with the COORDTRANS keyword in the alias section.
The elements identified by the specified keyword (such as unique triangles) are treated as undergoing a pure rigid body transformation, with no deformation. During the initial read-in process, the nodes associated with these unique triangles are tracked to construct a 4x4 transformation matrix. Subsequently, a sequence of transformation matrices is generated based on the MOVE flag specified in the MESHFREE alias configuration. At each MESHFREE time step (or sub-time step), the geometry from LS-DYNA is transformed using the calculated 4x4 transformation matrix to align with the MESHFREE coordinate system. Once the forces are computed within the MESHFREE environment, they are transformed back into the LS-DYNA coordinate system before being returned to LS-DYNA.
[1*] Estimating 3-D rigid body transformations: a comparison of four major algorithms, Machine Vision and Applications, D.W. Eggert, 1997
Optional setting in common_variables for LS-DYNA interface.
Example:Optional setting in common_variables for LS-DYNA interface.
Default:Since MESHFREE does not (fully) support 2D geometries, LS-DYNA 2D shell elements (ixs) are thickened into 3D elements with LSDYNA_ShellElement_ThicknessOffset (in the MESHFREE unit system) and then treated the same as 3D solids. The first argument denotes the default thickness for all shell elements. In case the user wants to provide a different thickness per PID, the keyword THICKNESS_ should be used in the alias section. In case this keyword is absent, the first arguement of LSDYNA_ShellElement_ThicknessOffset is chosen for thickening all shell elements. For shared nodes between PIDs, we have a non-trivial thickness at the nodepoint. The user can make a choice on which values to chose for such nodepoints. If LSDYNA_ShellElement_ThicknessOffset(2) is less than 0, the minimum is chosen (default). If LSDYNA_ShellElement_ThicknessOffset(2) is greater than 0, the maximum is chosen. The third argument is included just for fallback purposes. When LSDYNA_ShellElement_ThicknessOffset(3) is set to 1.0, the old algorithm is used which uses the default thickness as precribed in LSDYNA_ShellElement_ThicknessOffset(1). The third argument will become deprecated in a future release.
Optional setting in common_variables for LS-DYNA interface.
If this is turned on, LS-DYNA passes the geometry to MESHFREE, but no forces are returned, so LS-DYNA runs as if without user loading. Thus the simulation runs with coupling only in one direction. This is particularly used for debugging.
Optional setting in common_variables for LS-DYNA interface.
LSDYNA_ConvertQuadToTria = 0 leaves quads as such. This is not fully supported for all features of MESHFREE. LSDYNA_ConvertQuadToTria = 1 cuts each quad into 2 triangles along 1 diagonal LSDYNA_ConvertQuadToTria = 2 is a conceivable additional option to add a new point at the center of each quad and cut it into 4 triangles. This would need to be implemented in a way, in which the new points get moved along with the original quad points.
Optional setting in common_variables for LS-DYNA interface.
Boundary elements which lie on MPI-borders can have different nodepoints.
The user can set an tolerance to merge these nodepoints using this parameter.
The tolerance to merge these nodepoints is determined as follows:where MinNodes is the minimum distance between the nodepoints in the complete setup.This distance is converted into MESHFREE (SI units) unit system using the parameter LSDYNA_ScaleLength.
This check is expensive since it has to run over all the elements to check the distance between nodepoints (done only once for the complete setup). For performance gains, the user can skip this check by setting a negative value.
Default value is of LSDYNA_ScaleMinNodeDistance = 0.1
Optional setting in common_variables for LS-DYNA interface.
If the time step length in LS-DYNA is larger than the time step length in MESHFREE, then the coupled geometry could jump too far in one time step from the view point of MESHFREE. In this case, filling algorithms may not keep up, leading to unphysical holes in the fluid.
Since MESHFREE has no control over the LS-DYNA time step length, it can only the detect the potential problem and either abort the simulation or at least throw a warning.
In previous versions, only internal part IDs were passed from LS-DYNA to MESHFREE. That is, LS-DYNA parts are sorted according to their explicit part IDs in the setup and then renumbered, starting from 1. For example, a setup with part IDs 5, 12, 180 would be passed to MESHFREE as internal part IDs 1, 2, 3.
From MESHFREE version beta2021.05.0, the explicit/external part IDs are passed to MESHFREE as well and these are used by default for the alias names in MESHFREE.
For older setups, the parameter LSDYNA_UseInternalPartIDs allows to revert back to the old behavior, so that alias definitions do not need to be changed.
If the LS-DYNA_UseImplicitRun is greater than or equal to 11, then the BND_SearchTreeAdministration_RefreshTreeAfterHowManyCycles is automatically activated when the new geometry update is received from LS-DYNA. Otherwise, the cv settings are respected.
The geometry update coming from LS-DYNA can be skipped using the cv variable, LSDYNA_SkipGeometryUpdate=1. By default this is set to 0. This has higher priority in comparison to the MOVE flags. The update cannot be skipped for the first two timesteps.
This parameter allows the user to determine how frequently should MESHFREE and LS-DYNA exchange information. For instance if this value is 0.002, then MF and DYNA will exchnage information every 0.002s. For this the LS-DYNAImplicitRun value will have to set to greater than 0. It takes the same units given in LS-DYNA input files.
Since we can only control MF timesteps, the LS-DYNA_CouplingRate value should be greater than or equal to LS-DYNA timestep. For instance if the LS-DYNA timestep is 0.002 and LSDYNA_CouplingRate is 0.001, this behavior is not supported, MESHFREE has no control over LS-DYNA timesteps. The coupling rate is only active after 2 full LS-DYNA timecycles.
The setup works as follows. LS-DYNA first runs a timestep and MF checks if the CouplingRate time is achieved. Until this simulation time is reached, LS-DYNA will keep performing more timecycles. The computed flow-force from the previous MESHFREE-subcycle is used for every skip done on the MESHFREE side. Once this time is reached, MESHFREE subcycle begins. MESHFREE checks if the time provided by CouplingRate is reached, and if not it will keep performing its own timecycles.
Note : This only works if LSDYNA_UseImplicitRun is greater than 0.
In general, one could arrive to a situation where the current MF time and the LS-DYNA time are quite close but not exactly the same. To avoid very small timesteps and better synchronize the timescales, the user can set an overshoot parameter with LSDYNA_MaximumJumpinMFTimeStep (in %). MF looks for a value of (1+ LSDYNA_MaximumJumpinMFTimeStep)*dt to see if this value is within the range of end of the LS-DYNA subycle. If it finds this value, the current MESHFREE timestep is adapted to this value. Numerical experiments for testscases suggest a value of 0.2 i.e. 20% jump in the timesteps is a good approximation. Note : This only works if LSDYNA_UseImplicitRun is greater than 0.
To activate the tranformation, set LSDYNA_Transform= 1 or 2. LSDYNA_Transform= 1 : Uses an eigenvalue based decomposition to produce the transformation matrix. LSDYNA_Transform= 2 : Uses a direct map between coordinates of triangles to produce a transformation matrix.
LS-DYNA and MESHFREE both choose their time steps independently, see also LSDYNA_AbortIfTLDgreaterTMF. Whenever LS-DYNA requires the load on its parts, it calls the routine loadud, which in turn calls MESHFREE.
During the first call, the geometry is passed over to MESHFREE and translated to the internal geometry format. For 3D solid parts (ixh), the surface is extracted and saved as quads or triangles (see also LSDYNA_ConvertQuadToTria). LS-DYNA 2D shell elements (ixs) are thickened into 3D elements with LSDYNA_ShellElement_ThicknessOffset and then treated the same as solids. Beam elements (ixb) are ignored by the interface.
In all calls, if the LS-DYNA simulation has reached a later time than the MESHFREE simulation, nodal positions of the geometry are updated in MESHFREE with the information provided by LS-DYNA. With this new information, MESHFREE computes time steps until the LS-DYNA time has been exceeded again. The pressure and shear stresses are saved per boundary element, projected onto the geometry nodes in LS-DYNA and returned.
In coupled simulations, it may happen that the structural deformations are quite small compared to the local MESHFREE smoothing length. The user might wish to increase the timestep size for the structural computations in comparison to MESHFREE timesteps. Another practical scenario could be that LS-DYNA runs use implicit time-stepping schemes allowing much bigger timesteps (unconditionally stable).
MESHFREE supports such scenarios by activating the implicit run LS-DYNA flag, i.e. LSDYNA_UseImplicitRun greater than 0. In such situations, MESHFREE can automatically interpolate (linear interpolation) the intermediate structural positions. For more information, refer to Geometry-substepping.
Shell parts containing T-junctions cannot be consistently oriented and thus the thickened part in MESHFREE will have defects.
Due to limitations in the STL cleanup (see BE_CleanUp_STL),
the combination of LS-DYNA coupling and loading STL geometry
does not work reliably yet.
For the same reason, exportGeometry{ cannot be used during a coupled simulation.
We recommend exporting STL geometry as OBJ in a separate standalone MESHFREE step
and using this in the coupled simulation.
See exportGeometry{ and CONTROL_StopAfterReadingGeometry).
There is currently only a single parameter for the thickness of LS-DYNA shell elements in MESHFREE (LSDYNA_ShellElement_ThicknessOffset). Thus, if there are shell elements with different thicknesses in LS-DYNA, these cannot correctly be recreated in the MESHFREE part of the simulation.
Quadrilateral elements are not yet fully supported in MESHFREE. Thus quad faces from LS-DYNA are, by default, split into two triangles along one diagonal (see LSDYNA_ConvertQuadToTria). For non-planar quad faces, this is a non-unique linearization. Especially if two opposite non-planar quads are split along the different diagonals, this can lead to intersections in the MESHFREE geometry that were not present in the LS-DYNA geometry. A new option is planned for later, where quads are split into four triangles with the centers of gravity as auxiliary points. Until then, we recommend using geometry elements based on triangles rather than quads, particularly for shell elements.
If the LS-DYNA time step length exceeds the MESHFREE time step length, MESHFREE filling routines may not always be able to keep up with the geometry movements, leading to unphysical holes in the fluid. This is unlikely in industrial applications with elastic deformations modeled in LS-DYNA, but may happen for example in rigid body movements. In these cases, it is up to the user to set an appropriate time step limit in LS-DYNA. See also LSDYNA_AbortIfTLDgreaterTMF.
In most cases, the number of desired MPI processes for the two parts of the simulation would be highly different,
but it is technically not possible to run them on different numbers of MPI processes.
Thus a number of MPI processes needs to be chosen to balance the different requirements.
Removing this limitation would require significant changes to the interface and is not planned for the short term.
Currently with the use of DEBUG_PARAMETER() in the cv.dat file, the simulation startup is quite slow. The exact reason why this happens is unclear. It is specific to MESHFREE and happens while reading the DEBUG variables.
beta2024.02.0: Add coordinate transformation feature to move unsynchronized LS-DYNA geometries according to the MOVE-flags in MESHFREE (experimental)
beta2023.09.0: Add ForceToApplyOnBody for mapping forces on BE (experimental)
beta2023.09.0: Add cv variables, LSDYNA_MaximumJumpinMFTimeStep, LSDYNA_SkipGeometryUpdate, LSDYNA_CouplingRate, LSDYNA_UseImplicitRun (experimental)
beta2022.11.3: Add geometry substepping between longer LS-DYNA timesteps (experimental).
beta2022.11.3: Add support for ERFHDF5 format with LS-DYNA.
beta2022.11.3: Add support for LS-DYNA version R12.1.
beta2021.09.0: Add SAMG as dynamic library.
beta2021.09.0: Add support for LS-DYNA version R12.0.
beta2021.07.1: Fix shell thickening for shared memory case.
beta2021.05.1: Change FSI coupling keywords (Ucv) from LSDYNA_ to general names, e.g. PressureToApplyOnBody.
beta2021.05.1: Fix thickening of triangle shell elements.
beta2021.05.0: Add support for shared memory treatment of geometry on MESHFREE side (excluding the interface variables).
beta2021.05.0: Use explicit/external part IDs from LS-DYNA setups if provided by the interface. (Revert to internal part IDs with LSDYNA_UseInternalPartIDs.)
beta2021.05.0: Ensure that shell parts are consistently oriented for thickening. Note: This is not fully possible if they contain T-junctions.
beta2021.03.0: Updated compilation to use library for MESHFREE part. This adds support for Encryption, ERFHDF5, EULERIMPL, SAMG (see LINEQN_solver, LINEQN_solver_ScalarSystems).
beta2020.12.1: Fix crash during initial shell thickening for large geometries.
beta2020.10.0: Fix initial velocity for shells at MPI borders.
beta2020.08.1: Add support for TShell elements.