On Mon, Jul 16, 2012 at 6:53 PM, Barry Smith <bsmith at mcs.anl.gov> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120716/a62a7e48/attachment-0001.html>
