FixedStepper

Defined in: fixed_step.rs:208

pub struct FixedStepper\<'a, I: ?[Sized](https://doc.rust-lang.org/std/marker/trait.Sized.html), S: [DynamicalSystem](../../traits/dynamicalsystem/)\>

Advances a fixed-step solver towards successive target times.

Created via Integrator::stepper. Holds the state and the time it belongs to, so a caller that splits its span — at output intervals, or at the discontinuities a Segments(crate::Segments) walk finds — asks for one target after another and reads the state back between them. The adaptive solvers offer the same three calls (stepper(crate::DormandPrince::stepper), from_checked_state(Self::from_checked_state), advance_to(Self::advance_to)), so a loop that chooses its solver at run time writes one shape for all of them.

Each advance_to counts its steps from the time the stepper is at when it is called, and lands its last step on the target. Two calls covering [0, 1] and [1, 2] therefore step through different times than one call covering [0, 2]: splitting a span is a choice about where the solver is made to land, not a way to reproduce the same trajectory in pieces.

Methods

from_checked_state()

fn from_checked_state(self) -> Self

Skip the event check on the state this stepper starts from.

For a segment that continues where the previous one ended: the caller has asked its predicate about that state already. Checks after accepted steps are unaffected.

---

advance_to()

fn advance_to<F, E, B>(&mut self, t_target: f64, callback: F, event_check: E) -> [Result<AdvanceOutcome<B>, IntegrationError>](https://doc.rust-lang.org/std/result/enum.Result.html) where F: FnMut(f64, &::State), E: [Fn(f64, &::State) -> ControlFlow<B>](https://doc.rust-lang.org/std/ops/function/trait.Fn.html)

Advance to t_target in steps of the configured dt.

• For a target that advances, event_check runs first on the state the stepper currently holds, before any step. A level-triggered event can already hold there, and reporting it after a step would name a state the predicate itself rejects. Terminating there leaves the stepper where it was and calls no callback, since the callback reports accepted steps and none was taken. A target the stepper has already reached takes no step, so it asks nothing and reports Reached.
• Each step calls callback(t, &state), then event_check(t, &state); Break(reason) reports Event { reason }.
• A step whose result is not finite fails with IntegrationError::NonFiniteState without storing that result: the state after such a step is not a trajectory, and the stepper stays on the last state it accepted.

---

advance_to_roots()

fn advance_to_roots<F, E, B>(&mut self, t_target: f64, callback: F, event_check: E, roots: &mut RootSet<’_, ::State>) -> [Result<RootOutcome<B>, IntegrationError>](https://doc.rust-lang.org/std/result/enum.Result.html) where F: FnMut(f64, &::State), E: [Fn(f64, &::State) -> ControlFlow<B>](https://doc.rust-lang.org/std/ops/function/trait.Fn.html)

Advance to t_target in steps of the configured dt, stopping at the first boundary a RootEvent(crate::RootEvent) in roots describes.

Each step is examined on its raw candidate, before the projection: if an event changed sign over it, bisection re-steps from the step’s own start until the bracket is narrower than RootSearch::t_tolerance(crate::RootSearch::t_tolerance), and the state at the boundary is what the stepper commits. Neither the trials nor the state a root stopped at reach the callback: a boundary state is not final until the caller has handled the root, so it reads that one from the stepper.

Reaching a boundary ends the walk whether or not the event is terminal: terminal in the outcome says what the events asked for, and a caller that resumes takes its next step from the boundary. The guards in roots are what keep that step from reporting the departure as a new crossing, so the same set has to be passed back.

event_check is the one advance_to(Self::advance_to) takes, and it is asked in the same places: about the state the walk starts from, and about each ordinary step it commits. A boundary is not one of those places — that state is the caller’s to handle — so a caller whose condition can hold there asks it again once it has.

A value that is already zero at the state the stepper starts from is the “before” of the first step, and that step reports a root as soon as the value leaves zero toward the side the event counts. What stops a resumption from reporting the root it is standing on is RootGuard(crate::RootGuard), which the same roots carries: the step starting at that root’s own time does not report that event again.

---

state()

fn state(&self) -> &::State

The state of the last accepted step.

---

t()

fn t(&self) -> f64

The time the stepper has reached.

---

into_state()

fn into_state(self) -> ::State

Take the state of the last accepted step.

---