code_aster vs OpenCourant (ex-OpenRadioss): the right solver for the job, tested on four cases
TL;DR. We ran the same four structural problems with code_aster (implicit-first FEA) and OpenCourant (the community fork of OpenRadioss, explicit crash code) on cloudHPC, against experiments and closed-form solutions.
- Fast impact (Taylor bar): both land within 9% of the measured shape; OpenCourant takes 14 s, code_aster 23 min on the same mesh.
- Thin-walled tube crush: OpenCourant runs the full 100 mm crush with self-contact in 13.5 min. code_aster cannot use any of its shell elements for this explicit, large-rotation, plastic problem; four attempts end with documented errors. A 3D-solid workaround runs for 6.3 h and gives 37 kN without any folding.
- Slow plasticity (thick cylinder): both agree with Hill’s closed form; code_aster solves it statically in 38 increments, OpenCourant needs 36,000 explicit cycles and an artificial load ramp.
- 10,000 h creep: code_aster matches the analytical steady state within 1% in under a minute. OpenCourant stops at cycle 1 (mass-scaling limit), and its implicit solver is not in the precompiled build.
Short events, contact and large deformation: use OpenCourant. Static, quasi-static and long-term behaviour: use code_aster. On cloudHPC you can switch between them per job.
Why compare these two solvers now
In early October 2026 Siemens closed the OpenRadioss project and removed its public GitHub repository. Within days, Brian Clemens (founder of Rocky Linux and the RESF) launched OpenCourant, an AGPLv3 fork built from the last public OpenRadioss snapshot [1, 2]. OpenCourant is now the open-source explicit crash solver, and it is available on cloudHPC next to code_aster, the open-source FEA suite developed by EDF.
The two codes are often mentioned together, but they were built for opposite ends of structural mechanics. code_aster is implicit-first: static, quasi-static, modal, creep, thermo-mechanics. OpenCourant is explicit-first: crash, impact, blast, highly non-linear contact. Both offer the “other” scheme on paper: code_aster has explicit time integration in DYNA_NON_LINE, and Radioss has an implicit module. We wanted to know what happens when you push each one outside its comfort zone, with real runs, real error messages and real costs.
Results at a glance
| Case | Physics | Reference | code_aster | OpenCourant | Right tool |
|---|---|---|---|---|---|
| 1 · Taylor bar | impact, 300% plastic strain, 100 µs | experiment [3] | L −8.9%, D −6.4% · 23 min | L −7.6%, D +3.6% · 14 s | OpenCourant |
| 2 · Square tube crush | thin shells, folding, self-contact, 21 ms | experiment [4], theory [5] | shell elements unusable; 3D-hexa workaround: 37.1 kN at 12.5 mm and still rising, no folding · 6.3 h on 16 vCPU | peak 25.6 kN, mean 14.8 kN · 13.5 min for 100 mm | OpenCourant |
| 3 · Thick cylinder | quasi-static plasticity | Hill closed form [6] | matches · 14 s, 38 increments | matches · 8 s, 36,000 cycles + load ramp | code_aster (both work) |
| 4 · Creep 10,000 h | Norton creep, stress redistribution | analytical steady state [7] | within 1% · 53 s | stopped at cycle 1 | code_aster |
How the runs were set up
Every case was run on cloudHPC with the solver builds available on the platform: code_aster 17 with MPI (17.0 and the latest 17.x build) and the first OpenCourant build released on cloudHPC (October 2026), plus the last OpenRadioss build for cross-checks. Meshes were generated with gmsh and are identical between the two solvers wherever the element technology allows it. The material constants are identical in both decks. Wall times are solver times read from the logs; costs are the cloudHPC charges reported at the end of each run, including VM start-up.
Case 1 · Taylor bar impact (OFHC copper at 225 m/s)
A 34.5 mm × 7.8 mm OFHC copper rod hits a rigid, frictionless anvil at 225 m/s. Zelepugin et al. measured a final length of 22.5 mm and an impact-end diameter of 15.8 mm [3]. Both solvers use a quarter model with 8,256 hexahedra and the isothermal Johnson–Cook law with the original 1983 constants for OFHC copper (A = 90 MPa, B = 292 MPa, n = 0.31, C = 0.025) [8].
| Final length | Impact diameter | Solver time | Notes | |
|---|---|---|---|---|
| Experiment [3] | 22.5 mm | 15.8 mm | – | |
| OpenCourant | 20.80 mm (−7.6%) | 16.37 mm (+3.6%) | 14 s, 4 cores | HEPH solid, rigid wall |
| OpenRadioss (cross-check) | 20.76 mm (−7.7%) | 16.89 mm (+6.9%) | 18 s, 4 cores | same deck |
| code_aster | 20.50 mm (−8.9%) | 14.79 mm (−6.4%) | 23 min, 4 MPI | explicit DIFF_CENT, VMIS_JOHN_COOK; same result on 17.0 and the latest 17.x build |
What we learned. Accuracy is similar: all three under-predict the length by 8–9%, which points to the material constants (annealed-copper Johnson–Cook data, no thermal softening) rather than the solvers. The difference is everything around the result. code_aster’s first attempt stopped at 5.3 µs with MECANONLINE9_3: the Johnson–Cook local integration failed at the impact edge, and an explicit scheme has no time-step cutting to fall back on. Raising ITER_INTE_MAXI from 20 to 200, as the error message suggests, got it through. It then needed about 6,700 time steps and 23 minutes; OpenCourant did the same event in 14 seconds. Under-integrated, hourglass-controlled bricks and a lean explicit loop are what crash codes are built on.
Case 2 · Square tube axial crushing (AA6063-T5)
An aluminium AA6063-T5 square tube (38.1 mm side, 1.59 mm wall, 203.2 mm long) is crushed axially by 100 mm. Yob et al. measured a peak force of 21.67 kN and a mean crushing force of 9.71 kN [4]; the Abramowicz–Jones formula gives 9.4–10.4 kN depending on the flow stress [4, 5]. We drive the top at 5 m/s (a common quasi-static choice for rate-insensitive aluminium) with a smooth ramp. The material curve uses yield 118 MPa and UTS 152 MPa from [4].
OpenCourant: the natural tool
12,864 QEPH shells, 5 integration points through the thickness, a type 7 self-contact interface for the folds, and a rigid body on the top edge. The run finished 100 mm of crush in 812 s on 4 cores (377,272 cycles, energy error −0.8%), for €0.15.
The tube folds progressively from the clamped base, as in the tests. The peak force (25.6 kN) is 18% above the test value. The mean force (14.8 kN) is clearly higher than the measured 9.71 kN. A finer mesh (1.0 mm, 28,800 shells) gives a very similar mean of 14.3 kN, so this is not mesh resolution. We ran the fine mesh with both OpenCourant and the last OpenRadioss build: the energy histories match to the last printed digit (650,563 cycles each, 26 min on 8 vCPU, €0.51), which confirms that the fork has not changed the solver so far. The gap comes from our modelling choices: an idealised hardening curve built from just two numbers, both ends fully clamped instead of resting on platens, and a geometrically perfect tube. We report it as it is; a calibrated material curve would be the next step.
code_aster: four shell routes, four stops
A thin-walled crush calls for shell elements, explicit time integration, large rotations and plasticity, all at the same time. We ran each combination code_aster offers on cloudHPC. Every attempt stops before the first time step, with these messages:
| Attempt | Error | What it means |
|---|---|---|
DKT shells + GROT_GDEP |
COMPOR1_48 |
Large rotations only with an elastic material. |
| COQUE_3D shells, lumped mass | CALCUL_37 (MASS_MECA_EXPLI) |
No lumped mass for COQUE_3D; it also cannot compute the stable time step, so STOP_CFL='NON' is needed. |
| COQUE_3D shells, consistent mass | ELEMENTS3_91 |
No mass matrix at all for COQUE_3D with large rotations. |
| COQUE_SOLIDE (solid-shell) | CALCUL_37 (PAS_COURANT) |
No explicit stable time step for the solid-shell element. |
The remaining route is plain 3D hexahedra, two layers through the 1.59 mm wall: 25,728 elements, a 60 ns time step, and no self-contact (code_aster’s contact needs predefined master/slave pairs and only penalty is available in explicit). It runs, but slowly: we limited it to the first 12.5 mm of crush (3 ms), which took 6.3 h on 16 vCPU (8 MPI processes), €8.22. The result shows why this is a workaround, not a crash model. The force jumps to 30 kN and keeps rising to 37.1 kN at 12.5 mm, 71% above the test peak and 45% above OpenCourant, and no fold forms. With two layers of linear hexahedra the wall is far too stiff in bending, so the perfect tube never buckles: the whole cross-section yields in compression instead, close to its squash load (about 232 mm² × 152 MPa ≈ 35 kN). OpenCourant’s shells buckle at 3 mm and drop the force, as the real tube does.
A note on the first attempt. Our first code_aster run (€18.77) prescribed the velocity ramp as a displacement in an explicit scheme that expects accelerations (FORMULATION='ACCELERATION'), so the top of the tube barely moved. We fixed the boundary condition and reran; that first run is excluded from the results and the cost table.
Case 3 · Elastoplastic thick-walled cylinder
A steel cylinder (a = 10 mm, b = 20 mm, plane strain, σy = 250 MPa, perfectly plastic) is pressurised to 190 MPa, 95% of the limit pressure 2/√3·σy·ln(b/a) = 200.1 MPa. The plastic zone grows from the bore, and Hill’s solution gives the outer-wall displacement in closed form [6].
Both solvers reproduce the elastic slope exactly and follow the plastic curve; at 190 MPa they are within 1.5% of each other (16.9 µm vs 17.1 µm). The difference is in how they get there. code_aster solves the static problem directly: 38 load increments, mixed displacement–pressure elements (D_PLAN_INCO_UPG) that avoid volumetric locking, 14 s. OpenCourant has to turn a static problem into a dynamic one: a pressure ramp slow enough (2 ms, about 110 periods of the ring’s breathing mode) to keep inertia negligible, and 35,959 cycles. It works, and it took 8 s, but the user has to choose that ramp and check the kinetic energy. We also tested the implicit route in OpenCourant (/IMPL/NONLIN): it stops with Fatal error: MUMPS is required, but not available. The precompiled build does not include the implicit solver; it has to be compiled with MUMPS [9].
Case 4 · Creep of a thick-walled cylinder over 10,000 hours
At 60 MPa the cylinder is elastic, with the highest hoop stress at the bore. Under creep, stress migrates outwards until it reaches the steady-state distribution, which has a closed form for a Norton law in plane strain [7]. We use n = 5 and K = 1585 MPa·h1/5, illustrative values for a steel at high temperature.
code_aster (STAT_NON_LINE, NORTON) covers 10,000 h in 27 adaptive time steps in 53 s. At 10,000 h the hoop stress is 39.3 MPa at the bore and 75.0 MPa at the outer wall, against 39.1 and 75.1 MPa analytically.
OpenCourant has a creep law too (/MAT/LAW129, Norton form). The obstacle is time. The stable explicit time step for this mesh is 77 ns, so 10,000 h would take about 4.7 × 1014 cycles; at the speed measured on this model, that is several thousand years of computing. Mass scaling to a 10 s time step needs about 1016 times the physical mass. OpenCourant refuses: the run stops at cycle 1 with RUN KILLED: TOTAL MASS ERROR LIMIT REACHED, and raising the /STOP limits does not change it. That is the solver protecting you from a meaningless result.
Run times and costs on cloudHPC
| Case | Solver | Resources | Solver time | Job cost* |
|---|---|---|---|---|
| Taylor bar | OpenCourant | 4 vCPU hypercore | 14 s | €0.05 |
| Taylor bar | code_aster | 8 vCPU highcpu, 4 MPI | 23 min | €0.17 |
| Tube crush, 100 mm | OpenCourant | 4 vCPU hypercore | 13.5 min | €0.15 |
| Tube crush, 100 mm, 1.0 mm mesh | OpenCourant | 8 vCPU hypercore | 26 min | €0.51 |
| Tube crush, 12.5 mm | code_aster (3D hexa) | 16 vCPU highcpu, 8 MPI | 6.3 h | €8.22 |
| Thick cylinder | OpenCourant | 2 vCPU hypercore | 8 s | €0.03 |
| Thick cylinder | code_aster | 2 vCPU highcpu | 14 s | €0.01 |
| Creep 10,000 h | code_aster | 2 vCPU highcpu | 53 s | €0.01 |
| Creep 10,000 h | OpenCourant | – | not feasible | – |
*Total job charge, including VM start-up and file transfer; for short runs most of the time is set-up.
How to run these cases on cloudHPC
- code_aster: put the
.export, the.command the mesh (.medor.unv) at the root of the folder. To run on several MPI processes, addDISTRIBUTION=_F(METHODE='SOUS_DOMAINE', NB_SOUS_DOMAINE=n)toAFFE_MODELEand setmpi_nbcpu nin the export; select at least 2·n vCPU. - OpenCourant: upload the starter
*_0000.radand the engine*_0001.rad(or an LS-DYNA.key). cloudHPC runs one MPI process per physical core and converts the animation files to VTK for ParaView. - Explicit jobs that last more than a couple of hours belong on a regular (non-preemptible) instance.
FAQ
Can code_aster do explicit crash simulations?
It has explicit time integration (DYNA_NON_LINE with DIFF_CENT or TCHAMWA) and it ran our Taylor impact on solid elements. For thin-walled crash with shells, large rotations, plasticity and self-contact, none of its shell elements could be used in our tests, and solid-element workarounds are slow and stiff.
Can OpenCourant or OpenRadioss do static or creep analysis?
Radioss has an implicit module (/IMPL), but the precompiled OpenRadioss and OpenCourant builds we tested stop because MUMPS is not linked. Quasi-static problems can be run explicitly with slow loading, as in our cylinder case. Long-term creep is not practical with an explicit scheme.
Is OpenCourant the same as OpenRadioss?
OpenCourant is a community fork of the last public OpenRadioss code, maintained under the Rocky Enterprise Software Foundation and released under AGPLv3 [1, 2]. On our fine-mesh tube crush the two builds gave identical energy histories; on the Taylor bar the final shapes differ by up to 3%.
Which solver should I use for impact, drop tests or crash?
OpenCourant: it is built for short, highly non-linear events with contact, and in our runs it was one to two orders of magnitude faster than code_aster on the same problem.
Which solver should I use for pressure vessels, creep or slow loading?
code_aster: static and quasi-static solvers, mixed elements for plasticity and dedicated creep laws, with a correct result in seconds for our cases.
References
- Phoronix, “OpenCourant: Rocky Linux Developers Create Community Fork Of OpenRadioss”, 4 October 2026. phoronix.com
- OpenCourant project, opencourant.org and github.com/OpenCourant/OpenCourant
- S.A. Zelepugin, N.V. Pakhnutova, O.A. Shkoda, E.N. Boyangin, “Experimental Study of the Microhardness and Microstructure of a Copper Specimen Using the Taylor Impact Test”, Metals 12 (2022) 2186. doi:10.3390/met12122186
- N. Yob, K.A. Ismail, M.A. Rojan, M.Z. Othman, A.M.A. Zaidi, “Quasi Static Axial Compression of Thin Walled Aluminum Tubes: Analysis of Flow Stress in the Analytical Models”, Modern Applied Science 10(1) (2016) 34–46. doi:10.5539/mas.v10n1p34
- W. Abramowicz, N. Jones, “Dynamic axial crushing of square tubes”, International Journal of Impact Engineering 2(2) (1984) 179–208. doi:10.1016/0734-743X(84)90005-8
- R. Hill, The Mathematical Theory of Plasticity, Oxford University Press, 1950 (thick-walled cylinder under internal pressure).
- H. Kraus, Creep Analysis, Wiley, 1980 (steady-state creep of thick-walled cylinders).
- G.R. Johnson, W.H. Cook, “A constitutive model and data for metals subjected to large strains, high strain rates and high temperatures”, Proc. 7th Int. Symposium on Ballistics, The Hague, 1983, 541–547.
- WelSim, “Implicit transient analysis using OpenRadioss”, 17 October 2026. welsim.com
- code_aster documentation, operator DYNA_NON_LINE [U4.53.01] and advice for dynamic analyses [U2.06.13]. code-aster.org
CloudHPC is a HPC provider to run engineering simulations on the cloud. CloudHPC provides from 1 to 224 vCPUs for each process in several configuration of HPC infrastructure - both multi-thread and multi-core. Current software ranges includes several CAE, CFD, FEA, FEM software among which OpenFOAM, FDS, Blender and several others.
New users benefit of a FREE trial of 300 vCPU/Hours to be used on the platform in order to test the platform, all each features and verify if it is suitable for their needs
