SpeedyWeather.jl: an atmospheric model you can edit while it runs

A climate model built to be taken apart

SpeedyWeather.jl is described as a global atmospheric model developed as a research playground with an everything-flexible attitude as long as it is speedy. Technically it is a climate model with simple yet interactive representations of ocean, land and sea-ice.

The framing is unusual and worth reading carefully, because it tells you what the project is optimising for. The readme says it is fast on CPU and GPU, easy to use and easy to extend, and that the aim is to make atmospheric modelling an interactive experience in the terminal, in a notebook, or conventionally through scripts.

The vision section explains why another model exists at all. The stated belief is that most currently available models are stiff, difficult to use and extend, and therefore slow down research, whereas modern code in a modern language would not have to be. Julia was chosen because it combines the best of Fortran and Python: within a single language you can interactively run the model on large GPUs and also extend it, inspect its components, evaluate individual terms of the equations, and analyse and visualise output on the fly.

There is a scope statement, and it is unambiguous. The project does not necessarily aim to be an atmospheric model for production-ready weather forecasting, at least not at the cost of interactivity, ease of use or extensibility. It is built with a climate application scope in mind and with a focus on research and education.

So the audience is a person who wants to run a global atmosphere, change something in it and see what happens, rather than a forecasting centre that needs a dependable prediction on Tuesday.

The repository is a monorepo of several packages: SpeedyWeather/ for the model, SpeedyTransforms/ for the spherical harmonics transforms, RingGrids/ for grid generation, LowerTriangularArrays/ for the spectral storage layout, and SpeedyWeatherInternals/. The homepage is speedyweather.github.io, with the full documentation hosted separately at SpeedyWeatherDocumentation.

The physics you can exchange

The first block of the feature list covers dynamics and physics, and the structure of that list is the argument for the design.

You can choose between different physical equations: barotropic vorticity, shallow water, and primitive equations with and without humidity. These are not variations of one solver; they are different levels of physical complexity, and picking between them is the first knob a user turns.

Particle and tracer advection is supported in 2D and 3D for all of the equations, so you can carry a passive tracer through the flow. Physics parameterizations for convection, precipitation, boundary layer and radiation are included, and the readme emphasises that parameterizations can be easily changed and customised using modular fused GPU kernels. That last clause is the interesting one, because it means the same source-level interface is used whether the kernel runs on a CPU or on a GPU.

The lower boundary is modelled too. There is a slab ocean and a thermodynamic sea ice model, and a 2-layer land bucket model carrying soil temperature, moisture, vegetation and snow. Combined with the equation choice, that gives a model whose surface forcing is simplified but present, which is what makes the what-if scenarios in the next point possible.

The readme advertises various more or less realistic planets and what-if scenarios by easily modifying initial and boundary conditions. Combined with the interactivity, this is the characteristic use case: take the model, change a boundary condition, run it for a few simulated days on a laptop, and look at what the atmosphere does.

What the model does not attempt is documented in the vision section rather than hidden. New parameterizations of atmospheric processes can be very complicated and computationally expensive, and the project is happy to provide a general interface to support such extensions, which can even be developed as independent projects in separate repositories thanks to the modular structure. But because the philosophy is easy and fast by default, those complex extensions are not used by default.

Grids, arithmetics and the GPU story

The numerics block is where the speed claim gets its substance, and it is worth separating what is a choice from what is a claim.

Grids are plural in a specific way. You get full and octahedral grids, in both Gaussian and Clenshaw-Curtis variants, plus HEALPix and OctaHEALPix. Spectral resolutions run from T16 to T1024, matched flexibly with grids from roughly 800 km down to 10 km. The separate RingGrids package in the repository is the grid generation machinery, and LowerTriangularArrays is the storage layout for spectral coefficients, which is where a good deal of the performance comes from.

Arithmetic precision is also a choice. Float32 is the default, Float64 is available, and BFloat16 with stochastic rounding is described as experimental. The presence of an experimental low-precision path is a reasonable thing to want for large ensembles, and the stochastic rounding is there because naive truncation in low precision accumulates bias in long integrations.

The performance claims are stated as ranges rather than points. It is fast on single CPUs on x86 and arm for laptop prototyping, live demos and education, and GPU acceleration is typically 5 to 50 times faster on Nvidia and AMD GPUs, with Metal support for Apple Silicon. The separate SpeedyTransforms.jl package is described as a very fast and flexible spherical harmonics transform library for CPU and GPU, and it is one of the four CI workflows in the repository, which tells you it is maintained as its own project.

Automatic differentiation through Enzyme.jl is available for sensitivity analysis, parameter calibration and machine-learning-physics hybrid modelling, and the readme limits it to Julia 1.10 and 1.11 currently. That is a real constraint rather than a caveat: an adjoint model is the standard tool for parameter estimation in atmospheric science, and pinning it to two Julia versions means your choice of Julia version is partly dictated by whether you need it.

CI is split across the main package, SpeedyTransforms, RingGrids, LowerTriangularArrays, SpeedyWeatherInternals, Enzyme and a Reactant correctness workflow, which mirrors the monorepo structure.

Components, arguments and callbacks as the extension points

The user interface block lists four things, and together they explain how a user actually changes the model.

Models are constructed from their components, with non-defaults passed on as an argument. That is a plain and important design decision: instead of editing configuration files or subclassing, you assemble a model from parts and hand it the non-default parts. A researcher who wants one specific parameterization swapped passes it in.

