2. Fix Inverted Normals Causing Contact Fai

Why Inverted Normals Break Contact Detection

In LS-DYNA, a shell's normal direction is not a cosmetic attribute — it defines which side of the element is "outside." Contact algorithms that use segment-based detection (surface-to-surface, automatic general, and most penalty-based shell contacts) build contact segments from the shell faces and orient them according to the shell normal. When a shell's normal points into the opposing body instead of toward it, the contact segment faces the wrong way. The solver then either fails to detect the approaching surface at all, or it detects the wrong side and produces zero or wildly oscillating contact force. The classic symptom is a model that runs cleanly, shows visible interpenetration in the animation, and reports near-zero contact energy — the parts pass through each other as if no contact were defined.

This case walks through a reproducible detection-and-correction workflow: identify the offending shells, reverse their normals (or reorient the part), and confirm the fix with a minimal contact force probe before committing to a full run.

Recognizing the Failure Signature

Before touching the mesh, confirm that the problem is orientation and not something else (initial penetration, missing contact definition, or wrong segment type). The following observations together point strongly to inverted normals:

  • Visible interpenetration in d3plot while the contact interface reports essentially no force.
  • glstat contact energy stays near zero even though the parts clearly overlap.
  • messag may show no contact at all, or a small number of segments detected on one part but not the other.
  • Reversing the contact SIDE (e.g., from SIDE=1 to SIDE=2) suddenly produces force — a strong hint that the segment orientation is the culprit.
A quick sanity check: in LS-PrePost, enable Shell Normals display and color by normal direction. Consistent outward-facing normals on a closed part appear uniform; inverted patches show as a contrasting color region.

Detecting Inverted Normals

Two complementary methods are worth using together. The first is a visual/geometric check in LS-PrePost; the second is a solver-side probe that does not depend on the GUI.

Method 1 — LS-PrePost normal display. Load the keyword deck, select the shell part, and turn on Entity > Shell > Normals. Set the color mode to By Normal Direction. Any shell whose normal points opposite to its neighbors will render in the contrasting color. For a closed body, all normals should point outward; a patch pointing inward is the defect.

Method 2 — Contact force probe. Build a minimal two-part model: the suspect shell part and a rigid plane pushed toward it with a prescribed velocity. Define a single *CONTACT_AUTOMATIC_SURFACE_TO_SURFACE and request RCFORC output. If the shell normals are correct, the rigid plane's reaction force rises smoothly as it approaches. If they are inverted, the force stays at zero while the plane passes through. This probe isolates orientation from every other modeling variable.

A. Inverted Normal Rigid plane (moving down) v = 5 m/s normal points INTO plane Plane passes through shell RCFORC ≈ 0 contact energy ≈ 0 B. Corrected Normal Rigid plane (moving down) v = 5 m/s normal points TOWARD plane Plane contacts shell RCFORC rises smoothly contact energy > 0 C. Correction Paths Option 1: Reverse normals *ELEMENT_SHELL_NORMAL or LS-PrePost Reverse Normals Option 2: Reorient part *INITIAL_VELOCITY / transform rotate part so normal faces out Option 3: Contact SIDE SIDE=1 / SIDE=2 / SIDE=SEG use only when geometry is fixed Verify with RCFORC probe force rises, energy > 0 then run full model

Correcting the Orientation

Once the inverted patch is identified, choose the correction that matches the model's intent. Three options are common, and they are not interchangeable — pick the one that preserves the geometry you actually want.

Option 1 — Reverse element normals. This is the cleanest fix when the mesh is correct but the winding order is wrong. In LS-PrePost, select the affected shells and use Element > Reverse Normals. In the keyword deck, the equivalent is to reorder the node connectivity of each shell so that the normal flips (swap the second and third node IDs in the *ELEMENT_SHELL card). For a whole part, *ELEMENT_SHELL_NORMAL can be used to declare the intended normal direction explicitly. After reversal, re-export the keyword file and confirm the change persisted.

Option 2 — Reorient the part. If the part itself is modeled inside-out (e.g., a shell part built as the inner surface of a container), reversing normals alone may leave the geometry on the wrong side. In that case, apply a rigid transform or *INITIAL_VELOCITY with a rotation so the part's outward face points toward the contact partner. This is the right choice when the part's physical orientation, not just its winding, is wrong.

Option 3 — Adjust the contact SIDE. For *CONTACT_AUTOMATIC_SURFACE_TO_SURFACE, the SIDE parameter selects which side of the shell is treated as the contact surface. Setting SIDE=1 or SIDE=2 can make the solver use the opposite face. This is a legitimate fix when the geometry is fixed and only the contact interpretation needs to change, but it is easy to misuse: it does not fix the underlying normal, so any other contact or output that depends on normals (e.g., RCFORC sign, pressure output) will still be wrong. Prefer Options 1 or 2 unless you have a specific reason to keep the mesh as-is.

Do not "fix" inverted normals by simply flipping the contact SIDE and moving on. The normal direction also drives shell pressure output, RCFORC sign conventions, and any tied or spot-weld contact. Correct the normal at the source.

Verifying with a Contact Force Probe

The probe is a small, fast model that isolates the contact behavior. Build it as follows:

  1. Keep only the suspect shell part and a rigid plane. Delete or exclude everything else.
  2. Define *CONTACT_AUTOMATIC_SURFACE_TO_SURFACE between the shell part and the rigid plane, with SOFT=1 and a modest PENALTY scale (e.g., 0.1) so the force response is easy to read.
  3. Give the rigid plane a prescribed velocity toward the shell (e.g., 5 m/s) via *BOUNDARY_PRESCRIBED_MOTION_RIGID.
  4. Request RCFORC and GLSTAT output at a short interval (e.g., every 0.1 ms).
  5. Run for a short duration (e.g., 2 ms) so the plane just reaches and presses into the shell.

Read the result in LS-PrePost: plot the rigid plane's reaction force from rcforc. With correct normals, the force rises smoothly from zero as the plane approaches and then plateaus or oscillates around a stable value as penetration develops. With inverted normals, the force stays at zero while the plane passes through, and glstat contact energy remains near zero. A force that rises but then collapses to zero mid-run usually indicates a normal that flips partway through the mesh — check for mixed orientation within the part.

Only after the probe shows a clean force rise should you re-run the full model. This ordering saves hours of debugging on a large deck and gives you a clear pass/fail criterion: contact force rises monotonically during approach and contact energy is positive.

Quick Reference: Symptom → Cause → Fix

SymptomLikely causeCorrective action
Parts pass through each other, RCFORC ≈ 0Shell normals point away from contact partnerReverse normals (Option 1) or reorient part (Option 2)
Force appears only after changing SIDEContact segment orientation wrongFix normals at source; do not rely on SIDE alone
Force rises then collapses mid-runMixed normal orientation within one partSelect and reverse only the inverted patch
Contact energy near zero despite overlapNo segments detectedVerify normals, then confirm contact definition covers the part

The probe model is small enough to iterate in minutes. Once the force curve behaves, the same corrected keyword deck can be merged back into the full simulation with confidence that the contact interface is oriented correctly.