On 19 May 2010 16:18, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> 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
>
>
Barry/Jed, many thanks for your comments. Now things are far more
clear. So we should make KSPGetSolution(), KSPGetRHS(), etc. create
the inner vecs, and similarly for SNES and TS.
--
Lisandro Dalcin
---------------
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