New model components, including parameterizations, can be externally defined, which is what makes the separate-repository extension mentioned earlier possible. A parameterization that is too complex to live in the main package can live in its own repository and be plugged in.

Callbacks are the mechanism for injecting code after every time step. The readme gives three examples: custom output, event handling, and changing the model while it is running. That third one is unusual and is the most interesting feature in the list, because it means a run is not a closed loop. You can watch the state evolve and intervene, which turns a simulation into an experiment you steer.

Interactivity is the claim that follows from all of this: the model runs in a notebook or in the REPL as well as from scripts. Combined with the Julia choice, this is the argument the vision section makes, that you can evaluate individual terms of the equations rather than only the integrated fields.

Visualisation is included rather than bolted on. The readme names 2D, 3D and interactive visualisation with zoom and rotate, powered by Makie, Browzarr or Octant. Interactive visualisation of a global field is a genuine research convenience, and having three backends available means the choice is not forced.

The readme ends the philosophy with the word minimal: with minimal code redundancies, and Julia compiles to these choices just-in-time, so a different set of choices is a different compiled method rather than a configuration load at runtime.

Installing it, and what the readme does not tell you

The readme does not contain installation instructions. It points to the documentation instead, at https://speedyweather.github.io/SpeedyWeatherDocumentation/dev for the development documentation, with a badge linking to the stable version of the same site. For a Julia package, the usual route is the Julia package manager, and the package name follows the repository name, but the readme does not spell out the add command, the Julia version required for the base package, or any optional dependency groups, so those details have to come from the documentation site rather than from here.

What the readme does give is the list of separate projects to expect. SpeedyWeather.jl is the model itself. SpeedyTransforms.jl is the spherical harmonics transform library for CPU and GPU. RingGrids.jl is the grid package. LowerTriangularArrays.jl is the array storage package. SpeedyWeatherInternals is a supporting package inside the same repository.

Those are not incidental. A Julia package that depends on four sibling packages is a monorepo where the pieces are versioned together, and the fact that each has its own CI workflow means a change in the transform library is tested independently of the model. That is the right structure for a numerical codebase where the linear algebra is the hard part.

The repository also has a buildkite directory alongside the GitHub Actions workflows, which suggests continuous integration runs on more than one platform, and a CITATION.cff file alongside a Zenodo DOI badge, so the project is set up to be cited. The CHANGELOG.md is at the root, and there is a CLAUDE.md, which is a file for instructions aimed at coding assistants working in the repository.

The license is EUPL-1.2, the European Union Public License. That is worth pausing on for anyone planning to use the code commercially outside the EU framework, because it is a copyleft licence with its own terms and it is not one of the MIT or Apache licences most Julia packages carry.

Where SpeedyWeather.jl is the wrong tool

The first limitation is stated by the project itself and should not be softened. The readme says the project does not necessarily aim to be an atmospheric model for production-ready weather forecasting, at least not at the cost of interactivity, ease of use or extensibility. A team that needs a forecast that is good enough to act on needs something else, and the simplified ocean, land and sea-ice representations plus the choice of a general rather than a specific physics package are where that gap lives.

The second is the scope of the physics. Convection, precipitation, boundary layer and radiation are all parameterizations, and parameterizations are approximations whose behaviour depends on the resolution and configuration you give them. A model designed for interactive exploration on a laptop is making different trade-offs from a model tuned for a specific resolution, and the readme says as much when it lists the goal of defaults that are physically accurate yet fast enough to run on a laptop.

The third is the automatic differentiation constraint. Enzyme support is limited to Julia 1.10 and 1.11, so a project on a newer Julia has no adjoint capability from this package as the readme describes it. For a group doing parameter calibration or hybrid modelling, that is a binding constraint on the whole toolchain.

The fourth is that the four-sibling-package structure carries a real integration cost. Working on SpeedyTransforms.jl or LowerTriangularArrays.jl means working inside a numerical codebase where the correctness of the linear algebra is the whole point, and where the CI configuration, the code style badge and the project boundaries all have to be respected. Speeding this up is exactly what the project wants, but it means the hot path is Julia code written by people who know spectral transforms, not a wrapper you can call.

The fifth is the licence. EUPL-1.2 is a copyleft licence with obligations that differ from MIT or Apache, and for a scientific codebase that people fork and extend, the terms matter more than they would for a small utility. The readme also asks for contributions and discusses a hierarchy of models spanning multiple levels of process and computational complexity, which describes an active research programme rather than a finished product.

Editorial conclusion

SpeedyWeather.jl fits an atmospheric science group or a student who needs to run a global model in minutes, change one physical term and see the result, since the model is built from swappable components with callbacks that let you intervene after every time step, and the readme is explicit that production forecasting is not the goal. It is the wrong choice if you need forecast skill or an operational pipeline, and it is the wrong choice if you need a model with a maintained data assimilation system. Before adopting it, check the documentation site linked from the readme for the installation path, since the readme itself gives none, confirm the Julia version your extensions need, and note that the licence is EUPL-1.2, which carries copyleft obligations of its own, with the last push on 2026-10-20 and v0.23.0 released on 2026-10-08.

Frequently asked questions

Official sources

1. License: EUPL-1.2
2. Project website
3. README
4. Releases
5. SpeedyWeather/SpeedyWeather.jl on GitHub