[petsc-users] pcsetup

[Matthew Knepley]

On Wed, Jul 22, 2020 at 3:52 PM Alex Fleeter <luis.saturday at gmail.com>
wrote:

> Hi Barry:
>
> That explains and makes sense.
>
> Suppose I have associated a Mat object with KSP, by KSPSetOperators in the
> beginning of a Newton-Raphson iteration, say.
>
> Then in the following iteration steps, the entries in the Mat are updated.
> I only need to directly call KSPSolve without doing KSPSetOperators, since
> in KSPSolve the state of the Mat object is automatically detected and
> the PC will be reconstructed if necessary, correct?
>

Yes.

  Thanks,

    Matt


> On Tue, Jul 21, 2020 at 6:28 PM Barry Smith <bsmith at petsc.dev> wrote:
>
>>
>>   Alex,
>>
>>    See my long email.   The thing with nested preconditioners (like
>> yours) is they have multiple PCSetUps(), possibly outer ones and inner
>> ones. Each of these PC independently triggers a rebuild based on its own
>> state, hence the inner PCSetUps will be triggered when you change the inner
>> matrices (even when you don't call MatAssemblyBegin/End() on the MatNest.
>>
>>    In your case since the preconditioner seems to depend only on the two
>> sub matrices the fact that PCSetUp() is not called on the MatNest is
>> harmless, since that setup wouldn't do anything anyways.
>>
>>    For Schur complement based PCFieldsplits however the result maybe be
>> wrong unless you call MatAssemblyBegin/End on the nest matrix since the
>> outer setup actually does something
>>
>>   Barry
>>
>>
>> On Jul 21, 2020, at 8:16 PM, Alex Fleeter <luis.saturday at gmail.com>
>> wrote:
>>
>> If I call MatAssembly for individual sub-matrices,
>>  MatAssemblyBegin(subA[ii], MAT_FINAL_ASSEMBLY);
>>  MatAssemblyEnd(subA[ii], MAT_FINAL_ASSEMBLY);
>>
>> then call KSPSetOperators, the PC setup is not called.
>>
>> I have to call the assembly for the whole nest matrix
>>  MatAssemblyBegin(A, MAT_FINAL_ASSEMBLY);
>>  MatAssemblyEnd(A, MAT_FINAL_ASSEMBLY);
>> to trigger the setup of PC.
>>
>> I found some comments in matnest.c
>> <https://www.mcs.anl.gov/petsc/petsc-current/src/mat/impls/nest/matnest.c>,
>> line 474-478: "Note: split assembly will fail if the same block appears
>> more than once (even indirectly through a nested
>>
>> 475:            * sub-block). This could be fixed by adding a flag to Mat <https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/Mat.html#Mat> so that there was a way to check if a Mat <https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/Mat.html#Mat> was476:            * already performing an assembly, but the result would by more complicated and appears to offer less477:            * potential for diagnostics and correctness checking. Split assembly should be fixed once there is an478:            * interface for libraries to make asynchronous progress in "user-defined non-blocking collectives"."
>>
>> I guess the comment suggests calling matassembly for the big nest matrix after having setted values for individual sub-matrices, instead of calling matassembly for individual submatrices.
>>
>>
>> Can you confirm that?
>>
>>
>>
>> On Tue, Jul 21, 2020 at 4:35 PM Mark Adams <mfadams at lbl.gov> wrote:
>>
>>> KSPSetOperator tells the KSP that the PC should be resetup.
>>>
>>> On Tue, Jul 21, 2020 at 3:45 PM Alex Fleeter <luis.saturday at gmail.com>
>>> wrote:
>>>
>>>> Hi:
>>>>
>>>> I want to ask under what circumstance will trigger a call for pc setup.
>>>>
>>>> I call KSPSolve to solve with the same Mat object with different entry
>>>> values each time. I can see that the pc setup is only called at the
>>>> beginning of the first solve.
>>>>
>>>> I tried to read the implementation, but quickly get lost...
>>>>
>>>
>>

-- 
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

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20200722/592d6b21/attachment.html>