LS-DYNA migration
=================

LS-DYNA is the dominant explicit-dynamics code for crash and
high-rate impact analysis.  femorph-solver currently ships
**implicit linear-elastic** analyses only, so the LS-DYNA →
femorph-solver migration story is narrower than the MAPDL,
NASTRAN, and Abaqus equivalents — most LS-DYNA decks rely on
analysis types femorph-solver hasn't reached yet.

If you have an LS-DYNA deck and want to use femorph-solver
today, this page is the realistic assessment of the gap and
the workaround paths.

The honest gap analysis
-----------------------

LS-DYNA decks typically contain at least one of:

- Explicit time-integration (``*CONTROL_TIMESTEP``,
  Belytschko-Tsay shells, single-point hourglass control).
- Contact (``*CONTACT_AUTOMATIC_*``, penalty-method
  formulations).
- Material plasticity (``*MAT_PIECEWISE_LINEAR_PLASTICITY``,
  Johnson-Cook, Cowper-Symonds).
- Hyperelasticity / foam (``*MAT_BLATZ-KO``, ``*MAT_OGDEN``).
- Failure / damage (``*MAT_ADD_EROSION``).

**None of these are shipped in femorph-solver today.**  The
explicit-dynamics analysis type is on the long-range roadmap;
contact and plasticity are higher-priority follow-ups but
aren't in any released milestone.

What can be salvaged
--------------------

If your LS-DYNA deck is doing **implicit linear analysis** on
linear-elastic material — a small subset of LS-DYNA's typical
use case but not unheard of — the geometry is portable.
Workflow:

1. Convert the LS-DYNA ``.k`` keyword file to a NASTRAN BDF
   deck through LS-PrePost or the open-source ``ls2bdf``
   converter.  LS-DYNA → BDF is the standard intermediate
   step every commercial migration tool uses.
2. Read the BDF through :func:`femorph_solver.interop.nastran.from_bdf`.
   See :doc:`nastran` for the full BDF coverage.
3. Apply the implicit-linear solve through
   :meth:`Model.solve_static` or :meth:`Model.solve_modal` as usual.

If your LS-DYNA deck is **explicit-dynamics** or
**non-linear**, you have a roadmap-block — neither analysis
type ships in femorph-solver today.  The realistic options:

- **Wait for the analysis type to ship.**  The roadmap is
  visible in the `GitHub project board
  <https://github.com/femorph/solver/projects>`_; explicit
  dynamics is currently a future milestone.
- **Run the deck through LS-DYNA itself**, export the result
  fields to ``d3plot``, and convert to ``.pv`` for
  post-processing in the femorph-solver gallery recipes —
  not currently supported but a future ``d3plot`` reader is
  on the planned-roadmap.
- **Use femorph-solver for an implicit-linear sanity-check
  pass** (modal analysis to identify natural frequencies, a
  static load case to size the elastic envelope) before
  running the explicit deck — common practice in
  rotating-equipment and aerospace workflows.

LS-DYNA → femorph-solver vocabulary
-----------------------------------

For the implicit-linear subset, the cross-vendor terminology
table at :doc:`terminology` covers every concept.  Every
``ELEMENTS.*`` entry's technical sheet
(:doc:`/reference/elements/index`) carries an LS-DYNA
``ELEMENT_*`` row in its cross-vendor mapping table.

Cross-references
----------------

- :doc:`terminology` — the one-table Rosetta.
- :doc:`nastran` — NASTRAN deep-dive.  Recommended migration
  path from LS-DYNA via the ``.k`` → ``.bdf`` intermediate.
- :doc:`abaqus` — Abaqus deep-dive.
- :doc:`/getting-started/mapdl-interop` — MAPDL deep-dive.