Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing TIMPI interfaces #4

Open
roystgnr opened this issue Jan 27, 2020 · 1 comment
Open

Missing TIMPI interfaces #4

roystgnr opened this issue Jan 27, 2020 · 1 comment

Comments

@roystgnr
Copy link
Member

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.

@roystgnr
Copy link
Member Author

roystgnr commented Mar 5, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant