Task #3419

Task #3418: Infrastructure improvements for modular simulator

Reduce / remove use of legacy t_state objects throughout modular simulator

Added by Pascal Merz 11 months ago. Updated 11 months ago.



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

Revision 93fcbcf9 (diff)
Added by Pascal Merz 5 months ago

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

Revision 3216aceb (diff)
Added by Pascal Merz 5 months ago

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.

Refs #3517
Refs #3422
Refs #3419

Revision 8abc59d8 (diff)
Added by Pascal Merz 5 months ago

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

Refs #3517
Refs #3422
Refs #3419

Revision 00e8ec25 (diff)
Added by Pascal Merz 5 months ago

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

Revision 738eec3f (diff)
Added by Pascal Merz 5 months ago

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

Revision f7ee824f (diff)
Added by Pascal Merz 5 months ago

Make legacy energy elements use CheckpointData

This enables some legacy energy elements to write to CheckpointData,

  • energyhistory_t
  • delta_h_history_t
  • ekinstate_t

Refs #3517
Refs #3422
Refs #3419

Revision ac34f147 (diff)
Added by Pascal Merz 4 months ago

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

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.

Closes #3517
Closes #3422
In partial fulfillment of #3419


#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

Also available in: Atom PDF