<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>So: I don't fault Hypre... it seems to work under the same assumption.  I can see both sides.</div><div><br></div><div>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.</div><div><br></div><div>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...</div><div><br></div><div>Derek</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 3, 2018 at 4:22 PM Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 3, 2018 at 6:20 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Derek Gaston <<a href="mailto:friedmud@gmail.com" target="_blank">friedmud@gmail.com</a>> writes:<br>
<br>
> On Tue, Apr 3, 2018 at 4:06 PM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
><br>
>> Communicators should be cheap.  One per library per "size" isn't a huge<br>
>> number of communicators.<br>
>><br>
><br>
> I agree - but that's not what we're getting here.  We're getting one per<br>
> "object" (Mat / Preconditioner, etc.) associated with the library per<br>
> "size".  If we can fix that I agree that there's no problem (we use a lot<br>
> of libraries... but not 2000 separate ones simultaneously!).<br>
<br>
</span>So PETSc needs to dup and attach a hypre communicator because they<br>
aren't interested in doing it themselves.  Not hard to implement, just<br>
mildly annoying.<br>
</blockquote></div><br></div></div><div dir="ltr"><div class="gmail_extra">Can't someone tell them its an xSDK requirement?</div></div><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">   Matt<br clear="all"><div><br></div>-- <br><div class="m_3791601016205030361gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div>
</div></div></blockquote></div>