Project

General

Profile

Task #3437

Task #3418: Infrastructure improvements for modular simulator

Use builders to prepare modules

Added by Pascal Merz 5 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
mdrun
Difficulty:
uncategorized
Close

Description

The current setup of modular simulator is more complicated as necessary, as it mixes constructing the elements, satisfying their mutual connections (registering clients to signallers and functionality providers), and their arrangement (which defines the exact integration algorithm being used).

The approach would become significantly easier to understand, maintain and extend if the responsibility of preparing the elements would be delegated to builder object. This would encapsulate the implementation details of construction and inter-connection of elements, helping to more clearly expose the arrangement of modules.

Associated revisions

Revision 377cd00d (diff)
Added by Pascal Merz about 2 months ago

Modular simulator: Separate trajectory element and signaller

The trajectory element implemented both the ISimulatorElement and
the ISignaller interface. It was both signalling its clients that a
trajectory writing step was about to occur during task list creation,
and actually performing trajectory writing during the simulation.

In general, the tasks of signallers and elements, their call site in
the code, and their build and ownership procedures are all significantly
different. The dual nature of the trajectory element makes this
differentiation less clear, and requires some workarounds. Additionally,
separating the trajectory element in separate element and a signaller
requires no changes on client side, since all clients of the trajectory
element with integrated signaller already implemented two interfaces,
ITrajectorySignallerClient and ITrajectoryWriterClient.

The current change hence splits the current trajectory element into
a pure element and a pure signaller. This will make subsequent changes,
especially the introduction of a builder approach much easier. It also
removes support for combined elements and signallers: It renames the setup
method of the ISignaller interface from `signallerSetup` to `setup`, as
this differentiation was only used for classes implementing both element
and signaller interfaces. It also simplifies the handling of signallers
in ModularSimulator, as having a separate ownership and call list is not
needed anymore.

Refs #3437

Revision 1b7049ad (diff)
Added by Pascal Merz about 1 month ago

Separate ModularSimulator and ModularSimulatorAlgorithm

This introduces the ModularSimulatorAlgorithm, which takes over some
responsibilities from ModularSimulator. The ModularSimulatorAlgorithm
owns the elements, and allows ModularSimulator to run a simulation
following the prescribed algorithm. This change is only refactoring -
no functionality is added or removed, but separating the algorithm and
its builder from the simulator allows to develop the two independently.

The ModularSimulatorAlgorithm is built by ModularSimulatorAlgorithmBuilder.
In a first approach, ModularSimulatorAlgorithmBuilder creates an appropriate
algorithm based on the input passed from the runner level (md or md-vv, thermo-
and / or barostat, constraining, FEP, etc).

Eventually, the builder will not need to know about all possible algorithms,
but offer an interface for its user to creat algorithms. Currently, the only
planned user of the ModularSimulatorAlgorithm is the ModularSimulator itself.
In view of this, two "hacks" were used to reduce unnecessary line changes
to simplify review: The builder mirrors all protected members of ISimulator,
and some of its member function implementations were left in modularsimulator.cpp.
Note that both of these "hacks" will disappear in subsequent changes.

Refs #3437

Revision 99a5aa62 (diff)
Added by Pascal Merz about 1 month ago

Separate StatePropagatorData element

The StatePropagatorData was both holding data which is accessed by
a majority of the elements, and was an element itself. The element
part is needed to save state information for printout and checkpointing.
The double nature of StatePropagatorData created some difficulty in
initializing the elements, however - the StatePropagatorData
has a well defined place within the simulator loop, but has to be
created ahead of time so that other elements can get a pointer to it
to query for state data during the simulation run.

This change separates the ISimulatorElement implementation which
allows StatePropagatorData to take part in the simulation loop
into a member object. The StatePropagatorData can now be created
ahead of element construction time, while an object of the member
class can be created any time later. This will make the implementation
of a builder approach significantly easier.

Refs #3437

Revision faf790d3 (diff)
Added by Pascal Merz about 1 month ago

Separate energy data and element

The EnergyElement was both holding data which is accessed by
a majority of the elements, and was an element itself. The element
part is needed to update the energy records and save data for
trajectory writing.
The double nature of the EnergyElement created some difficulty in
initializing the elements, however - the EnergyElement
has a well defined place within the simulator loop, but has to be
created ahead of time so that other elements can get a pointer to it
to query for or save energy data during the simulation run.

This change separates the ISimulatorElement implementation which
allows EnergyElement to take part in the simulation loop
into a member object. The data part of the EnergyElement is renamed
to EnergyData, the element is EnergyData::Element. The EnergyData
can now be created ahead of element construction time, while an
object of the member class can be created later. This will make the
implementation of a builder approach significantly easier.
The life time of the element is managed by the EnergyData object to
avoid problematic life time dependencies between the two.

Refs #3437

Revision 9ed40554 (diff)
Added by Pascal Merz about 1 month ago

Separate Element from FreeEnergyPerturbationData

Mirroring the StatePropagatorData and EnergyData, the free energy
element is split up into a data part that is accessed by other
elements, and a member class which implements the ISimulatorElement
to allow for updating and checkpointing of lambda values.

Refs #3437

Revision 612dec38 (diff)
Added by Pascal Merz 29 days ago

Introduce modular simulator exceptions

This introduces a new base exception for modular simulator, and a
few exceptions inheriting from this base exception. Having a
modular simulator base class allows to easily add exceptions without
touching (4!) files outside the module. The introduced derived
exceptions are all used in the fulfillment of #3437. Introducing them
in a separate commit allows to keep the final commit smaller.

Revision 8b8c7270 (diff)
Added by Pascal Merz 7 days ago

Introduce GlobalCommunicationHelper

In view of #3437 (!410), this introduces a helper container to store
data related to global communication. With the upcoming builder
approach, there won't be a central location where all elements are
created, so this helper container helps grouping related data allowing
for shorter call signatures. This helper object will become obsolete
when moving to a client-based global communication (#3421,
draft implementation ready).

Also available in: Atom PDF