adding SNESSetLinearSolve()

[Barry Smith]

On Nov 1, 2007, at 10:16 AM, Matthew Knepley wrote:

> Actually, making the regularization parameter independent for each
> process is much more efficient. Gene Golub had a poster on this at
> the last SIAM CS&E meeting.
>
>   Matt
>
> On Nov 1, 2007 9:24 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>> On 10/31/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>>  Lisandro,
>>>   A followup to our previous discussion. It sounds to me like you
>>> are "actually" solving an n+1 unknown nonlinear problem where the
>>> "special" unknown is kept secret from SNES and managed somehow by  
>>> the
>>> application code?
>>
>> That's exactly the case. Furthermore, this 'special' unknown in  
>> just a
>> regularization parameter who tends to zero as the nonlinear solution
>> is reached. Unfortunatelly, this unknow is coupled with all other
>> degree of freedom, thus generating a full dense row and a dense  
>> column
>> in the Jacobian matrix. But fortunatelly, the special unknown is just
>> a single scalar, thus computing the schur complement is feasible, but
>> requires two linear solves with the other 'sparse' block of the
>> Jacobian.

    The point is that your ComputeJacobian routine would NEVER compute  
this Jacobian
with the final row/column that are dense. You would use a shell matrix  
for the full beast and
in side it store the n by n sparse beast in the usual manner, the  
shell PC would then
use the two parts of the shell matrix to do its thing with the two  
solves.

    I admit I do not have a handle on what it means to move the  
Eisenstat-Walker test
inside the outer-most KSP to the two inner linear solves. Either  
theoretically or
practically in code.

>>
>>
>>>  You can guess how I feel about this :-).
>>
>> Yes, of course. I agree that PETSc API must be consistent and clean.
>> But I also feel that some time I need more features. Please  
>> remember I
>> use PETSc exclusively from Python. And then is so easy to manage
>> complicated application setups. But at some point I need more
>> low-level support from PETSc to make it working.
>>
>> For example, I would love to have SNESSetPresolve/SNESSetPostSolve  
>> and
>> SNESSetPreStep/SNESSetPostStep, and perhaps a
>> SNESSetPreLinearSolve/SNESSetPostLinearSolve. Of course, this make  
>> the
>> API grow with features that are not frecuently needed.

   I'd like to understand why they are ever needed and if they can be  
done
with current constructs?

    Barry

>>
>>
>>> PETSc/SNES is suppose
>>> to be good enough to allow you to feed it the ENTIRE nonlinear  
>>> problem
>>> in a way that would allow as efficient solution as if you "handled  
>>> the
>>> special unknown" specially.
>>
>> Even for my particular case? Can I pass-over the issue with the full
>> denses rows and columns?
>>
>>> In particular for this problem the intended
>>> solution is to use the PETSc DMComposite object via  
>>> DMCompositeCreate()
>>>  You may want to look at this construct to see if it is suitable
>>> for your friends needs. And what we need to add (note that though  
>>> DMComposite
>>> can be used with DMMG it does not have to be, it can be used  
>>> directly
>>> with a SNES also.
>>
>> I'll definitely take a loop ASAP.
>>
>> Regards,
>>
>> --
>> 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
>>
>>
>
>
>
> -- 
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which
> their experiments lead.
> -- Norbert Wiener
>