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