[petsc-dev] [issue1595] Issues of limited number of MPI communicators when having many instances of hypre boomerAMG with Moose

Rob Falgout hypre Tracker hypre-support at llnl.gov
Tue Apr 3 17:42:03 CDT 2018


Rob Falgout <rfalgout at llnl.gov> added the comment:

Is somebody actually having a problem with communicator conflicts right now?

I thought the reason for this thread was to reduce the number of communicators because of limits in MPI implementations.  Somebody has to reduce the Comm_create() and Comm_dup() calls.  We responded with one way to reduce the create() calls in BoomerAMG, but now you are asking us to put them back in by calling dup()?  I'm confused about what we are trying to achieve here now.

The reason I suggested that the user be responsible for calling dup() is twofold: 1) I don't think it is common for users to run hypre in parallel with other user code where both are using the same communicator (I'm not sure how this could even work without deadlocking since hypre calls are collective); 2) Making libraries lower down on the call stack be responsible for calling dup() seems less scalable than the other way around and more likely to increase the number of communicators used.

Anyway, I'm still confused about what we are trying to achieve so maybe somebody can try to summarize again?

-Rob

____________________________________________
hypre Issue Tracker <hypre-support at llnl.gov>
<http://cascb1.llnl.gov/hypre/issue1595>
____________________________________________


More information about the petsc-dev mailing list