<div class="gmail_quote">On Mon, Jul 16, 2012 at 6:53 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">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=":2fj">   Yes, that is absolutely a hack and does not belong there. But you are totally miss understanding what I am saying: that hack is NEW. For 15 years PETSc did NOT need a hack to work with MPIUNI (which has a single communicator), thus I conclude that MPUNI is fine and something is wrong with the PETSc thread comm stuff if it requires that hack. That is, why the heck does petscthreadcomm depend on MPI_COMM_SELF != MPI_COMM_WORLD while for 20 years NOTHING ELSE IN PETSc (which is a dang lot more complicated than petscthreadcomm) does not depend on MPI_COMM_SELF != MPI_COMM_WORLD???<br>
</div></blockquote><div><br></div><div>As far as I know, the other calls to MPI_Attr_put occur the first time the comm is used with an object rather than being pre-initialized. In this case, PETSC_COMM_SELF and PETSC_COMM_WORLD are pre-endowed with the threadcomm. Should the threadcomm be placed in some global variable and obtained (and referenced) the first time it is used with a given communicator? If we store the canonical one on a comm, then it must be on COMM_WORLD and COMM_SELF.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2fj">
<br>
   In other words fix petscthreadcomm model; don't mess with a perfectly good mpiuni.</div></blockquote></div><br><div>MPI has them as separate communicators. MPIUNI breaks that model for, as far as I can tell, no good reason.</div>