[petsc-dev] changes to the TS structure

[Jed Brown]

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.

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