Inner KSP never created on SNES

[Barry Smith]

On Dec 2, 2008, at 4:02 PM, Lisandro Dalcin wrote:

> However, the argument (at source code) that PCGetOperators should
> return new Mat's if they were never set never, never convinced me. For
> me, Mat's are to KSP/PC like Function/Jacobian to SNES. Stuff that the
> user has to provide. Supose you call PCGetOperators(),  and then that
> call returns a just created Mat, with no sizes and not type, almost
> empty. What those returned Mat's would be good for?? Just to save
> users from a MatCreate() call ?? However, creating 'on-demand' inner
> PC on KSP, or inner KSP on SNES is a completelly different matter, as
> we can provide meaningful defaults for SNESType/KSPType/PCType.
>
>
    I use to think that the Mat and Vec are different kinds of objects  
(data objects)
from SNES and KSP (algorithm objects). In some sense this is true, but  
that
doesn't mean they shouldn't be as similarly treated as possible.

I use to think in a PETSc program the user created a bunch of objects  
and put them
together. Now I think we can also support a more "framework" oriented  
program
where the user creates one object (like SNES for nonlinear objects)  
and just
interacts with it.  I'm not claiming this is a better model (in fact I  
think often it is
a stupid simplistic model) but I like the idea of supporting it.

BTW:
   Currently one can do
     MatCreate(comm,&A);
     KSPSetOperators(ksp,A,,A,....)

Barry


> On Tue, Dec 2, 2008 at 6:53 PM, Barry Smith <bsmith at mcs.anl.gov>  
> wrote:
>>
>>  Ugg,  I have added this check.
>>
>>  Barry
>>
>>  This bug came from another "design extension" that was slightly
>> half-assed.
>> Originally SNESCreate() always created a KSP and KSPCreate() always  
>> created
>> a PC and one could not change them.  But I realized that PCCreate()  
>> did not
>> automatically have a Mat in it, you had to add one with  
>> PCSetOperators()
>> [which really should be called PCSetMats()!] One could also change
>> it later with another call to PCSetOperators(). By symmetry one  
>> should
>> also be able to replace the KSP in a SNES and the PC in a KSP, hence
>> SNESSetKSP(), KSPSetPC().
>>
>>   But still PC's PCGetOperator() was different
>> because it returned nothing if PCSetOperators() had not yet been  
>> set. So
>> I had PCGetOperators() automatically return a new Mat if one had  
>> never set
>> it. I then changed SNESGetKSP() and KSPGetPC() to automatically  
>> create
>> one if it did not already exist and SNESSetKSP() had never been  
>> called.
>> This meant I had to add a bunch of checks if (!snes->ksp) to make
>> sure SNES had a proper KSP when needed.
>>
>> An alternative approach was to have SNESCreate() and KSPCreate()
>> continue to create the KSP and PC and change the PCCreate() to  
>> automatically
>> have a Mat (then PCSetOperators() would just overwrite the one  
>> already
>> there). The reason I didn't take this route is that PC hast TWO  
>> slots for
>> mat and pmat, sometimes they are the same and sometimes they are
>> different. Should PCCreate() create one and put it in both slots or  
>> create
>> two, one for each slot. I could avoid that decision by having the  
>> creation
>> of those mats until PCGetOperators() when the user decides they  
>> want two or
>> one matrices by passing the same address in for mat and pmat or  
>> different
>> addresses.
>>
>> So a bunch of design decisions over time lead to the current  
>> undesirable
>> need for if (!snes->ksp) ....
>>
>>
>> On Dec 2, 2008, at 8:08 AM, Lisandro Dalcin wrote:
>>
>>> I've just noticed that now SNES does not create the inner KSP at the
>>> time SNESCreate() is called. Then I could easily manage to break
>>> things (basically, if SNESSetFromOptions() is never called)
>>>
>>> Does it make sense to add:
>>>
>>> if (!snes->ksp) { SNESGetKSP(snes, &snes->ksp);}
>>>
>>> near the begining of SNESSetUp() ??
>>>
>>>
>>> --
>>> Lisandro Dalcín
>>> ---------------
>>> Centro Internacional de Métodos Computacionales en Ingeniería  
>>> (CIMEC)
>>> Instituto de Desarrollo Tecnológico para la Industria Química  
>>> (INTEC)
>>> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
>>> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
>>> Tel/Fax: +54-(0)342-451.1594
>>>
>>
>>
>
>
>
> -- 
> Lisandro Dalcín
> ---------------
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
>