Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

Architecture & design

San Diego State University

This section documents why progenax is shaped the way it is. Where the theory section covers what the package computes, this section covers what the package is as software: the JAX-native patterns, the protocol-based composition, the units policy, the conventions every contributor needs to know, and the historical decisions that shaped the current API.

Map of the section

Chapter

Scope

JAX-native philosophy

Why no numpy or scipy in core code, why jax.lax.scan instead of Python loops, why equinox modules for state

Three-brick state pattern

The State / SystemParams / ParticleSystem decomposition that makes differentiable simulations possible

Protocol-based composition

SpatialProfile, VelocityDF, IMFProtocol — runtime-checkable protocols enabling mix-and-match composition

Differentiability rules

Patterns that preserve gradient flow; antipatterns that break it

Units policy

Explicit units / G parameters, DEFAULT_UNITS per package, no global context managers

Virial Q convention (Q = T/|V|)

Why Qvir=T/VQ_{\mathrm{vir}} = T/|V| (= 0.5 at equilibrium) — and not the factor-of-2 alternatives

JAX-native CW04 substructure Q parameter

The Cartwright & Whitworth (2004) substructure Q parameter: kNN approximation + scipy reference

Contributor guide

How to add a new spatial profile, IMF, integrator, or validation suite to progenax

IC redesign history

The 2026-02-12 IC redesign that produced the current protocol-based architecture

What this section is not

These chapters describe implementation choices — the patterns that let progenax be JAX-native, differentiable, and composable. They do not describe the underlying physics (that is the theory section) or the per-symbol API (that is the API reference reference). A chapter belongs in this section if its content is invariant under swapping the implemented physics: “use jax.lax.scan not while-loops” is true for any progenax module, while “the King profile satisfies 2T+V=02T + V = 0 at equilibrium” is specific to King.

Reading paths

For new contributors: read JAX-native philosophyDifferentiability rulesProtocol-based compositionContributor guide in that order. The first two establish the constraints; the third shows the composition pattern; the fourth walks through adding new modules.

For users coming from McLuster or NBODY6: read Units policy and Virial Q convention (Q = T/|V|) first — these are the convention-mismatches most likely to bite.

For paper-writers wanting to cite progenax’s design choices: Three-brick state pattern and IC redesign history are the chapters most worth referencing.

How architecture and theory interact

Some progenax decisions sit on the boundary between architecture and physics. The convention is:

When in doubt about which section a topic belongs in, the test is: “would this discussion still be true if we ported progenax to PyTorch or NumPy?” If yes → theory. If no → architecture.

References

The JAX programming model is documented at the JAX docs. Equinox is Kidger & Garcia (2021). The broader JAX ecosystem progenax sits in (jaxstro, gravax, stellax) is described in the jaxstro README.

References
  1. Cartwright, A., & Whitworth, A. P. (2004). The statistical analysis of star clusters. Monthly Notices of the Royal Astronomical Society, 348, 589–598. 10.1111/j.1365-2966.2004.07360.x
  2. Kidger, P., & Garcia, C. (2021). Equinox: Neural networks in JAX via callable PyTrees. 10.5281/zenodo.5648586