[petsc-users] Redo PetscOptions From Commandline

Dmitry Karpeev karpeev at mcs.anl.gov
Sun Apr 7 10:54:29 CDT 2013


On Fri, Apr 5, 2013 at 11:32 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> On Apr 5, 2013, at 10:18 AM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
>
> > Should PetscInitialize() take a comm argument, then?
>
>    No, this is such an uncommon case that it shouldn't be exposed to
> everyone.

It seems to me that the burden on the user is fairly small -- the
boilerplate code becomes
PetscInitialize(MPI_COMM_WORLD) instead of PetscInitialize().  From the
library design
perspective, making it more general by taking an initialization parameter
also sounds (to me)
like the right thing to do.  And since the hack that swaps PETSC_COMM_WORLD
works
(at least for Derek), it sounds like making it "legitimate" wouldn't take
much extra code.

Dmitry.


> 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).
>
>    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.
>
>    Barry
>
>
> >
> >
> > On Fri, Apr 5, 2013 at 10:15 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> > On Apr 5, 2013, at 10:09 AM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
> >
> > >
> > > On Thu, Apr 4, 2013 at 7:42 PM, Jed Brown <jedbrown at mcs.anl.gov>
> wrote:
> > >
> > > 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.
> > > Would that be enough?
> > >
> > > Dmitry.
> > >
> >
> >     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.
> >
> >    Barry
> >
> >
> > >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20130407/12ecbf60/attachment.html>


More information about the petsc-users mailing list