integrator
Stable type · Simulation
Tier: stable · Kind: type · Topic: Simulation
| Julia | TypeScript | Python | Rust | Go |
|---|---|---|---|---|
| not exported | outside profile | Integrator | Integrator | outside 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 accumulatedSolution. This is the spec’ssolve!.solution— The trajectory accumulated so far, as aSolution.
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
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.)
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.