opensim-core and the choice between scripting OpenSim and driving its GUI

Musculoskeletal simulation, provided as a library

OpenSim is software that lets users develop models of musculoskeletal structures and create dynamic simulations of movement. The repository is the SimTK OpenSim C++ libraries and command line applications, plus Java and Python wrapping, and the homepage is opensim.stanford.edu.

The domain matters for the evaluation. This is not a general physics engine that you can point at any mechanical system. It is a library of models and tools built around the biomechanics of movement, which is why the feature set is what it is. The command line applications named in the README are inverse kinematics and computed muscle control, which are the two operations a gait analysis pipeline runs on every trial.

The audience is therefore researchers and engineers in biomechanics, rehabilitation science and related fields, and the people who build the tools around them. The most valuable thing in the repository for that audience is not the application but the library, because a scripted pipeline that runs the same analysis over a thousand trials is what turns a research tool into a research system.

The README also notes a version boundary that matters for anyone arriving from an older installation. This repository contains the source code for OpenSim 4.x, and for 3.x or earlier there is a separate link to the older build instructions, which is the kind of split that regularly costs a new contributor an afternoon.

The interface is deliberately not in this repository

The README states plainly what this repository contains: OpenSim's C++ libraries, OpenSim's C++ examples, OpenSim's command line applications, and OpenSim's Java and Python bindings. And then it states what it does not contain, the source code for the OpenSim GUI, which lives in its own repository.

That separation is the single most useful fact for an adopter, because it tells you where your work goes. If you want to script an analysis, you use the libraries and the bindings, and you install the GUI only if you also want to explore interactively. If you want to build an interface, you are working in opensim-gui against the same libraries, and you are not going to find the interface code here.

It also means the two installation paths are genuinely different products rather than one product with two installers. The GUI is a desktop application you download and run, and it has its own scripting documentation for driving the interface from a script. The libraries and the command line applications are what you compile, bind to or script from Python and Matlab.

For a team deciding how to use OpenSim, the question to answer first is which of the two you actually need. If the answer is a script on a compute cluster or a web service, the GUI is irrelevant and this repository is the whole story. If the answer is a person at a desk exploring a model, the GUI is the product and this repository is its engine.

Four routes in, and they are genuinely different

The Download and Setup section lists four ways to get OpenSim, and the differences between them are worth reading carefully.

The OpenSim GUI has its own download page on the SimTK file release system, along with a separate page on scripting inside the GUI.

For Matlab and Python scripting there is a setup instructions page, and for scripting in Conda there is a published conda package at anaconda.org/opensim-org/opensim, with its own source repository, conda-opensim, and a page with more information. The conda route is the one most people running Python should look at first, because it avoids a C++ build entirely and gives a working import.

For C++ development there are the build instructions, covering Windows, macOS and Linux with Ubuntu and Debian named explicitly, a developer's guide, and the C++ API reference hosted on simtk.org.

For help there are two channels, a forum and the GitHub issue tracker, and the README is honest that the forum is where questions are asked while issues are for bugs and feature requests.

The build section adds that the project provides scripts to build OpenSim on Windows, macOS and Linux, with the instructions to download and execute those scripts on the Build Instructions wiki page. The practical note for C++ developers is that the scripts, not a hand written sequence of cmake commands, are the supported route, and the wiki page is the authoritative version of them.

The command line applications and the language bindings

The repository contents tell you what a consumer can call. The command line applications cover inverse kinematics and computed muscle control among others, and the language bindings mean the same models are reachable from Python, Matlab and Java.

That set of bindings is what makes OpenSim usable inside a larger pipeline. A gait analysis workflow typically needs to run a marker based inverse kinematics solve, then a muscle analysis, over every trial in a study, and then feed the results into a statistics pipeline. Doing that by hand in a desktop interface is a research assistant's afternoon per trial. Doing it through the Python bindings is a loop.

