<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 5, 2013 at 11:32 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Apr 5, 2013, at 10:18 AM, Dmitry Karpeev <<a href="mailto:karpeev@mcs.anl.gov">karpeev@mcs.anl.gov</a>> wrote:<br>
<br>
> Should PetscInitialize() take a comm argument, then?<br>
<br>
</div>   No, this is such an uncommon case that it shouldn't be exposed to everyone.  </blockquote><div style>It seems to me that the burden on the user is fairly small -- the boilerplate code becomes</div><div style>

PetscInitialize(MPI_COMM_WORLD) instead of PetscInitialize().  From the library design </div><div style>perspective, making it more general by taking an initialization parameter also sounds (to me) </div><div style>like the right thing to do.  And since the hack that swaps PETSC_COMM_WORLD works </div>

<div style>(at least for Derek), it sounds like making it "legitimate" wouldn't take much extra code.</div><div style><br></div><div style>Dmitry.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Note I actually would advocate that "Moose's new MultiApp capability" use PETSc "above" the individual runs and thus would not design "Moose's new MultiApp capability" to set the PETSC_COMM_WORLD to be related to a single app; I was just pointing out this was a possibility if "Moose's new MultiApp capability"  specifically only knew about PETSc at the individual App level (which it sounds like its current design).<br>


<br>
   Also note that I previously proposed making PetscOptionsInsertArgs_Private()  public so that one may reset the command line options and not the environmental options and Moose could then use this option safely and not need to muck with PETSC_COMM_WORLD.<br>


<span class="HOEnZb"><font color="#888888"><br>
   Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
><br>
><br>
> On Fri, Apr 5, 2013 at 10:15 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> On Apr 5, 2013, at 10:09 AM, Dmitry Karpeev <<a href="mailto:karpeev@mcs.anl.gov">karpeev@mcs.anl.gov</a>> wrote:<br>
><br>
> ><br>
> > On Thu, Apr 4, 2013 at 7:42 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
> ><br>
> > It seems to me this is related to Moose's new MultiApp capability: solving different systems on subcommunicators (with the interaction between the systems handled outside of PETSc)?  It may be that the cleaner approach is to have the subsystems (their solvers, rather) use prefixes to set their specific options.<br>


> > Would that be enough?<br>
> ><br>
> > Dmitry.<br>
> ><br>
><br>
>     If PETSc is only aware of the subcommunicator then it could be that the right model is to set PETSC_COMM_WORLD to be the sub comm of MPI_COMM_WORLD before PetscInitialize(), then PETSc only sees that sub communicator.  But you will NOT be able to use PETSc on anything that "connects" these various sub communicators together.<br>


><br>
>    Barry<br>
><br>
><br>
> ><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div></div><br></div>