Version: dev

integrator

Stable type · Simulation

Tier: stable · Kind: type · Topic: Simulation

JuliaTypeScriptPythonRustGo
not exportedoutside profileIntegratorIntegratoroutside profile

Julia

Julia does not export this type.

TypeScript

Not available in TypeScript. TypeScript is outside the simulation capability profile (Julia, Python, Rust): build an RHS and integrate it; TypeScript and Go are deliberately non-simulating.

Python

class Integrator
Integrator(prob: EsmProblem, *, alg: str = DEFAULT_ALG, abstol: float | None = None, reltol: float | None = None, callback: Any = None, maxiters: int | None = None)
Integrator.t: float  # property
Integrator.u: np.ndarray  # property
Integrator.__getitem__(key: str | int) -> Any
Integrator.step() -> ReturnCode | None
Integrator.solve() -> Solution
Integrator.solution() -> Solution
Integrator.__iter__() -> Integrator

A stepping integrator over a EsmProblem (esm-libraries-spec §2.5.6).

Build one with init , advance it with step (or Integrator.step), and run it out with solve_all . This is the same lifecycle solve performs internally, exposed for callers that need to interleave their own work with the integration — a coupling driver in a host model, an interactive session, a progress UI.

Python has no ! convention, so the spec’s step! / solve! are spelled step / solve_all ; both mutate the integrator, as their Julia twins do. An Integrator is also iterable, yielding (t, u) after each accepted step:

for t, u in init(prob):
    ...

u is the current state vector; __getitem__ indexes it BY NAME (§2.5.7), as a Solution does.

abstol / reltol resolve on the esm-spec §2.2.2 chain — call site, then the document’s solver block, then the binding default — the same chain solve runs, because it belongs to a document being integrated rather than to one entry point. The resolved values are readable back as abstol / reltol.

Members

  • t — The current time.
  • u — The current state vector.
  • __getitem__ — integrator[name] — the named variable’s current value.
  • step — Advance one accepted solver step.
  • solve — Run to completion from wherever the integrator stands, and return the accumulated Solution . This is the spec’s solve!.
  • solution — The trajectory accumulated so far, as a Solution .

Source

Example (integrator)

integ = earthsci_ast.init(prob)
earthsci_ast.step(integ)
assert 0.0 < integ.t < 10.0
assert integ["N"] < 100.0

rest = earthsci_ast.solve_all(integ)
assert rest.retcode == earthsci_ast.ReturnCode.Success
assert rest.t[-1] == 10.0

From docs/api/examples/python/simulate.py

Rust

pub struct Integrator<'a> {
    /* private fields */
}

impl Integrator<'_> { pub fn t(&self) -> f64 }

impl Integrator<'_> { pub fn retcode(&self) -> ReturnCode }

impl Integrator<'_> { pub fn u(&self) -> &HashMap<String, f64> }

impl Integrator<'_> { pub fn step(&mut self) -> Result<StepStatus, SimulateError> }

impl Integrator<'_> { pub fn solve_to_completion(&mut self) -> Result<Solution, SimulateError> }

A stepping integrator (§2.5.6) — the same lifecycle solve performs internally, exposed for callers that need to interleave their own work with the integration: the coupling driver in a host model, an interactive session, a progress UI.

What a “step” is here

Integrator::step advances to the next entry of the output grid, not to the next internal solver step. Each advance runs the configured algorithm over [t_now, t_next] from the current state, exactly the way the array runtime’s segmented provider-refresh driver already advances across a refresh boundary. That means the adaptive controller restarts at every interleave point, so a run stepped in N pieces is not step-for-step identical to the same run solved in one call — it is the same trajectory to tolerance, at some extra cost per boundary. Choose the grid accordingly: coarse when you only need to interleave, fine when you need control.

(diffsol’s solver borrows its OdeSolverProblem, so a EsmProblem-owning integrator that also owns a live solver would be self-referential. Restarting per grid interval is the safe-Rust way to expose the lifecycle, and it is the mechanism already in production here for segmented refresh.)

Source · Rust docs

Go

Not available in Go. Go is outside the simulation capability profile (Julia, Python, Rust): build an RHS and integrate it; TypeScript and Go are deliberately non-simulating.