Task #3418: Infrastructure improvements for modular simulator
Implement client system for global reduction
The current compute_globals function performs more than just reduction over the different ranks of the simulation, requiring it to have a lot of knowledge about different functionalities. To allow for modularization, this should be moved to a design in which modules subscribe to the global reduction object, and can request reduction of an arbitrary number of values. In such a design, all computation is done by the module, the reduction object's only responsibility is the reduction of an arbitrary vector of floating point variables across simulation ranks.
#5 Updated by Eric Irrgang 3 months ago
Is the intention that the Accumulator owns opaque data on behalf of clients, or is there a possibility of regions of
globalVariables mapping to multiple clients?
How are clients/reductions grouped? Is there one Accumulator per (sub)communicator?
My first reaction is that, here, both Accumulator and Clients depend on IAccumulatorClient, but it doesn't seem like either of them needs to. It seems like it should be sufficient for the client builder to interact with the AccumulatorBuilder.
Looking at the diagram, it doesn't seem that the IAccumulatorClient is necessary, but that it should be sufficient to register a function object.
It also seems like the Accumulator and client are slightly more coupled than necessary.
It doesn't seem like the client should need to hold both a reference to the Accumulator and keep an ArrayRef view member. It can either retrieve the fresh ArrayRef from the Accumulator or pre-arrange the call-backs for delivery.
Does the client need to be able to request reduction or should this be pre-scheduled? What is the result of the request() (notifyReductionNeeded()?)?
Are performReduction() and notifyReductionNeeded() public members of the same interface? Is that necessary and appropriate?