<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Michael,
<div class=""><br class="">
</div>
<div class="">Personally, I would read and summarise the current MPI text about this as these two restrictions:</div>
<div class=""><br class="">
</div>
<div class="">The type map described by {sendcount, sendtype} in A must be consistent with the type map described by {recvcount, recvtype} in B, e.g. {4, MPI_INTEGER} in A and {1, strided_4_integers}.</div>
<div class=""><br class="">
</div>
<div class="">and, at the same time,</div>
<div class="">
<div class=""><br class="">
</div>
<div class="">The type map described by {sendcount, sendtype} in B must be consistent with the type map described by {recvcount, recvtype} in A, e.g. {4, MPI_DOUBLE} in B and {1, strided_4_doubles}.</div>
<div class=""><br class="">
</div>
<div class="">For an intra-communicator, or for processes in an inter-communicator with dual-membership (erroneous but somehow supported according to section 6.6.2), one of the send/recv communications for each process is back to that same process. Thus, these
two statements constrain the operation to have only one type map, which is then applicable to both directions at all processes. That type map could be specified using different but consistent {count, type} parameters at each process.</div>
<div class=""><br class="">
</div>
<div class="">So, in short, yes.</div>
<div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="Apple-interchange-newline">
Cheers,</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Dan.</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
—<br class="">
Dr Daniel Holmes PhD<br class="">
Applications Consultant in HPC Research<br class="">
<a href="mailto:d.holmes@epcc.ed.ac.uk" class="">d.holmes@epcc.ed.ac.uk</a><br class="">
Phone: +44 (0) 131 651 3465<br class="">
Mobile: +44 (0) 7940 524 088<br class="">
Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
—</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
—</div>
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 30 Apr 2019, at 10:07, Michael Knobloch via mpi-forum <<a href="mailto:mpi-forum@lists.mpi-forum.org" class="">mpi-forum@lists.mpi-forum.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hi all,<br class="">
<br class="">
when looking at the semantics of all-to-all collectives on intercomms I<br class="">
came to a point that isn't entirely clear from the standard: Am I'm<br class="">
allowed to use different datatypes for each communication direction,<br class="">
i.e. send MPI_INTEGERS from group A to group B and MPI_DOUBLES from B to A?<br class="">
<br class="">
The standard says (page 168, line 38 for MPI_Alltoall, similar<br class="">
statements for the other all-to-all collectives): The type signature<br class="">
associated with sendcount, sendtype, at a process must be equal to<br class="">
the type signature associated with recvcount, recvtype at any other<br class="">
process. This implies that the amount of data sent must be equal to the<br class="">
amount of data received, pairwise between every pair of processes. As<br class="">
usual, however, the type maps may be different.<br class="">
<br class="">
This however is only true for an intracommunicator as the statement only<br class="">
holds for every pair of *communicating* processes, which in the case of<br class="">
an intercommunicator is not every pair of processes (though the name<br class="">
implies a different semantics). And the advice to users (page 169, line<br class="">
23) contradicts that by saying that the counts may be different, but<br class="">
says nothing about the datatypes.<br class="">
<br class="">
-Michael<br class="">
-- <br class="">
Michael Knobloch<br class="">
Juelich Supercomputing Centre<br class="">
Institute for Advanced Simulation<br class="">
Forschungszentrum Juelich GmbH<br class="">
52425 Juelich, Germany<br class="">
<br class="">
Phone: +49-2461-61-3546<br class="">
Fax: +49-2461-61-6656<br class="">
<a href="mailto:m.knobloch@fz-juelich.de" class="">E-mail: m.knobloch@fz-juelich.de</a><br class="">
WWW: http://www.fz-juelich.de/jsc/<br class="">
<br class="">
_______________________________________________<br class="">
mpi-forum mailing list<br class="">
mpi-forum@lists.mpi-forum.org<br class="">
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>