don't skip master rank on receive in mpi_vector

[selmanTerzi]

this is needed for ring-blocking in parareal

[pint-jenkins]

Can one of the admins verify this patch?

[torbjoernk]

@pint-jenkins test this please

[torbjoernk]

LGTM. @memmett any concerns?

[memmett]

I feel like this should break something! Anyway, I think the better way to do this is the following (see LIBPFASST): the communicator should keep track of who is the "first" processor, and who is the "last" processor. Then in send/recv you can use modular arithmetic to figure out if you should in fact send/recv.

[pancetta]

+1. Alternatively, each time rank could have some notion of its pre- and
successor (which would be helpful as as soon as we have fun with mixing
the order of the ranks: ring parallelization, fault tolerance, time
adaptivity etc.). Anyway, then you can do send/recv on all ranks,
provided the first and the last simply point to themselves. This should
result in an empty MPI call..

On 17.04.15 15:43, Matthew Emmett wrote:

I feel like this should break something! Anyway, I think the better way
to do this is the following (see LIBPFASST): the communicator should
keep track of who is the "first" processor, and who is the "last"
processor. Then in send/recv you can use modular arithmetic to figure
out if you should in fact send/recv.

—
Reply to this email directly or view it on GitHub
#192 (comment).

[memmett]

+1. Everyone is feeling the love today...

Continuing with @pancetta, I guess we could come up with a very simple API now and have it implement a simple ring with first/last accounting. Let's just make sure we don't go over board and end up in YAGNI land. As it is right now, everyone calls send/recv and the logic to test for first/last is in the body of send/recv, so in that sense we're already somewhat in line with @pancetta (all ranks call send/recv).

Suggestions for an API?

How about, ok_to_send() and ok_to_recv() or something like that?

[memmett]

I'm closing this but have created a related issue #222.