openMotor simulates solid rocket motor internal ballistics on your desktop

A desktop simulator for internal ballistics, not a flight simulator

openMotor is described as an open source internal ballistics simulator for rocket motor experimenters. The scope is specific: it estimates a rocket motor's chamber pressure and thrust based on propellant properties, grain geometry and nozzle specifications. It does not model the flight of the vehicle, the trajectory or the aerodynamics, and it is worth being clear about that before you install it, because the word simulator invites a broader assumption.

What it does is the part of motor design that is hardest to do on paper quickly. Change a grain dimension and the burn time, chamber pressure and thrust curve all move in ways that are hard to reason about mentally. The tool exists to compress that loop.

The current feature list covers the whole design workflow rather than a single calculation. It supports metric and imperial units, and common grain geometries such as BATES, Finocyl and Star. You can load custom grain geometry from DXF files, which is how a non standard core shape gets into the tool. There is a propellant editor where you can enter the properties of as many propellants as you like, and a grain editor that displays how a grain will regress, which the README says cuts down on the guesswork involved in tweaking geometry. It exports ENG files, and imports and exports Burnsim files. The UI supports saving and loading designs along with undo and redo, and there are tools for tweaking and optimising a design.

The calculations are sourced from Rocket Propulsion Elements by George Sutton and from Richard Nakka's website, which tells you the model is a well documented textbook one rather than something invented for this program.

Fast Marching Method is what makes arbitrary grains possible

The one sentence in the README that explains the technical choice is the one about the Fast Marching Method. It says openMotor uses the Fast Marching Method to determine how a propellant grain regresses, which allows the use of arbitrary core geometries.

That is the load bearing detail of the whole project. Grain regression in a solid motor is the burning of the propellant surface over time, and for the standard geometries there are well known analytical or semi analytical solutions. Once a designer moves away from those standard shapes, into a custom core or an unusual case, the problem becomes a moving boundary in space and time, and the usual shortcuts stop working.

The Fast Marching Method handles that class of problem by tracking the advancing burn front as a front, rather than marching a grid of cells and watching for a sign change, which is what gives it the ability to work on arbitrary geometry without the mesh artefacts a grid method would leave behind.

The dependency list corroborates the claim. scikit-fmm at 2023.4.2 or later is in both pyproject.toml and requirements.txt, and scikit-image at 0.18.3 or later is there for image processing, which is what the regression visualisation in the grain editor is built on. numpy, scipy and networkx fill out the numerical side, with networkx at 3.1 or later for the graph work and scipy at 1.10.1 or later for the numerical routines.

There is also a performance layer. The setup.py builds a Cython extension called mathlib._find_perimeter_cy from mathlib/_find_perimeter_cy.pyx, with numpy include directories and a macro that opts out of the deprecated numpy API, and the cythonize call uses nthreads set to the CPU count. The README explains that Cython is used to run calculations in C for the more computationally expensive parts of the codebase.

Building the UI and the Cython extension are separate steps

Getting openMotor running from source takes more than a pip install, because two categories of generated file are not committed to the repository.

The first is the UI. openMotor uses Qt Designer to lay out the GUI, which generates .ui files describing the interface, and pyuic6 is used to compile those into Python source that is then included in the program as ordinary source code. Because those autogenerated files are not committed, you must build them with:

$ python setup.py build_ui

and if you change the .ui forms, you have to rebuild with the same command.

The second is the Cython library, which has to be compiled separately for each system:

$ python setup.py build_ext --inplace

or, with uv:

$ uv run python setup.py build_ext --inplace

Again, changes to any .pyx file mean recompiling with the same command.

The environment setup itself has two documented routes. The first uses standard pip and venv:

$ git clone https://github.com/reilleya/openMotor
$ cd openMotor
$ python3 -m venv .venv
$ source .venv/bin/activate
$ pip install -r requirements.txt

The second uses uv, which the README calls the fastest way to set up the development environment:

$ git clone https://github.com/reilleya/openMotor
$ cd openMotor
$ uv sync

Two platform traps are documented as well. If a dependency has no prebuilt wheel for your Python version, the pip route can fail with a scikit-fmm build error ending in Python.h: No such file or directory, and the fix is to install python3-dev or the equivalent. On Windows, DLL load failed while importing _cext points at the Microsoft Visual C++ Redistributable.

Qt6 itself has to be installed, because the PyQt6 bindings are used for the GUI, and the project is developed against Python 3.10.

