[petsc-users] A bad commit affects MOOSE

[Derek Gaston]

It's interesting... I'm now thinking about MOOSE.  MOOSE doesn't dup the
comm you give it either.  It simply takes it and uses it.  It assumes
you've already done the duping.

I like it that way because the calling code can do whatever it needs to do
to get that communicator (for instance, split it).  Duping it on the way in
would be unnecessary in many circumstances where MOOSE is getting passed a
"clean" comm (for instance, from a split that is meant only for that
instance of MOOSE).  It's up to the caller to make sure to pass in a clean
comm for MOOSE to use.

So: I don't fault Hypre... it seems to work under the same assumption.  I
can see both sides.

At the same time, I can see the PETSc model because it simplifies things
for the calling library - you don't have to worry about passing in a
"clean" comm... PETSc generates its own internally.

I think both models are valid - and there are tradeoffs both ways.  We just
need to do the "annoying" thing and keep track of a clean comm that we're
passing in to Hypre.  When MOOSE is running sub-solves of itself the
calling instance of MOOSE creates and keeps track of those clean comms for
each sub-solve...

Derek

On Tue, Apr 3, 2018 at 4:22 PM Matthew Knepley <knepley at gmail.com> wrote:

> On Tue, Apr 3, 2018 at 6:20 PM, Jed Brown <jed at jedbrown.org> wrote:
>
>> Derek Gaston <friedmud at gmail.com> writes:
>>
>> > On Tue, Apr 3, 2018 at 4:06 PM Jed Brown <jed at jedbrown.org> wrote:
>> >
>> >> Communicators should be cheap.  One per library per "size" isn't a huge
>> >> number of communicators.
>> >>
>> >
>> > I agree - but that's not what we're getting here.  We're getting one per
>> > "object" (Mat / Preconditioner, etc.) associated with the library per
>> > "size".  If we can fix that I agree that there's no problem (we use a
>> lot
>> > of libraries... but not 2000 separate ones simultaneously!).
>>
>> So PETSc needs to dup and attach a hypre communicator because they
>> aren't interested in doing it themselves.  Not hard to implement, just
>> mildly annoying.
>>
>
> Can't someone tell them its an xSDK requirement?
>
>    Matt
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20180403/4bdd9994/attachment.html>