Give MdModules access to simulation resources (e.g. atom selection manager or communication infrastructure)
MdModules depend on resources that are not yet available when they are build.
The goal of this task is to build an infrastructure that
- provides the MDModules with the resources they need (preferably without changes to the IMDModules interface and avoiding function bloat of MDModules)
- ensures that resource dependencies are resolved in the right order (preferably at compile time)
- callback when resources are not longer available
Provide callbacks/notifications for MDModules
Adds functionality for MdModules to subscribe to be called back during
the simulation. Within the run, subscribed modules are notified of
events, that are distinguished by the function argument by the call back
Implements the callbacks based on storing function pointers, following
the discussion in https://gerrit.gromacs.org/c/gromacs/+/10942
#1 Updated by Eric Irrgang over 1 year ago
In the case of initializing the modules, this would seem to be a good case for a Builder pattern. Is there an argument against adding resources to module builders as Mdrunner::mdrunner progresses? Presumably, the builders themselves would also have to have "addSubscriber" aspects for inter-module dependencies.
But since Modules will need to consume some resources during simulation, likely repeatedly, it could be that both problems can be solved together with an Observer pattern such that resources passed during set up are just a special case of one-time updates. However, we then also need a Visitor pattern to allow Modules to subscribe themselves to resources, and possibly a Mediator to serve as the subject to which the modules are subscribed and which, in turn, is the subscriber to the various resources as they become available during Mdrunner::mdrunner.