|
Tempus Version of the Day
Time Integration
|
The primary goal of Example 3: Introduce SolutionState is to move the evolving solution and selected time-integration metadata into Tempus::SolutionState while preserving the same Thyra::ModelEvaluator-based model, the same explicit Forward Euler update, the same simple tabular output, and the same regression-testing workflow used in Example 2: Use ModelEvaluator.
New concepts introduced are:
Tempus::createSolutionStateX()This is the first step in moving from application-local scalar bookkeeping to a Tempus-managed representation of the evolving solution state. That organization becomes increasingly important in later examples that introduce solution histories, steppers, and integrators.


The code excerpts below highlight the main changes needed to move from separate scalar bookkeeping variables to a Tempus::SolutionState.
Create a SolutionState. The current solution is now stored in a Tempus::SolutionState together with selected metadata.
Before
After
This replaces several scalar bookkeeping variables with a single Tempus::SolutionState object.
Use metadata from the solution state. The loop condition is now expressed in terms of the solution state's index, time, and status.
Before
After
Record step success or failure through the solution state. Step acceptance and failure are now reflected in the solution status and metadata.
Before
After
In the updated example, the final tutorial success condition is formed after the time loop by combining:
SolutionState has status PASSED, andA more detailed comparison can be made by diffing:
examples/02_Use_ModelEvaluator/02_Use_ModelEvaluator.cppexamples/03_Intro_SolutionState/03_Intro_SolutionState.cppFrom the packages/tempus directory, a focused comparison of the main time-integration logic between these two examples can be generated locally in bash or zsh with:
This ignores leading header lines (e.g., #include statements and Doxygen comments) and trailing regression-testing lines.