A .ric file is YAML, and your propellant data lives in platform paths

The data model is simple and worth knowing because it changes what you can do with the files afterwards.

openMotor uses YAML for data storage. Motor files have the extension .ric to differentiate them, but internally they are YAML and can be edited in a text editor if you want to. The recommended MIME type is application/vnd.openmotor+yaml. In other words, a design file is a text document with a custom extension, which means it diffs cleanly in version control and can be scripted.

The remaining user information, propellant data and preferences, is stored in plain YAML files in platform specific application data directories. On Windows that is <AppData>\Local\openMotor, on Mac OS it is /Users/<username>/Library/Application Support/openMotor, and on Linux it is /home/<username>/.local/share/openMotor.

Those paths are handled by platformdirs, which is in the dependency list at 4.2.2 or later, so the app is not hard coding them.

The interop story is where this project meets the rest of the rocketry tooling world. ENG file exporting is supported, which is the format used to hand a motor design to a test stand, and Burnsim importing and exporting is supported, which is the path into a burn simulation tool. If your workflow already runs in one of those, openMotor is designed to slot in rather than to replace it.

The unzip and run route is also documented. You can download the latest version for your system from the releases page, unzip the file and run it, and the project is also packaged for Arch Linux on the AUR as openmotor and for Debian apt as openmotor.

The licence is the reason to look at the code

openMotor is released under the GNU GPL v3 licence, and the README gives the reasoning plainly: the source code is distributed so you can build cool stuff with it, and so you don't have to trust the calculations are being done correctly. It invites you to check for yourself and file an issue ticket if you doubt the results.

That framing is unusual and useful. A ballistics tool is only as good as the model behind it, and a proprietary or closed tool asks you to take the numbers on faith. Here the claim is inspectable, and the project says that having as many eyes on the code as possible is the best way to avoid bugs and the easiest way to get new features added.

The practical implication of GPL v3 for a user is worth stating plainly without giving legal advice. If you use the application as it ships, the licence does not reach your designs or your data. If you distribute a modified version of the program, the copyleft obligations come with it. If you want to reuse the calculation code inside a different program of your own and keep that program closed, GPL v3 is a poor fit, and you would need to talk to the maintainer or find a different approach. The code structure in the repository, with mathlib/ and motorlib/ directories alongside uilib/ and the entry points app.py and main.py, shows a reasonably separated core, which is useful to know either way.

The contributing guidance is also direct. If you have ideas to improve the program or find an error, the README asks you to open an issue ticket for discussion, or file a pull request if possible.

The disclaimer is the most important paragraph in the README

The last section of the README is short and it is not optional reading. It says rocket motors can be dangerous, that you should always verify calculations before testing a motor, and that you should test far enough away from people and structures to avoid damage. It states that the results from the program are provided as an estimate, and come with NO guarantees.

That is the correct framing for the software, and it is also a description of what the tool is for. openMotor is a design aid. It is a way to see the effect of a geometry change quickly, and the grain editor with its regression visualisation exists to cut down on guesswork, not to remove the need for testing.

The dependency list also hints at where the accuracy comes from and where it stops. The calculations are sourced from Sutton's Rocket Propulsion Elements and from Richard Nakka's site, both well known references in the hobby rocketry world, and the software reproduces those models rather than extending them. A design tool that faithfully implements a published model has a clear contract with its user: same model, faster iteration.

The project makes no measured first style claim anywhere, which is a good sign. The README does not attach performance numbers or accuracy guarantees to the simulation, it names its sources, and it tells you the results are estimates. The maintenance picture is consistent with that: v0.6.2 was released on 2026-07-08, v0.6.1 on 2025-09-11 and v0.6.0 on 2025-03-18, and the last push was on 2026-09-26, with the default branch named staging rather than main.

Editorial conclusion

Adopt openMotor if you are designing or iterating on solid rocket motors and want to see the effect of a grain change without leaving your desk, and if you are willing to verify its numbers against the sources it cites. Do not treat its output as a substitute for testing, because the README states the results are an estimate with no guarantees, and it does not replace the safety practices the same README insists on. Before you design with it, read the disclaimer, check the calculation references, Sutton's Rocket Propulsion Elements and Richard Nakka's site, and remember that the licence is GPL v3, so a distributed derivative carries copyleft obligations.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. reilleya/openMotor on GitHub
5. Releases