Task #3419
Task #3418: Infrastructure improvements for modular simulator
Reduce / remove use of legacy t_state objects throughout modular simulator
Description
In the first implementation of the modular simulator, we have been using a bunch of t_state objects to interface with legacy functionality. We want to move away from the legacy t_state object to allow for a purely modular implementation of functionality. Further, the number of allocated objects could hurt performance. Interfaces to legacy functionality include
- Checkpoint reading and writing
- Domain decomposition
- Trajectory writing (position, velocity, boxes)
Associated revisions
Introduce CheckpointData
CheckpointData exposes methods to read and write scalar values,
ArrayRefs, and tensors. It also allows to create a "sub-object" of
type CheckpointData which allows to have more complex members
implement their own checkpointing routines. All methods are templated
on the chosen operation, CheckpointDataOperation::Read or
CheckpointDataOperation::Write, allowing clients to use the same code
to read and write to checkpoint. Type traits and constness are used to
catch as many errors as possible at compile time. CheckpointData uses
a KV-tree to store the data internally. This is however never exposed
to the client. Having this abstraction layer gives freedom to change
the internal implementation in the future.
All CheckpointData objects are owned by a ReadCheckpointDataHolder or
WriteCheckpointDataHolder. These holder classes own the internal
KV-tree, and offer deserialize(ISerializer*) and
serialize(ISerializer*) functions, respectively, which allow to read
from / write to file. This separation clearly defines ownership and
separates the interface aimed at file IO from the interface aimed at
objects reading/writing checkpoints.
Prepare legacy checkpoint for modular simulator checkpointing
- Extend legacy checkpointing functionality to accept a CheckpointDataHolder
for reading and writing - Bump checkpoint version to reflect above change
- Turn off some checkpoint sanity checks when using modular simulator
- Pass CheckpointDataHolder object into checkpoint reading in runner, and
move this object in SimulatorBuilder and then ModularSimulator for element
setup
Make EnergyOutput::addDataAtEnergyStep independent of t_state
EnergyOutput::addDataAtEnergyStep took a pointer to a full t_state,
although it only uses a small part of the object. This makes the
dependencies explicit. This is a necessary step to make EnergyData
independent of t_state.
Refs #3419
Remove dependency of EnergyData on t_state
EnergyData used a t_state object to calculate the conserved energy.
This responsibility is now given to the respective temperature /
pressure control algorithms. This allows to remove the dependency
of EnergyData on t_state.
This also introduces the conserved energy as a test quantity in the
tests comparing legacy and modular simulator code paths.
Refs #3419
Implement modular checkpointing
Using the CheckpointData format introduced in a parent commit, this
rewrites checkpointing for the modular simulator to completely use
the new format.
The CheckpointHelper is now passing a CheckpointData object to its
clients (instead of a legacy t_state object). Clients are now stored
in a map, as they are identified by their unique key to be able to
assign the correct CheckpointData sub-objects at reading and writing.
If checkpoint reading occured, the newly introduced
CheckpointHelperBuilder receives the CheckpointData object read at the
runner level from the ModularSimulator. It then initializes its clients
with their respective, read-only CheckpointData subobjects.
The ICheckpointHelperClient interface is adapted to reflect above
changes.
The ModularSimulatorAlgorithmBuilder is slightly simplified thanks to
to the introduction of a proper builder for the CheckpointHelper.
The ComputeGlobalsElement is simplified, as it is not required to know
about the needs of communication of the EnergyData object which
depends on checkpoint reading.
Finally, all elements which are checkpoint clients are updated to
implement the new design. Note that they all introduce their own
checkpoint versioning, as the data being checkpointed is opaque to the
checkpointing infrastructure.
History
#1 Updated by Pascal Merz 11 months ago
- Tracker changed from Feature to Task
#2 Updated by Pascal Merz 11 months ago
- Private changed from Yes to No
Make dd_collect_vec independent of t_state
This removes the explicit dependency of dd_collect_vec on the
t_state object.
This is a prerequisite for !440.
Refs #3422 #3419