[petsc-users] Redo PetscOptions From Commandline

[Barry Smith]

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.  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
> 
> 
> >
> 
> 
> 
>