# Project Chrono: a C++ multiphysics engine for multibody, granular and FSI simulation

> Project Chrono is a BSD-licensed C++ library for rigid and flexible multibody dynamics, granular contact, fluid-solid interaction and vehicle or robotics simulation. It is a build-it-yourself research tool, not a drop-in game engine.

**projectchrono/chrono** — High-performance C++ library for multiphysics and multibody dynamics simulations

- Repository: https://github.com/projectchrono/chrono
- Website: http://projectchrono.org
- Stars: 3,061 · Forks: 637
- Language: C++
- License: BSD-3-Clause
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/projectchrono-chrono

## What Project Chrono simulates, and who the library is aimed at

Project Chrono is an open-source multiphysics package. The README lists the problem classes it targets: connected rigid bodies governed by differential-algebraic equations, deformable bodies governed by partial differential equations, granular dynamics under either a non-smooth contact formulation that produces differential variational inequalities or a smooth formulation that produces DAEs, fluid-solid interaction coupling DAEs and PDEs, first-order ODE systems, and sensors including camera, LiDAR, GPS, IMU and SPAD exposed through a ROS2 interface.

That list is the audience definition. This is not a general-purpose game physics library. It is aimed at researchers and engineers modelling mechanical systems where the equations of motion matter more than frame rate: ground vehicles and terramechanics, robotics and embodied AI, granular material, flexible bodies, and coupled fluid-structure problems. The README states the package has been used by researchers in academia, industry and federal government, and that ground vehicle simulation and terramechanics are among the areas with mature support.

The implementation is almost entirely C++, with Python and C# APIs on top. If you work in Python only, PyChrono is the documented entry point, but the core modelling concepts and most of the module documentation are written for the C++ API.

## How the core and the optional modules fit together

Chrono separates a core from optional modules. The README describes the core as providing modelling, simulation and visualization of rigid and flexible multibody systems, with additional capabilities delivered through modules. Those modules cover granular dynamics and fluid-solid interaction, specialized systems such as ground vehicles and robots, co-simulation, run-time visualization, post-processing, interfaces to external linear solvers, and parallel algorithms across multi-core, GPU and distributed targets.

That split is the main architectural decision a new user has to internalize. You do not get granular contact or FSI by default; you enable the module that provides it and accept its dependencies. The repository layout reflects the same idea: there are separate template project directories for C++, C#, FMI 2, ROS and vehicle co-simulation, so a project is expected to be assembled around the modules it needs rather than built as one monolith.

The build system is CMake, and the repository carries CMakeLists.txt, CMakePresets.json and a cmake/ directory. The README points to install guides at api.projectchrono.org/install_guides.html rather than embedding platform steps. The README also states that Chrono is platform-independent and is actively tested on Linux, Windows and macOS with a variety of compilers. For AMD GPU work there is a separate document, docs/README_AMD_GPU.md, which the README summarizes as covering CPU PyChrono versus HIP/FSI, CMake hints and the ROCR_VISIBLE_DEVICES environment variable.

## Installing Project Chrono and running a first Python model

The README does not inline installation commands. It points to the build and install instructions at https://api.projectchrono.org/install_guides.html, and the build system is CMake. The Python interface is documented separately at https://api.projectchrono.org/pychrono_introduction.html. What follows is what the repository itself documents: the branch layout, the CMake build system, the template projects, and the agent guidance file.

The README's note on repository structure gives the branch names you need: the main development branch is main, and releases live in branches named release/*.* with tags of the form *.*.*. Cloning the repository is therefore the first step, and the build system is CMake.

```bash
git clone https://github.com/projectchrono/chrono.git
cd chrono
```

For a C++ project, the repository includes template_project/ and template_project_csharp/, which exist so that you start from a working CMake setup rather than writing link flags from scratch. The README also notes that agents working in the repository should read AGENTS.md, and that a local Claude setup is expected to symlink rather than copy it.

```bash
ln -s AGENTS.md CLAUDE.md
```

That symlink is the documented local convention so the guidance file stays in sync with the repository version. The README does not document rollback or uninstall steps, so plan your build directory accordingly.

## The build surface is the real cost of entry

