<div dir="ltr">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:<br><div class="gmail_extra">
<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">Derek, what problem are you trying to solve by resetting the options like this?</span></blockquote>
<div><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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 ;-)</div>
<div style><br></div><div style>For now, swapping PETSC_COMM_WORLD is allowing me to solve my problems.  But I'll put in the proper prefixing stuff later.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>Thanks again for the replies!</div><div style><br></div><div style>Derek</div></div></div>