Skip to content

Missing TIMPI interfaces #4

@roystgnr

Description

@roystgnr
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.

Activity

roystgnr

roystgnr commented on Mar 5, 2020

@roystgnr
MemberAuthor

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @roystgnr

        Issue actions

          Missing TIMPI interfaces · Issue #4 · libMesh/TIMPI