[petsc-dev] changes to the TS structure

[Barry Smith]

On May 19, 2010, at 2:07 PM, Jed Brown wrote:

> On Wed, 19 May 2010 15:17:19 -0300, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>> If you do have the SNES availabe at the point you setIFunction(vec,
>> func), then yes, there is no much to gain from having TS hold a ref to
>> vec. The damn issue right now is that you do not always have SNES
>> already created at that time. And other issue I want to solve is the
>> need to call setSolution() to make things work. IMHO, setRHSFunction()
>> should also take a vec to store the rhs function.
> 
> I think the TS should create the SNES at this point if it does not exist
> (just like KSPSetOperators does).  This might (possibly) be a
> significant enough change that it needs to coincide with a full rework
> of SNES ownership semantics.
> 
>> Additionally, it seems even you do not follow your own advocacy :-)
>> ... TS Theta hods a ref to th->res, while TS GL does not.
> 
> Looks like my mistake, thanks for pointing it out.
> 
>> Yea, but no model is perfect. For example, if you call KSPSetPC(), you
>> are implicitly changing the underlying operators. I'm still not sure
>> about what's fundamentally wrong with KSP hold a ref to A, and PC hold
>> refs to A,B. And I'm still unhappy with the current behavior of
>> {KSP|PC}GetOperators(). And...
> 
> My understanding of the history is that a long time ago, the idea was
> that the user creates a bunch of low-level objects and assembles them
> into the high-level thing.  This meant creating the various vectors
> needed by the linear and nonlinear solvers, creating a SNES, KSP, PC,
> then KSPSetPC() and SNESSetKSP().  The "modern" way is that you create
> the highest level object and it creates all the inner components.  The
> user then has SNESGetKSP() and KSPGetPC() to customize the inner pieces
> if they so desire.  This is why SNESGetKSP() is in the "beginner" API,
> but SNESSetKSP() is a "developer" API.

   Yes, this is essentially correct. Though there have probably always been inconsistencies about who creates what.

   I am not sure we really need the SNESSetKSP(), KSPSetPC() etc. Since one can get the inner object and customize it completely why would one need to set a completely different one in there? I put them in for symmetry and to be consistent with how the Mat and Vec work. For example, we could completely eliminate KSP/PCSetOperators() and the setting of Vecs into SNES. Instead one could use PCGetOperators() to get the (naked) Mats and then customize the Mats (and also Vecs) for the problem at hand.  In this model the user is responsible for creating essentially NO objects except the highest level beast (be it TS, SNES or KSP).  It didn't go this far because I am afraid most users will find it confusing to not create their own matrix. 

   Thus the current model is:

1) Users create the outer most beast.
2)   a) They can use get to access inner beasts and modify for their problem or
       b) They can create their own inner beasts and set them into the outer beasts
3) the "usual" style is for users to create their own inner Mat and Vec beasts but NOT create their own inner solver beasts (such as KSP in SNES or PC in KSP).

  If I were writing PETSc for my exclusive use I would remove all the sets for inner beasts and have the outer beast create all inner beasts and have the user (me) get the inner beast and customize it). Because I hate to have two ways to do the same thing).

   Barry

> 
> The "old-style" is bad for at least two reasons: it is more work to use
> the API since the user has to interact with all the inner objects even
> when they don't need customizing, and it creates order-dependence since
> setting certain options on the outer object require customization of the
> inner.
> 
>> Yes, it was the damn f... order-dependencies. I was using release-3.1,
>> perhaps now this works better in dev. I ended-up doing some horrible
>> hacks (no yet pushed) in petsc4py, in order to make the residual
>> vector available inside SNES early on, and then get matrix-free to
>> work.
> 
> I wonder what the specific issue was, I certainly run ex7 and ex10 with
> -snes_mf and -snes_mf_operator without doing anything special (I think
> these examples use "normal" setup).  I though the ugliness was mostly in
> the fragile and awkward call to SNESSetJacobian() within the TS
> implementation as the loud comments explain (this will go away once SNES
> ownership is fixed, it already does nothing implementation-specific
> since we have SNESTSFormJacobian() in -dev).
> 
> Jed