<div class="gmail_quote">On Sun, Apr 15, 2012 at 12:52, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":c5t">  Curse it, these are all cases of MPI didn't do something right or some MPI implementor got lazy and didn't include something they should have. They should really start with MPI.  Maybe MPILazyBastards_xxxx() it doesn't seem right to name space any of them with PETSc!!!!  MPImissing_, MPIFU_  (for MPI fuck up).<br>
</div></blockquote><div><br></div><div>MPIPetsc_xxx so it's at least clear who is providing the "fixed" version (and which package's configure it may depend on). MPIU_INT, for example, is intimately bound to the way PETSc was configured, so maybe it should be MPIPETSC_INT?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":c5t">
<br>
> PetscMPI_Iallreduce(), Petsc_MPI_Iallreduce(),<br>
<br>
   This is a clash between two naming conventions, the silly MPI one with _ and the reasonable Petsc one without a million _.  You know the one I like.<br>
<br>
    Are you sure we shouldn't continue to use MPIU? We have squatters rights to that prefix since we've used it for 18 years. It looks good and makes clear what those functions are for.</div></blockquote></div><br>
<div>It's true, but it would be a shame for some version of PETSc to become incompatible with some version of MPICH due to a symbol collision (though they use visibility on many platforms, so the symbol can be used within the library, but not visible outside).</div>