[petsc-users] Redo PetscOptions From Commandline

[Derek Gaston]

Sorry for the delay in my replies!  I got diverted off to something else
and am just now making it back to this!  Thank you guys for all the good
replies, I'll try to answer some of the questions:

Derek, what problem are you trying to solve by resetting the options like
> this?


Well, of course, I am trying to do something in the wrong way.  I should be
using prefixing, like Dmitry posits.  However, we don't have the ability to
assign names to individual solves at this moment... but we do have
different sets of options for each solve (that we're storing in our own
parameters objects).  So, my "quick and dirty" idea was to clear the PETSc
options before each solve and fill them back in with the correct options
for this solve.

That works fine... but we do also want to allow setting "global" options on
the command-line and having those effect all of the solves.  So I needed to
pull those back in too.

Unfortunately, some of these solves are on sub-communicators (actually, all
of them might be... but at least in my case there is at least one solve
over the entire set of processors that's been given to us... even if that
might not be over COMM_WORLD)... so calling PetscOptionsInsert() on those
sub-communicators will cause the program to hang.

This is most definitely my own fault... we should be using the mechanisms
built into PETSc for assigning per-solve options (prefixing).  It's just
that in this particular case that can get arbitrarily complicated (we have
multiple levels of hierarchical solves happening... where only the level
above a given level knows about a level (i.e. a level doesn't even know
about the level above it that spawned it) so you have to be a bit careful
to make sure prefixes don't collide).  But it can be done ;-)

For now, swapping PETSC_COMM_WORLD is allowing me to solve my problems.
 But I'll put in the proper prefixing stuff later.

Now - about PetscInitialize()... we are in the situation where we might be
passed a sub-communicator to do our whole solve on and will need to set
PETSC_COMM_WORLD to that sub-comunicator.  It's good to know that I just
need to do that before PetscInitialize().  It seems to me that it could be
convenient to have another version of PetscInitialize that takes a COMM for
just this case.  But, I do understand that it's fairly uncommon.  For us,
this is happening because of coupling multiple codes together (which might
not be PETSc based codes) that are running on disjoint communicators in
parallel.

Thanks again for the replies!

Derek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20130406/a96e609e/attachment.html>