On Mon, Jul 16, 2012 at 6:53 PM, Barry Smith <[email protected]> wrote:

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???

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.

In other words fix petscthreadcomm model; don't mess with a perfectly good mpiuni.

MPI has them as separate communicators. MPIUNI breaks that model for, as far as I can tell, no good reason.