# SOFA is a finite element framework for deformable simulation, packaged as libraries > SOFA is an open source C++ framework for interactive physics simulation based on the finite element method, aimed at medical simulation and robotics, and the README is clear that the important form of it is not the runSofa application but the bundle of libraries underneath. What it offers is a graph of interchangeable components, a plugin mechanism, and a licence layout that is LGPL for the core and GPL for the applications and tutorials. **sofa-framework/sofa** — Real-time multi-physics simulation with an emphasis on medical simulation. - Repository: https://github.com/sofa-framework/sofa - Website: https://www.sofa-framework.org - Stars: 1,299 · Forks: 371 - Language: C++ - License: LGPL-2.1 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/sofa-framework-sofa ## Finite element, and the two domains it targets SOFA is described as an open source framework targeted at interactive physics simulation based on the Finite Element Method, with an emphasis on medical simulation and robotics, and the README says it is mainly intended for the research community, so that new algorithms can be developed against it, while it can also be used as an efficient prototyping tool. The choice of finite element method rather than a rigid body engine is the defining technical fact. FEM divides a deformable body into a mesh and solves for how the elements deform under load, which is what makes it the tool for soft tissue, organs, muscles and compliant robots, and what makes it the wrong tool for a stack of crates. The two domains are not unrelated. Medical simulation needs deformable mechanics, and robotics needs a model of a deformable object to control against. A gripper that squeezes a deformable object, a surgical tool interacting with tissue, a soft robot that changes shape, and a humanoid whose body is not rigid, all of them need the same machinery. The audience is therefore a research group or a company with a simulation problem that is hard rather than merely large, and the README's emphasis on developing new algorithms tells you the intended user is someone who intends to modify the code, not only run it. ## The architecture is a graph of replaceable pieces The README lists five things the architecture allows, and read together they describe a component system rather than an application. The creation of complex and evolving simulations by combining new algorithms with existing ones. The modification of key parameters of the simulation, naming deformable behavior, surface representation, solvers, constraints and the collision algorithm. The synthesis of complex models from simpler ones using a graph description. The efficient simulation of the dynamics of interacting objects using abstract equation solvers. And the comparison of various algorithms and mathematical models. That last point is the one that matters most for a research framework. If the solver is an abstract interface, the same mechanical model can be run with different solvers and the results compared, which is the only way to argue that one formulation is better than another on a shared scenario. The same applies to the surface representation, to the constraint set and to the collision algorithm, each of which is a component that can be swapped. The graph description is the other half. A simulation is a graph whose nodes are components and whose edges are the data flow between them, and a model is built by composing simpler ones. The consequence for a user is that a SOFA scene is data, and the cost is that a scene file is not something you can write by hand without learning the vocabulary of the components available. For a team evaluating the framework, the practical test is whether the algorithm they intend to publish is a new component in this graph. If it is, the framework does exactly what they need. ## It is a set of libraries, and runSofa is the demo The README makes a point that is easy to skim past and that determines how you should evaluate the project. SOFA is often presented as a standalone software, runSofa, and a simulation tool, but the project is most importantly a bundle of libraries and thus can be used or integrated in any project. That is the honest description of a research framework, and it changes the deployment question. A team that wants a simulation tool will download and run runSofa, and the README sends them to the SOFA download page for the binaries and the source. A team that wants the simulation inside their own application, in a pipeline that drives it, or in a service that runs many scenarios, embeds the libraries instead, and that is the mode the architecture was designed for. The second mode is the one with the better long term economics for a research group, because a scenario that lives in a script can be re-run, parameter swept, and run on a cluster. The first mode is the one that gets you a picture of a deformable body deforming in an afternoon. The repository layout reflects the same split. The Sofa/ directory holds the framework itself, applications/ holds the applications and the plugins, examples/ holds the scenes, and share/, tools/, scripts/, cmake/ and extlibs/ hold the data, the utilities, the build scripts and the third party libraries. There is also a development/ directory and GUIDELINES.md, which reads like the project's coding conventions. ## Plugins are the extension route, and they are indexed SOFA provides a plugin system allowing the coupling of additional codes to add functionalities, and the README points at three places where plugins live. The first is the source code itself, at the applications/plugins path in the repository. The second is the sofa-framework organisation on GitHub, which hosts the other plugin repositories. The third is the Marketplace, a project page listing plugins, and the README invites people to get their own plugins referenced there. That third point is worth pausing on, because it tells you the project is not trying to keep every extension in its own tree. A research group that has written a new solver or a new constraint publishes it as a separate repository, and the ecosystem is assembled by reference rather than by inclusion. The cost is that a SOFA installation becomes a set of versions to manage, and the benefit is that the core does not grow a plugin for every research group's special case. For a team choosing this framework, the plugin list is the strongest signal available about its health, because it is where the real extension surface is. The same README points to support on GitHub Discussions, a Discord server, a contact address and a jobs page, so the project is organised as a consortium rather than a single maintainer's repository. ## The licence layout decides where you can put it The licence section is more specific than a single licence line, and an adopter should read it as a map. SOFA is LGPL, except for applications and projects, which are GPL, and applications and tutorials, which are also GPL, and any directory that has its own license file specifying a different licence. The LGPL is the GNU Lesser General Public License as published by the Free Software Foundation, either version 2.1 of the licence or, at your option, any later version, and the GPL is version 2 of the GNU General Public License. The practical reading is that the framework libraries carry LGPL terms, which is the permissive-enough end for a research framework that wants to be embedded, while the applications built on top of them, including the tutorials that people copy from, are GPL and therefore stickier. That is a coherent and common arrangement for a tool that wants to be used in commercial research and development, and it has a consequence worth planning for. If you take code from a tutorial, that code is GPL, so it is worth reading the licence of the specific directory you copy from rather than assuming the LGPL of the core covers it. The repository carries a LICENSE-LGPL.md at the root and a per directory licence file mechanism, and the README says plainly that directories with a licence file specifying a different licence take that licence. ## CMake, Nix and Pixi all in the tree The build tooling in the repository is a good indicator of how a project is actually used, and there are three systems side by side. CMake is the primary one, with a CMakeLists.txt at the root and a CMakePresets.json for the configurations. Nix appears as a flake.nix, a package.nix, a flake.lock and a tight_inclusion.nix, which together describe reproducible environments and a packaged build. Pixi appears as pixi.toml and pixi.lock, which is a newer environment manager with its own lock file. Having all three is a consequence of the project's shape. A research group on a cluster wants a reproducible environment, a developer on a workstation wants a fast local setup, and a distributor building a binary wants a package definition. The extlibs/ directory holds the third party dependencies the build pulls in. The examples/ directory is the other half of the build story, and it is organised by what you are trying to do rather than by feature. There is a Benchmark/ directory, a Component/ directory for the individual components, a Demos/ directory of demonstration scenes, an Objects/ directory, a SimpleAPI/ directory for embedding, a Tutorials/ directory and a Validation/ directory. There are also test definitions, with RegressionStateScenes.regression-tests and RegressionTopologyScenes.regression-tests files, and a .scene-tests file, which tells you the project treats the scenes as something that can be checked automatically. The SimpleAPI/ directory is the one to look at first if your intent is to embed the framework rather than run the application, because it is the example of the mode the README says matters most. ## Maintenance and the research posture The release numbering follows the calendar, with the recent versions being v26.06.00 from 2026-07-15, v25.12.00 from 2026-02-05 and v25.06.00 from 2025-07-24. The year and month are in the version, which tells you the project ships on a roughly half yearly cadence and that a release from two years ago is not unusual to encounter in a lab that has pinned it. The repository is not archived and the last push was on 2026-10-15, so work continues between releases. The changelog is in CHANGELOG.md, the contributors are listed in Authors.txt, and the copyright statement names INRIA, USTL, UJF, CNRS and MGH with the year 2006, which is a good indication of the age of the codebase and of the institutions that have carried it. The project documents itself on its own website, with the download page, a documentation link and a get involved page, and it asks people to read the CONTRIBUTING rules carefully before opening an issue or a pull request. That last request is consistent with a project whose interface is a component graph, where a pull request that changes a component's semantics affects every scene that uses it. The honest summary for an adopter is that this is a research framework with a long institutional history and an active release line, whose value is in the composition of its components and the ecosystem of plugins, and whose cost is a large C++ codebase, a multi system build and a licence layout that needs reading before the code is copied into anything commercial. ## Conclusion SOFA suits a research group that needs to build a deformable body or soft tissue model and wants to swap the solver, the constraint set, the collision algorithm or the surface representation without rewriting the simulation, and that is prepared to work in a C++ codebase with a CMake build and a large dependency set. It does not suit a team that wants a small, easy physics engine for a game or a rigid body application. Verify first which licence applies to the part you intend to use, since the core is LGPL while applications and tutorials are GPL, and check the version numbering scheme, which follows the year and month, before planning an upgrade against a release that landed more than two years before the current one. ## FAQ ### What is the SOFA framework? SOFA is an open source framework for interactive physics simulation based on the Finite Element Method, with an emphasis on medical simulation and robotics. It is mainly intended for the research community, so that new algorithms can be developed against it, and can also be used as an efficient prototyping tool. ### Is SOFA an application or a set of libraries? Both, and the README says the library form is the important one. SOFA is often presented as a standalone application, runSofa, but the project is most importantly a bundle of libraries and can be used or integrated in any project. ### How do plugins work in SOFA? A plugin system allows the coupling of additional code to add functionalities. Plugins are referenced from the applications/plugins directory in the source, from other repositories in the sofa-framework organisation, and from the project Marketplace, and the README invites people to have their own plugins referenced there. ### What licence applies to SOFA? SOFA is LGPL, either version 2.1 or any later version, except for applications and projects and applications and tutorials, which are GPL version 2, and any directory with its own licence file specifying a different licence. ### How do I get and build SOFA? The README sends you to the SOFA download page at sofa-framework.org/download/ for the binaries and source. The repository builds with CMake, with CMakePresets.json for configurations, and also carries Nix and Pixi definitions for reproducible environments, along with an examples/ directory covering components, demos, objects, a SimpleAPI example, tutorials and validation. ## Sources - [License: LGPL-2.1](https://github.com/sofa-framework/sofa/blob/master/LICENSE) - [Project website](https://www.sofa-framework.org) - [README](https://github.com/sofa-framework/sofa/blob/master/README.md) - [Releases](https://github.com/sofa-framework/sofa/releases) - [sofa-framework/sofa on GitHub](https://github.com/sofa-framework/sofa) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sofa-framework-sofa