This example introduces Tempus::SolutionState, which stores the solution and selected metadata at a particular time. The model is still provided through a Thyra::ModelEvaluator, and the Forward Euler update is still written explicitly in the application code, but the evolving state of the integration is now organized using a core Tempus data structure.
The main purpose of this step is to move from ad hoc scalar bookkeeping to a structured representation of the solution and its integration metadata.
Relative to Example 2: Use ModelEvaluator:
- the primary solution is stored in a Tempus::SolutionState
- metadata such as index, time, timestep size, and status are tracked through that object
- pass/fail logic is expressed through Tempus::Status
- the example begins to follow Tempus conventions for managing solution state during time integration
The central idea behind Tempus::SolutionState is that it should contain the information needed to represent a solution at a specific time in a form suitable for restart, checkpointing, diagnostics, and recovery from failed timesteps.
This example uses only part of the full Tempus::SolutionState capability:
- the solution vector
- selected metadata from Tempus::SolutionStateMetaData
For additional details, see SolutionState Description.
A more detailed explanation of the changes from Example 2: Use ModelEvaluator is given in Transition from Example 2 to Example 3.
The next example extends this idea by introducing Tempus::SolutionHistory to manage multiple solution states.
