<div dir="ltr"><div>Lisandro raises an interesting point.  I just checked the MPI_VERSION defined on the currently released IBM BlueGene/P driver, and I was surprised to see 2.1 defined, given that the BlueGene doesn't support dynamic process control (though I guess otherwise it is basically a full MPI-2), from the developer's guide:</div>
<div><br></div><div>"<span class="Apple-style-span" style="font-family: Helvetica; font-size: 10px; ">The implementation of MPI on the Blue Gene/P system is the MPICH2 standard that was developed by Argonne National Labs. For more information about MPICH2, see the Message Passing Interface (MPI) standard Web site at:</span><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><meta http-equiv="Content-Style-Type" content="text/css"><title>
</title><meta name="Generator" content="Cocoa HTML Writer"><meta name="CocoaVersion" content="1038.36"><style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 10.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Times; color: #033efc}
span.s1 {font: 8.0px Helvetica}
</style>
<p class="p2"><a href="http://www-unix.mcs.anl.gov/mpi/">http://www-unix.mcs.anl.gov/mpi/</a></p>
<p class="p1">A function of the MPI-2 standard that is not supported by Blue Gene/P is dynamic process management (creating new MPI processes).<span class="s1">16 </span>However, the various thread modes are supported".</p>
<div><br></div><div>I think this is worth considering carefully as MPI-3 is approved and we start to see vendor implementations of some of its cooler features show up on our systems.  Perhaps in addition to version numbers specific 'features' could be macro-defined by the standard: MPI_HAS_EXSCAN, etc...?  This might be a reasonable compromise between the two approaches.</div>
<div><br></div><div>A </div><div><br></div><div class="gmail_quote">On Tue, Aug 2, 2011 at 4:56 AM, Lisandro Dalcin <span dir="ltr"><<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 31 July 2011 14:34, William Gropp <<a href="mailto:wgropp@illinois.edu">wgropp@illinois.edu</a>> wrote:<br>
> I'm referring to the MPI_VERSION and MPI_SUBVERSION.<br>
> I'm in general a supporter of feature checks, but in the case of MPI, the<br>
> documentation is very precise about the content of each version and there<br>
> are comprehensive tests for MPI implementations that have ensured compliance<br>
> with the spec.  The MPI Forum has repeatedly rejected any MPI subset,<br>
> ensuring that MPI_VERSION and MPI_SUBVERSION can be used.<br>
<br>
</div>So, suppose an MPI implementation advertises 1.3 compliance (by<br>
defining  MPI_VERSION as 1 and MPI_SUBVERSION as 3), and implements<br>
some calls from MPI 2.0 like MPI_Exscan() ? Using the version macros<br>
would prevent PETSc to use the MPI_Exscan() available in the<br>
implementation as an extension... Or does "The MPI Forum has<br>
repeatedly rejected any MPI subset" means that such implementations<br>
are not conforming with the MPI std?<br>
<br>
<br>
--<br>
<font color="#888888">Lisandro Dalcin<br>
---------------<br>
CIMEC (INTEC/CONICET-UNL)<br>
Predio CONICET-Santa Fe<br>
Colectora RN 168 Km 472, Paraje El Pozo<br>
3000 Santa Fe, Argentina<br>
Tel: +54-342-4511594 (ext 1011)<br>
Tel/Fax: +54-342-4511169<br>
</font></blockquote></div><br></div></div>