The documentation supports that reading. The API example in the repository's wiki is a simple elbow simulation written in C++, Python and Matlab, which is exactly the right size of example for learning the shape of the API, and the tutorials site is described as moving from introductory to more advanced so that OpenSim can be learned progressively. There is also a Biomechanics of Movement classroom site with additional tutorials, homework problems and project ideas, which tells you that the primary audience includes students, and that the teaching path is a real use case for the library.

The C++ API reference is hosted separately on simtk.org, and the main documentation lives on the SimTK Confluence site. That arrangement, documentation on a separate host from the code, is a long standing characteristic of the project and it has a practical consequence for an adopter, the reference you read may not describe the version you built.

CMake presets, vendored dependencies and a wheel build

The repository layout shows how a large scientific C++ project is organised, and OpenSim is not a small one.

The OpenSim/ directory holds the libraries, Applications/ the command line applications, Bindings/ the Java and Python wrapping, Vendors/ the third party code, dependencies/ the dependency management, cmake/ the build system support, scripts/ the build scripts, tests/ the test suite and doc/ the documentation sources.

Two files in the root tell you how the build is driven. CMakeLists.txt with CMakePresets.json means the project uses CMake presets rather than a single configure line, which is how a project with several platforms and configurations keeps the option sets consistent, and buildWheel.cmake is the script that produces the Python wheel, which is how the bindings are distributed to people who are not compiling C++ themselves.

There is a.clang-format file at the root, and the presence of a formatting configuration in a research codebase is a good sign about how the code is maintained. The CHANGELOG.md and CHANGELOG_MOCO.md pair is worth a note: a separate changelog for MOCO suggests that side of the project has its own release rhythm.

The CI badge points at a continuous integration workflow, and the repository is under the opensim-org organisation, which is the modern home of the project.

Documentation that lives on another host, and code that moves quickly

The documentation situation is the thing to check before you commit to this project, because it is spread across at least four places. The main documentation is on the SimTK Confluence site, the C++ API reference is on simtk.org, the build instructions and the elbow example are in the GitHub wiki, and the tutorials are on a separate site. The README is a directory to all of it rather than a manual itself, which is the right structure for a project of this size and the wrong one if you need to answer a question offline.

The code, by contrast, moves at a reasonable pace. The recent releases are 4.6 on 2026-07-09, 4.5.2 on 2025-04-22 and 4.5.1 on 2024-08-23, so a feature release in 2026 and patch releases in the two years before it. The repository is not archived, and the last push was on 2026-10-18.

The licence is Apache 2.0, with the text in LICENSE.txt, and there is a separate NOTICE file, which is the convention for a project that vendors third party code, and the Vendors/ directory confirms there is some. There is also a CODE_OF_CONDUCT.md, a CONTRIBUTING.md and a DEVELOPING.md, and the README asks contributors to read the developer's guide, the developer's guidelines and the code of conduct before opening a pull request.

The judgement for an adopter is that opensim-core is a serious, well maintained scientific codebase with a permissive licence, an unusually broad set of language bindings for a domain tool, and a documentation structure that rewards a small amount of reading before you start.

Editorial conclusion

Adopt opensim-core if you are scripting musculoskeletal simulation, running inverse kinematics or computed muscle control in a batch, or embedding OpenSim in a C++ tool, since the libraries and the command line applications are exactly that surface. Do not adopt it for interactive use, because the interface is a separate repository, and do not adopt it as a general purpose multibody dynamics solver, because the model library is domain specific. Verify three things first: which scripting route you will use, since the conda package, the GUI's scripting mode and a source build differ in what they give you, which version your downstream tools expect, because this repository is the 4.x line and older releases live elsewhere, and how the documentation you find relates to the code you have. The last push was on 2026-10-18 and the newest release is 4.6 from 2026-07-09.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. opensim-org/opensim-core on GitHub
3. Project website
4. README
5. Releases