Enforce compability of MdModules
When MdModules modify data that is given to them they will be able to break compability to other modules that require the same data (e.g., two modules modifying topology data at the same time)
Thus MdModules should never modify data in simulation themselves, but only return values.
- Allow MdModuleNotifications to return values
- only allow for call signatures that have const input
- build intermediate layer of builder-like functionality where MdModule data has to be used to modify other outputs
#1 Updated by Eric Irrgang about 1 month ago
There is another option. MdModules could be allowed to acquire a write handle (for scheduling purposes, this could be a feature they subscribe to ahead of time) through an accessor. A write handle cannot be issued if read handles exist. Acquisition (or release) of a write handle should have a subscribable signal indicating changed data. Any consumer of the same information should subscribe to the signal if it invalidates local structures.
This could be enforced by requiring data to be subscribed to, and requiring a subscriber to provide a call-back that either provides a new read-handle or just an opportunity for the subscriber to invalidate its derived data (also triggering the changed-data signal).
@pascal has reasoned through some additional details in the context of the modular simulator elements. I.e. what meta-data should be associated with such data events to support efficient and robust sequencing: the call-back signature may include a step number (a conventional approach), but may also warrant a sub-step sequence number; though a richer subscription interface (specifying intervals or conditions for interest in a signal) would allow smarter scheduling while potentially relocating the logic of when a subscription signal is relevant to a particular subscriber.