RocketPy simulates a rocket in six degrees of freedom, with the mass changing

Six degrees of freedom, and a rocket that gets lighter

The library's claim is a complete 6 degrees of freedom simulation of a rocket's flight trajectory, including high-fidelity variable mass effects as well as descent under parachutes. The variable mass is the part that distinguishes it from a simple vertical integrator, because a rocket burning propellant is changing its mass, its centre of mass and its inertia as it flies, and treating the vehicle as a constant mass body gets the apogee wrong. The design goal as stated in the README is to allow for a complete simulation including those effects, with the solver described as nonlinear 6 degrees of freedom, rigorously treating the mass variation effects, solved efficiently using LSODA with adjustable error tolerances, and optimised for fast performance. The audience is three groups at once, enthusiasts who want to know what their motor will do, researchers who need the trajectory rather than a number, and engineers doing design studies.

The solver choice and the tolerance knob

The mention of LSODA in the feature list is more informative than it looks. LSODA is an adaptive solver that switches between a stiff and a non-stiff algorithm depending on the problem, which matters for a rocket trajectory because the equations change character sharply at ignition, at rail departure, at apogee and at the moment a parachute opens, and a fixed-step integrator either becomes slow or becomes wrong at those points. The adjustable error tolerances are the second half of the design, because a Monte Carlo run over a thousand dispersion cases cannot afford a very tight tolerance, while a single design study can afford one and should use it. The feature list also notes that the implementation is highly optimised for fast performance, and the Makefile has a separate pytest-slow target, with the tests marked as slow, which is the tell that the slow tests are the full trajectories rather than the algebra.

Weather is a first-class input

The second feature area is weather, and the detail is that this is not a constant wind speed. The library supports the International Standard Atmosphere of 1976, custom atmospheric profiles and Wyoming soundings, and it can import weather forecasts, reanalysis data and ensembles for realistic scenarios. The requirement list in the repository explains why, with netCDF4 for the meteorological data, requests for the download of forecasts, pytz for the time handling, simplekml for the output and numpy, scipy and matplotlib for the numerics and the plots. The ensembles point is the sophisticated one, because an ensemble is what turns a single simulated trajectory into a distribution, and that is what a dispersion analysis needs before you decide whether a flight is safe on a marginal day.

Parachutes with trigger functions, and sensors that lie a little

The parachute model is the fourth feature and it is the one that shows the project's real audience. Parachutes with external trigger functions means you write a function that decides when a parachute opens, which covers the cases a fixed altitude trigger cannot, such as a drogue deployed by a timer and a main deployed by altitude, or a test drop from a helicopter at a set height. The stated purpose is to test the exact code that will fly, and the second capability is sensor data augmentation with noise, so a parachute simulation includes the jitter of a real barometer and the deployment is not a clean step function. For a library aimed at people who fly, that is the difference between a plot and a prediction, and it is also why the library can handle non-standard flights such as a parachute drop test from a helicopter.

Solid, hybrid and liquid motors, and where the numbers come from

The motor models cover the three kinds of motor a high-power rocket uses. The properties, burn rate and mass variation, are taken from the thrust curve, and custom rocket tanks can be defined based on flux data, with support for CSV and ENG file formats, which is what makes it possible to model a motor that is not in any published data set. The fluid side is what makes a motor model more than a table, since a liquid motor's thrust depends on the tank pressure at that moment, and the mass of the propellant leaving the tank changes the vehicle. The feature list also claims the ability to define custom rocket tanks based on flux data, which is the interesting phrase, because it means the library lets you model the propellant behaviour rather than read it off a datasheet.

The optional extras are the analysis features

The packaging metadata shows the dependency groups, and they read as a menu of analyses rather than as conveniences. The env-analysis group brings windrose, timezonefinder, jsonpickle, ipython and ipywidgets, which is the environment analysis tooling for working with weather data. The monte-carlo group brings imageio, multiprocess, statsmodels, prettytable and contextily, which is the dispersion and global sensitivity analysis machinery, and the Monte Carlo feature in the README says it can conduct dispersion analysis and global sensitivity analysis, which is a stronger claim than running the same trajectory many times. The animation group brings pyvista and imageio, for producing flight animations from the simulated trajectory. The core requirements are numpy, scipy, matplotlib, netCDF4, requests, pytz, simplekml and dill, and the package requires Python 3.10 or above.

The validation table is the reason to believe the numbers

The strongest part of the README is the validation table, which compares RocketPy's output with measured flight data. The Bella Lui Kaltbrumn mission gives an apogee altitude of 461.03 m against a measured 458.97 m, a 0.45 percent relative error, an apogee time of 10.61 s against 10.56 s, a 0.47 percent error, and a maximum velocity of 86.18 m/s against 90.00 m/s, a -4.24 percent error. The NDRT launch vehicle gives an apogee altitude of 1,310.44 m against 1,320.37 m, a -0.75 percent error, an apogee time of 16.77 s against 17.10 s, a -1.90 percent error, and a maximum velocity of 172.86 m/s against 168.95 m/s, a 2.31 percent error. The flight data and rocket parameters were provided by the EPFL Rocket Team and the Notre Dame Rocket Team, and the project points at a research article in the Journal of Aerospace Engineering through a DOI in the header, so the validation is peer reviewed rather than self asserted.

Where a simulation stops being evidence

The limits are the ones a trajectory simulation always has, and this project is more honest about them than most. The first is that a validated simulation is still a simulation, and a 4 percent error in maximum velocity is a good result for a design tool and a poor foundation for a flight decision. The second is the aerodynamic model, since the Barrowman equations for lift coefficients are optional and drag coefficients are imported from other sources such as CFD simulations, which means a result is only as good as the coefficients you supply, and a beginner with no coefficients is simulating a shape rather than a vehicle. The third is the scope, since this is a trajectory library and not a design tool, so the optimisation feature works on a model you have already parameterised rather than on a vehicle you have not yet designed. The practical way to use it is the way the project demonstrates, comparing a prediction with a measured flight and reading the difference, and the documentation's Flight Examples page collects the validated cases for exactly that reason.

Editorial conclusion

RocketPy is worth adopting if you are designing or analysing a high-power rocket and want to iterate on the design in a script rather than by flying it, because the whole trajectory is a Python object graph you can change and re-run, and the published validation gives you a reason to trust the output. It is the wrong tool if you need a design tool with a graphical interface rather than a library, and it is the wrong tool for flight certification, since a simulation validated to a few tenths of a percent on apogee is still a simulation. Before you trust its numbers, read the validation table and pick the mission whose conditions resemble yours, and remember the model assumes a massless aerodynamic model unless you give it coefficients, since the Barrowman equations are optional and drag coefficients from CFD are an import.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. RocketPy-Team/RocketPy on GitHub