OpenRadioss: the AGPL-3.0 finite element solver for crash and impact work
Project brief: OpenRadioss is a powerful, industry-proven finite element solver for dynamic event analysis.
At a glance
- What is it?
- OpenRadioss is the open source code base behind Simcenter Radioss, a nonlinear explicit dynamics solver with LS-DYNA and Abaqus input support. This is what it does, how to install it, and where it stops being the right tool.
- Who is it for?
- OpenRadioss fits engineers and researchers who already understand explicit dynamics and want a solver they can build from source and modify, particularly for crash, impact, battery and biomaterial work.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Fortran, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 20, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What OpenRadioss solves, and who the code base is for
OpenRadioss is a finite element solver for highly nonlinear problems under dynamic loading, which in practice means crash, impact, drop, penetration and similar short-duration events. The README describes Simcenter(TM) Radioss(R) as an analysis solution used for more than 30 years to replace physical tests and shorten design iterations, and OpenRadioss as the publicly available open-source code base derived from it. The audience is stated plainly: researchers, software developers and industry leaders who want to contribute to a solver rather than only consume one.
That framing matters when you decide whether to adopt it. This is not a general-purpose structural analysis package. It is an explicit dynamics code with a large existing element and material library, and the project's pitch is that contributors get a stable base plus continuous integration tooling instead of starting from an empty repository. If your problem is linear static analysis, or a thermal or electromagnetic simulation, the README gives you no reason to be here.
Starter, engine and reader: how the solver is split
The top-level repository layout shows the architecture directly. There are separate directories for starter, engine, reader, common_source, hm_cfg_files, template, tools and qa-tests. The Starter reads and validates the input deck and writes the model into a form the solver consumes; the Engine runs the time integration and produces the animation and time history output. The reader directory holds the input reading code, which is why the README can list several deck formats as supported in the Starter.
Input deck support is one of the more consequential details. The native .rad format is read by the Starter, and LS-DYNA .k and .key decks are described as natively supported in the Starter as well. Abaqus .inp files go through a converter rather than being read natively: the README links to an inp2rad converter in the OpenRadioss/Tools repository. That difference between native reading and conversion is worth noticing, because a converter path means keyword coverage depends on the converter, not on the solver.
Output is similarly split across tools. Animation files can be converted to VTK, time history files to CSV, and an animation to d3plot converter is hosted on the Vortex-CAE GitHub repository rather than in this one. The README does not describe a built-in viewer.
Installing OpenRadioss and running a first deck
The README routes installation through two documents: HOWTO.md for building OpenRadioss and INSTALL.md for running it. Cloning needs both git and git-lfs, which the README states explicitly, so a plain git clone without git-lfs will not give you a complete tree. The repository also ships build_windows.bat, CMakeLists.txt and CMake_Compilers, plus an Apptainer directory for container-based builds.
Start by cloning with large file support enabled.
git lfs install
git clone https://github.com/OpenRadioss/OpenRadioss.git
cd OpenRadiossAfter cloning, the build instructions live in HOWTO.md and the run instructions in INSTALL.md. The repository root contains CMakeLists.txt, so configuration goes through CMake, and build_windows.bat exists for Windows users. The README does not reproduce the compiler matrix or the exact CMake invocation, so read HOWTO.md before choosing a toolchain.
Once a build exists, a run is a Starter pass followed by an Engine pass over an input deck. The README does not give a full command line for either, so treat INSTALL.md as the source for the exact invocation and for the environment variables the executables expect. What the README does give you is the deck formats: a .rad file is the native path, and a .k or .key file can be handed to the Starter directly. If your model is in Abaqus .inp format, convert it first with the inp2rad tool from OpenRadioss/Tools, then run the converted .rad deck.
The graphical entry point is documented separately. Launching OpenRadioss through the openradioss_gui tool is described in doc/openradioss_gui.md, and that document is where the GUI's own requirements and startup steps would be, not this README.
Where OpenRadioss is the wrong tool
The most concrete limitation is documentation ownership. The README points to Altair's online help for the Radioss reference guide, user guide and theory manual, hosted under help.altair.com and dated 2022 in the PDF links. So the authoritative description of keywords, materials and element formulations sits outside the repository, in a commercial vendor's documentation set. That is workable, but it means the open source project and its reference material do not version together. A keyword added to the Starter may not appear in the 2022 PDFs.
Licensing is the second boundary. OpenRadioss is AGPL-3.0. For an internal analysis group that runs the solver on its own hardware and publishes results, that is usually unremarkable. For anyone embedding the solver in a distributed product, the AGPL network and distribution terms are a real design constraint, and the repository's COPYRIGHT.md and LICENSE.md are the files to read rather than a summary.
The third case is workflow fit. There is no preprocessor in this repository. The hm_cfg_files directory and the template directory suggest integration with external meshing and setup tools, and the GUI is a separate tool referenced from doc/openradioss_gui.md. If your team's process depends on a tightly integrated meshing, setup, solve and postprocessing chain from one vendor, adopting OpenRadioss means assembling that chain yourself from the converters and tools the README lists.
OpenRadioss against LS-DYNA and commercial Radioss
The comparison people actually search for is OpenRadioss versus LS-DYNA, and the README answers part of it by accident. OpenRadioss reads LS-DYNA .k and .key decks natively in the Starter. That is a migration path, not an equivalence claim: reading a deck means the keywords are parsed, and the README says nothing about how complete that keyword coverage is or whether results match. Anyone moving an existing LS-DYNA model should expect to validate the conversion against known results rather than assume it.
The comparison against Altair Radioss is cleaner. The README states that OpenRadioss is the publicly available open-source code base, while Simcenter Radioss is the commercial analysis solution with more than 30 years of use. The practical difference is support and packaging: commercial Radioss comes with vendor documentation, a supported installation and the surrounding toolset, while OpenRadioss comes as source you build yourself under AGPL-3.0, with community contribution paths described in CONTRIBUTING.md and Stable_code.md. The solver lineage is shared; the delivery model is not.
Maintenance, releases and the upgrade cost
The release cadence is visible in the tags: latest-20260520, latest-20260615 and latest-20260728, each described as a stable build, with the most recent push to the repository on 2026-07-28. That is roughly monthly stable tagging, and RELEASES.md is the document the README points to for stable releases, with Stable_code.md covering how to access the stable version. A team adopting OpenRadioss should plan on tracking those tags rather than following the main branch, because the stable builds are the ones the project labels as such.
The upgrade cost is mostly build cost. Because the project is Fortran source configured through CMake, moving to a new stable tag means rebuilding, and any local modifications you have made have to be carried forward. The EXTLIB_VERSION.json file at the repository root suggests external library versions are pinned per release, which is the kind of detail that makes a rebuild reproducible but also means a version bump can change your dependency set. The qa-tests directory gives you a way to check a build after upgrading, and the README links a CI workflow for pull request merges, so the project does run automated checks on its own code.
On licence implications, AGPL-3.0 is the identifier in the repository metadata and LICENSE.md is the governing text. Whether your specific use triggers the network clause or the distribution clause is a question for your own legal review, not something the README attempts to answer.
Editorial conclusion
OpenRadioss fits engineers and researchers who already understand explicit dynamics and want a solver they can build from source and modify, particularly for crash, impact, battery and biomaterial work. It does not fit teams that need a supported commercial installation with vendor help, or analysts who expect a graphical preprocessor in the repository: the README points to a separate openradioss_gui tool and to Altair's online help, and the input converters live in the OpenRadioss/Tools repository. Verify first that your hardware and compiler combination is covered by HOWTO.md, that your existing decks use keywords the Starter actually reads, and that the AGPL-3.0 terms are acceptable for how you plan to distribute your work.
Frequently asked questions
How do I install OpenRadioss?
Clone the repository with git and git-lfs, both of which the README states are required, then follow HOWTO.md to build it and INSTALL.md to run it. The repository root includes CMakeLists.txt and build_windows.bat, and an Apptainer directory exists for container builds.
How do I use OpenRadioss?
The workflow is a Starter pass that reads and validates the input deck, followed by an Engine pass that runs the analysis. The README points to doc/Getting_started.md for a quick start and to INSTALL.md for run instructions, and it lists a separate openradioss_gui tool documented in doc/openradioss_gui.md.
What is the difference between OpenRadioss and Altair Radioss?
The README describes Simcenter Radioss as the commercial analysis solution used for more than 30 years, and OpenRadioss as the publicly available open-source code base derived from it, licensed AGPL-3.0. The practical difference is delivery: OpenRadioss is source you build yourself, while the reference guide, user guide and theory manual are hosted in Altair's online help.
Community notes