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
>
