RHEPLICANT¶

A REPLICa of an ANTenna — a JAX model of a radio telescope, run as a digital twin. Built for RHINO, a horn antenna measuring the 21 cm global signal, and domain-agnostic underneath: horns, dipoles and dishes alike.

A RHEPLICANT twin is one pure function from sky and instrument parameters to raw data. Because every stage is differentiable, the same twin that simulates an observation also calibrates it: gradients, Bayesian posteriors, Fisher forecasts, and neural surrogates all run through the instrument model itself.

Four things it is built to do¶

1 · Forward modelling

Simulate what any stage of the experiment would produce — a sky, a receiver output, a processed product. Where you stop is a property of the graph.

2 · Bayesian inference

Read the same twin backwards. Free any subset of what it contains; the noise model is the likelihood; the engine follows from the model’s structure.

3 · Neural surrogates

Replace an expensive stage with a trained network and leave the graph’s shape untouched — or amortize the posterior itself.

4 · Streaming evidence

Keep a campaign after its recordings are archived: compress each night to a fixed-size likelihood factor, then discard the data.

None of the four is a separate mode. They all read the same twin object, which is what makes the calibration you fit the simulator you trust.

Two nouns¶

_images/tour-operator-light.svg — An operator takes the whole scientific context and returns it one step later.¶

_images/tour-operator-dark.svg — An operator takes the whole scientific context and returns it one step later.¶

State: The complete scientific context — data, coordinates, environment, randomness, metadata. It is an organisation of references to buffers, not the buffers themselves, so a derived state allocates the shell and nothing else: 48 bytes, with a 16 MB array shared rather than copied. JAX arrays are immutable, which is what makes sharing safe.
Operator: One step, State in and State out. Sky models, instrument effects, calibration, filtering and neural networks are all the same kind of thing, and each carries its own physical parameters as differentiable leaves.

state.data always references what the instrument has produced so far. For example: the sky engine produces the (n_time, n_freq) antenna temperature, the antenna’s ohmic loss produces that array after loss, the receiver produces a system temperature. Nothing is written in place — each stage hands back a new State whose data points at its own result, while the fields it did not touch go on pointing where they already did.

The sky map itself is not in state.data — it is a parameter of the sky model, differentiable like every other, which is why a map can be inferred rather than merely assumed.

Three ways to join them — and you rarely write any¶

Structure	Combinator	Physics it expresses
Cascade	`Pipeline`	sequential effects: each stage transforms what the last produced
Sum	`SumOperator`	independent contributions that add into one signal
Switch	`SelectOperator`	alternative paths, one selected per time sample

You normally write none of them. Declare the operators you want and assemble reads the canonical signal path to decide what joins to what — so the composition is a consequence of the physics you declared, not something you wrote out. Reach for the three combinators directly only when you are building a structure the template does not describe.

A canonical signal path is a template saying which operators exist and which structure joins them: node kinds source, transform, junction and selector map one-to-one onto “creates data”, cascade, sum and switch. You provide a set of operators, and assemble folds them into exactly those three combinators.

The template shipped as the default, RADIO_GRAPH, is RHINO’s structure: a single-antenna, switched-load, drift-scanning horn. It is a default, not the framework — the machinery underneath knows nothing about radio astronomy, and another instrument is another template registered the same way.

Where to start¶

You want to…	Start here
install it	Install — limTOD resolves from PyPI; `uv sync` and `uv run` do not work here, so use `uv venv` + `uv pip install`
understand the whole thing in one sitting	The guided tour — one worked example, simulated then inferred
simulate an instrument	The canonical signal path, then the operator catalog
write or run a YAML configuration	Configuration — what a document contains and what v1 covers. A first document, start to finish, is the tutorial; the command line is what validates and runs it
edit a YAML configuration in a browser	Configuration workbench — Model, Config, Execute and Results over exact YAML, plus install and trusted-server boundaries
turn a RHINO recording into a `State`	Ingestion — every other page starts from a `State` that already exists; this is where one comes from
see one instrument end to end	From the sky to the receiver
fit or sample parameters	Tutorial: an exact posterior or Tutorial: a gradient posterior first, then Inference for the rules they cite
keep a campaign after the recordings are archived	Evidence — accumulate likelihood factors, discard the data
run something and read its output	Examples — fifteen scripts, with measured wall clocks
look something up	The API reference, contracts between stages, design decisions

Concepts

Configuration

Configuration documents

Inference