2. CAE solver landscape

Cross-solver transferability assessment begins with an honest inventory of the solver landscape. A model that transfers cleanly between two solvers from the same vendor family is a very different engineering claim from one that survives a jump between a commercial implicit structural code and an open-source explicit dynamics package. The purpose of this chapter is to map the major solvers, the file formats they read and write, and the specific interoperability failure modes that make cross-solver transfer risky.

2.1 The Major Solver Families

Commercial CAE solvers dominate production workflows and can be grouped by physics discipline and numerical method. In structural mechanics, Abaqus (Dassault Systèmes) and ANSYS Mechanical are the most widely deployed implicit codes, with Abaqus/Explicit and ANSYS LS-DYNA covering transient dynamic and crash scenarios. Nastran (MSC Nastran, NX Nastran, and the open-source CalculiX as a partial clone) remains the reference for aerospace structural analysis, particularly modal, buckling, and aeroelastic workflows. LS-DYNA is the de facto standard for explicit crash and impact simulation. In computational fluid dynamics, ANSYS Fluent, STAR-CCM+, and OpenFOAM cover the compressible and incompressible spectrum. Multiphysics coupling increasingly pushes these solvers into shared workflows, which is precisely where transferability problems concentrate.

Open-source solvers have matured to the point where they are credible transfer targets, not just academic curiosities. OpenFOAM for CFD, CalculiX and Code_Aster for structural analysis, Elmer for multiphysics, and FEniCS/deal.II for custom finite element research all accept or emit standard mesh and result formats. The practical distinction is not open versus closed source but documented versus undocumented solver behavior: open-source codes expose their element formulations and integration schemes in source, while commercial codes often treat these as proprietary, making it harder to predict how a transferred model will behave.

2.2 File Formats: The Transfer Medium

Model transfer happens through files, and the format determines what information survives the trip. Three categories matter:

• Neutral mesh and geometry formats — STEP (AP203/AP214/AP242) for geometry, IGES for legacy geometry, and STL for tessellated surfaces. These carry shape but almost no simulation intent: no boundary conditions, no material assignments, no solver settings.
• Solver-native input decks — Abaqus .inp, Nastran .bdf/.dat, LS-DYNA .k, OpenFOAM dictionaries (controlDict, fvSchemes, fvSolution). These are complete but solver-specific; keyword semantics differ even when names coincide.
• Interchange and results formats — CGNS for CFD mesh and solution data, Exodus II for finite element meshes and results, HDF5 as the container underneath both, and VTK/VTU for visualization. These are the most transfer-friendly because they are governed by published standards.

The critical insight is that no single format carries the full simulation definition. A STEP file gives you geometry; a CGNS file gives you mesh and fields; neither carries the contact definitions, solver controls, or unit conventions that determine whether the analysis is physically meaningful.

2.3 Where Interoperability Breaks

Interoperability failures cluster into five recurring categories. Understanding them is the foundation for the assessment methodology developed later in this course.

Element and formulation mismatch. A quadratic hexahedral element (C3D20) in Abaqus has no exact counterpart in every target solver. CalculiX supports C3D20 but with different integration and hourglass control defaults. When a model is translated, elements may be downgraded to linear, reduced integration may be silently enabled, or incompatible element types may be substituted. The result is a stiffness change that shows up as a frequency shift in modal analysis or a different stress concentration factor.

Unit and coordinate convention drift. Abaqus is unit-agnostic; the user supplies consistent units. Nastran traditionally assumes consistent units but many legacy decks use inches and lbf. OpenFOAM requires SI. A model transferred without explicit unit reconciliation can be off by factors of 10³ or more. Coordinate system orientation (right-hand vs. left-hand, Z-up vs. Y-up) compounds the problem for anisotropic materials and directional loads.

Boundary condition and load semantics. A "fixed" boundary condition in one solver may constrain all six DOF; in another it may constrain only translations. Pressure loads may be defined per-unit-area or as total force. Thermal loads may reference absolute or gauge temperature. These semantic differences are invisible in the file and only surface as wrong results.

Material model availability. Advanced constitutive models — Johnson-Cook plasticity, Gurson damage, anisotropic Hill or Tsai-Wu — are implemented differently or absent across solvers. A transferred model may silently fall back to a linear elastic approximation, producing plausible but wrong results.

Contact and constraint handling. Contact algorithms (penalty vs. Lagrange, node-to-surface vs. surface-to-surface) and constraint methods (tie, coupling, rigid body) are solver-specific. A tied contact that transfers as a node-merge changes the load path entirely.

2.4 A Practical Transferability Probe

Before committing to a full cross-solver study, run a minimal probe that isolates the transfer medium from the physics. The following procedure uses a cantilever beam as the test article because its analytical solution is known, making deviations unambiguous.

Inputs. A 200 mm × 20 mm × 10 mm steel cantilever, E = 210 GPa, ν = 0.3, ρ = 7850 kg/m³. Fixed at one end, 100 N transverse tip load. Mesh with 20 × 2 × 1 quadratic hexahedra (C3D20 in Abaqus, C3D20 in CalculiX, HEXA20 in Nastran).

Procedure. Export the mesh and boundary conditions from the source solver in the most neutral format available (CGNS or Exodus II preferred over native decks). Import into the target solver. Do not re-mesh. Re-apply the tip load manually rather than relying on translated load definitions. Solve linear static.

Observable verification. Compare tip deflection against the Euler-Bernoulli reference δ = FL³/(3EI) = 100 × 0.2³ / (3 × 210e9 × 1.667e-9) ≈ 0.762 mm. A transfer that preserves element formulation and BC semantics should land within 2–5% of this value. A shift beyond 10% indicates element downgrade, unit error, or BC misinterpretation.

Typical failure symptoms and diagnosis. If deflection is off by exactly 1000×, suspect a mm-to-m unit error. If deflection is 20–40% too stiff, suspect quadratic-to-linear element downgrade. If the model runs but produces zero stress, suspect that the fixed BC transferred as a free surface. If the solver reports negative Jacobians, the mesh was exported with a different node ordering convention.

2.5 What This Means for Assessment

The solver landscape is heterogeneous by design: vendors differentiate on element formulations, contact algorithms, and material models, and those differences are exactly what makes cross-solver transfer non-trivial. The assessment methodology in later chapters builds on this reality by treating transferability as a measurable property with specific test cases, tolerance thresholds, and failure signatures — not as a binary "does it import" question. The next chapter introduces the verification metrics that turn the qualitative failure modes above into quantitative pass/fail criteria.