You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While going through the TIMPI headers to write up summaries, I noticed there are still a number of non-blocking MPI operations that we don't provide interfaces to but should: reductions, scatters/gathers, and broadcasts. There's also MPI_Scan, which we don't even support in blocking form. There's also a number of overloads (unordered_set and unordered_map communications!) that we don't have yet.
For libMesh purposes I was always happy with our "don't bother implementing each API until we need it" philosophy, but we might want to preemptively satisfy more requirements if we want to attract more users. The only catch is that we'll need to be on the ball with unit testing, if we're adding APIs we don't immediately have a real use case for.
The text was updated successfully, but these errors were encountered:
Here's an idea for adding a lot of missing container compatibility at once: for non-vector containers, just use std::begin(c) and std::end(c) iterators to copy the data from c into the buffer to be transmitted. We keep std::vector overloads for efficiency, but then everything from std::deque to std::unordered_map might be handled by a single routine for some operations.
Ironically, it was @jwpeterson's reduction operations on map+unordered_map that made me think of this, but those are some of the few cases where we wouldn't want to just treat the container as a simple range.
While going through the TIMPI headers to write up summaries, I noticed there are still a number of non-blocking MPI operations that we don't provide interfaces to but should: reductions, scatters/gathers, and broadcasts. There's also MPI_Scan, which we don't even support in blocking form. There's also a number of overloads (unordered_set and unordered_map communications!) that we don't have yet.
For libMesh purposes I was always happy with our "don't bother implementing each API until we need it" philosophy, but we might want to preemptively satisfy more requirements if we want to attract more users. The only catch is that we'll need to be on the ball with unit testing, if we're adding APIs we don't immediately have a real use case for.
The text was updated successfully, but these errors were encountered: