4. Material models and constitutive laws

Material definitions are the most fragile part of any cross-solver CAE transfer. Geometry can be re-meshed, loads can be re-applied, and boundary conditions can be re-selected, but a constitutive law carries physical meaning that is encoded differently in every solver. When a model moves from Abaqus to ANSYS, from LS-DYNA to Radioss, or from Nastran to a custom in-house code, the material card is where silent errors accumulate. This chapter explains how to map material models between solvers, how to judge whether two implementations are truly equivalent, and how to verify the mapping before trusting any result.

Why Material Mapping Is Not a Simple Rename

A constitutive law defines the relationship between stress, strain, and internal state variables. Solvers implement this relationship through different formulations, integration schemes, and parameter conventions. Three sources of divergence dominate practice:

• Formulation differences. A "plasticity" model in one solver may use von Mises yield with isotropic hardening, while another defaults to a combined isotropic-kinematic formulation. The same input numbers then produce different stress-strain paths under cyclic loading.
• Parameter conventions. Yield stress may be given as true stress or engineering stress; hardening may be expressed as a tangent modulus, a plastic strain table, or a hardening exponent. A value of 600 MPa means different things depending on which convention the card expects.
• Integration and regularization. Explicit solvers use different hourglass control, strain-rate filtering, and element formulation defaults. These are not material parameters, but they change the effective response of the material model.

The practical consequence is that a material card cannot be copied across solvers. It must be decomposed into physical intent and solver-specific encoding, then reassembled.

Decomposing a Material Definition into Physical Intent

Before touching any solver input, extract the physical intent from the source model. For a typical elastoplastic metal, this means answering four questions:

1. What is the elastic behavior? Isotropic linear elasticity requires Young's modulus and Poisson's ratio. If the source uses orthotropic elasticity, record all nine independent constants and the material coordinate system.
2. What is the yield criterion? von Mises, Hill, Drucker-Prager, or a user-defined surface. Record the exact form and any associated parameters.
3. What is the hardening law? Isotropic, kinematic, combined, or tabulated. Record the hardening curve as true stress versus true plastic strain, not as a modulus.
4. Are there rate, temperature, or damage dependencies? If the source includes strain-rate sensitivity or thermal softening, these must be carried explicitly.

This decomposition produces a solver-neutral material specification. The following table shows a representative example for a ductile steel, expressed in physical terms before any solver encoding.

This specification is the reference against which every target-solver card is checked. If a target solver cannot represent one of these items, that limitation must be recorded as a known deviation, not silently ignored.

Mapping to Solver-Specific Implementations

Each solver encodes the same physics differently. Consider the hardening curve above. In Abaqus, it is entered as a *PLASTIC table with true stress and true plastic strain pairs. In LS-DYNA, the same data may go into *MAT_PIECEWISE_LINEAR_PLASTICITY (MAT_024), where the first point is the yield stress and subsequent points define the hardening curve. In ANSYS Mechanical APDL, it becomes a TB,PLASTIC table with the same paired data, but the solver's default integration may differ.

The mapping is not always one-to-one. A combined isotropic-kinematic hardening model in Abaqus (*PLASTIC, HARDENING=COMBINED) has no direct equivalent in many explicit solvers. The practical options are:

• Approximate with isotropic hardening and document the loss of Bauschinger effect.
• Use a kinematic hardening card if the target solver provides one, and re-fit the parameters.
• Switch to a user-defined material subroutine if the target solver supports it and the fidelity requirement justifies the cost.

Units are a frequent source of error. A card written in mm-tonne-s must be converted consistently before insertion into a solver expecting m-kg-s. Density, modulus, and yield stress all scale differently. The following snippet shows a typical LS-DYNA material block for the steel above, using mm-tonne-s units:

*MAT_PIECEWISE_LINEAR_PLASTICITY
$ MID  RO        E         PR       SIGY      ETAN      FAIL      TDEL
  1    7.85E-9   210000    0.30     355.0     0.0       0.0       0.0
$ LCSS  LCSR      VP
  0     0         0.0
$ EPS1  EPS2      EPS3     EPS4     EPS5      EPS6      EPS7      EPS8
  0.0   0.02      0.05     0.10     0.0       0.0       0.0       0.0
$ ES1   ES2       ES3      ES4      ES5       ES6       ES7       ES8
  355.0 420.0     480.0    520.0    0.0       0.0       0.0       0.0

Note that SIGY is repeated as the first point of the hardening curve. This redundancy is intentional in MAT_024 and must be consistent; a mismatch between SIGY and ES1 produces a discontinuity at yield that can trigger premature element failure.

Equivalence Checking: From Card to Response

Two material cards are equivalent only if they produce the same stress-strain response under the same loading path. Card-level comparison is necessary but not sufficient. The recommended verification procedure is a single-element test:

1. Build a one-element cube model in both source and target solvers with identical dimensions and boundary conditions.
2. Apply a prescribed displacement history that covers the expected strain range, including unloading if cyclic behavior matters.
3. Extract the stress-strain curve from both runs and overlay them.
4. Quantify the deviation: peak stress difference, yield point offset, and area between curves.

Acceptance criteria depend on the analysis purpose. For a stiffness-driven design study, a 2% deviation in peak stress may be acceptable. For a crash or fatigue analysis, the same deviation may be disqualifying. The following SVG illustrates the verification workflow and the decision points where a mapping can fail.

Handling Solver-Dependent Implementations

Some material behaviors are inherently solver-specific. Explicit codes regularize softening through element deletion or damage variables; implicit codes may converge to a different solution branch. Hyperelastic models are particularly sensitive: a Mooney-Rivlin fit in one solver may use a different strain energy formulation than another, so the same C10 and C01 constants produce different stress responses.

When a direct mapping is impossible, the correct engineering response is to define an equivalence basis. This is a documented statement of what is being preserved and what is being sacrificed. For example: "The target model preserves elastic stiffness and initial yield but approximates combined hardening with isotropic hardening; cyclic loading results are therefore not transferable." This statement is more valuable than a false claim of exact equivalence.

Practical Checklist for Material Transfer

The following checklist summarizes the minimum steps for a defensible material mapping. It is intended to be applied per material, not per model.

Steps 1 through 4 are preparation; steps 5 through 7 are verification. Skipping verification is the most common cause of cross-solver discrepancies that are later misattributed to meshing or contact. A material mapping that has not been tested on a single element has not been validated.

Material transfer is ultimately a physics-preservation problem, not a file-format problem. The solver card is an encoding; the constitutive law is the intent. Keeping those two layers separate, and verifying the encoded result against the intended physics, is what makes a cross-solver model trustworthy.