FixedStepper
Defined in: fixed_step.rs:207
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
Section titled “Methods”from_checked_state()
Section titled “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()
Section titled “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_checkruns 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 reportsReached. - Each step calls
callback(t, &state), thenevent_check(t, &state);Break(reason)reportsEvent { reason }. - A step whose result is not finite fails with
IntegrationError::NonFiniteStatewithout storing that result: the state after such a step is not a trajectory, and the stepper stays on the last state it accepted.
state()
Section titled “state()”fn state(&self) -> &
::State
The state of the last accepted step.
fn t(&self) -> f64
The time the stepper has reached.
into_state()
Section titled “into_state()”fn into_state(self) ->
::State
Take the state of the last accepted step.