The honest limitation of Project Chrono is not the physics, it is the setup. A library that spans rigid bodies, finite elements, granular contact, fluid-solid interaction, vehicle models and ROS2 sensors cannot be a single include-and-link dependency. Each optional module brings its own third-party requirements, and the README delegates the whole question to the install guides rather than summarizing it. If your team expects a package manager install and a working simulation in an afternoon, this is the wrong tool.

There is a second, subtler cost. Choosing between the non-smooth and smooth contact formulations for granular dynamics changes the mathematical problem you are solving, and the README presents both without recommending one for a given case. That is a modelling decision the user has to make with domain knowledge, and getting it wrong shows up as solver behaviour rather than as a compile error.

The repository structure also carries a migration note worth reading before you follow an older tutorial. The main development branch was renamed to main from develop, the obsolete master branch was deleted, and releases live in branches named release/*.* with tags of the form *.*.*. Tutorials and build scripts written against the old branch names will not resolve. Chrono is also not a real-time game engine: the README describes run-time visualization as a module, and the package is framed around simulation and post-processing, not around shipping a playable build.

## Chrono versus a general rigid-body physics engine

The obvious alternative for someone who just needs bodies to fall over is a general-purpose rigid-body physics engine of the kind used in games and simple robotics demos. The difference in approach is the formulation. A typical game engine solves rigid-body contact with an iterative impulse solver tuned for stability at interactive rates, and it does not attempt deformable bodies, granular material or fluid coupling.

Chrono instead formulates connected rigid bodies as differential-algebraic equations and deformable bodies as partial differential equations, and it offers granular contact as either a DVI problem or a DAE problem. That is a heavier mathematical apparatus, and it is what makes flexible-body and fluid-solid interaction work possible inside the same framework. The price is that you configure and build the modules you need, and you think about solver selection.

A second alternative is writing the equations yourself against a linear algebra library. That is defensible for a single narrow problem, but you then own the contact handling, the time integration and the parallel execution, which the README lists as module-provided capabilities. Chrono's value proposition is that these pieces already exist and interoperate; its cost is that you adopt its build and its module boundaries along with them.

## Release cadence, licence and what an upgrade actually involves

The repository is not archived, and the last push was on 2026-09-23. Recent releases are 10.0.0 on 2026-04-07, 8.1.0 on 2025-06-28 and 9.0.1 on 2024-07-03. That sequence is worth reading carefully: 10.0.0 is the current release, and the version numbering has not been strictly monotonic in time, so pin to a tag rather than assuming the newest tag is the one your code was written against.

Upgrade cost is dominated by the C++ API and by module dependencies, not by a configuration file you can edit. The README publishes a separate API reference per release, including 10.0.0 and 9.0.0, which is the practical way to diff what changed between the version you build against and the one you move to. There is also a CHANGELOG.md at the repository root. Because the main branch is now main and releases live in release/*.* branches, an upgrade path that pins to a release branch is more predictable than tracking main.

The licence is BSD-3-Clause, stated in the README and present as LICENSE at the repository root, with a license text referenced at projectchrono.org/license-chrono.txt. A permissive BSD licence generally permits commercial and closed-source use with attribution and without copyleft obligations, but the terms that apply to you depend on the exact text and on the licences of any optional third-party modules you enable. That is a question for your own legal review, not something the repository answers for you.

## Conclusion

Adopt Project Chrono if your problem is a mechanical system governed by DAEs or PDEs and you can afford a CMake build and C++ integration. Do not adopt it as a game physics engine or as a turnkey packaged binary. Before committing, read the install guides for your platform, confirm which optional modules you actually need, and check whether your solver requirements are covered by the modules you can build.

## FAQ

### Is Project Chrono a C++ library?

Yes. The README states it is implemented almost entirely in C++, with Python and C# APIs also provided, and the build system is CMake.

### What licence does Project Chrono use?

It is distributed under the BSD-3-Clause licence, stated in the README and present as LICENSE at the repository root.

### Which platforms does Project Chrono run on?

The README states the library is platform-independent and is tested on Linux, Windows and macOS with a variety of compilers.

## Sources

- [License: BSD-3-Clause](https://github.com/projectchrono/chrono/blob/main/LICENSE)
- [projectchrono/chrono on GitHub](https://github.com/projectchrono/chrono)
- [Project website](http://projectchrono.org)
- [README](https://github.com/projectchrono/chrono/blob/main/README.md)
- [Releases](https://github.com/projectchrono/chrono/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/projectchrono-chrono