code_aster: the deep open-source FEA solver

code_aster is an open-source finite element solver for structural mechanics and thermal analysis, developed by EDF — the French state electricity utility — and released under the GPL. It has been in continuous development since 1989.

The important context is what EDF built it for: assessing the structural integrity of their nuclear fleet. It is not a research prototype that escaped a university, and it is not a lightweight solver with ambitions. It is production software used for safety cases submitted to a nuclear regulator, which is about as demanding an audience as structural analysis has.

That shows up as a validation base running to thousands of documented test cases, each with a reference solution and a stated tolerance — an unusual level of published evidence for any solver, commercial or not.

Plenty of solvers do linear static analysis well. code_aster earns its place where the problem stops being linear:

• Nonlinear material behaviour — a deep library of constitutive models covering plasticity, viscoplasticity, damage and their combinations, rather than a handful of standard curves.
• Fracture mechanics — stress intensity factors, J-integral, crack propagation. This is core to remaining-life assessment and it is not something most open-source codes attempt seriously.
• Creep — deformation accumulating under sustained load at temperature, which matters for anything hot and long-lived.
• Contact and large deformation, with the convergence machinery to make hard contact problems actually solve.
• Thermo-mechanical coupling — its own thermal solver feeding the structural one, which is how welding residual stress and thermal fatigue are done.
• Dynamics — modal, harmonic, transient, seismic analysis with spectrum methods, and rotordynamics.

A code_aster study is a command file — a .comm file — that reads as a sequence of operator calls: read the mesh, assign the material, define the boundary conditions, solve, post-process. It is closer to a script than to an input deck, which makes it powerful and parameterisable, and it means you have to know the operator names and what each expects.

There are two practical frictions worth knowing before you start. Much of the deepest documentation is French in origin; English material exists but the reference documentation is where the real detail lives. And error messages assume you understand the mechanics of what you asked for — a non-converged nonlinear step tells you the truth, but not in a form that suggests the fix.

The result is a solver with an unusually steep entry cost relative to its capability. That gap between what a tool can do and what a competent engineer can get it to do is exactly the gap a front end exists to close — the same argument made at more length in OpenFOAM and the case for a GUI.

code_aster is developed on Linux and distributed for Linux, which is the practical objection to it rather than anything about the mechanics. The usual answers are a virtual machine, WSL, or a container — all of which work, and all of which are a conversation with corporate IT before an engineer can run a single analysis.

There is a fourth route. A sequential build — no MPI, and therefore none of the distributed stack that makes a Windows port hard — has every dependency it needs already built for Windows. That is the route SHD Sim took, and it is what puts a full research code on a desktop with nothing to provision.

For the wider picture of which solver runs which physics, see the open-source stack.