[petsc-users] pcsetup

Alex Fleeter luis.saturday at gmail.com
Wed Jul 22 14:50:50 CDT 2020


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?


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...
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20200722/ec462b17/attachment.html>


More information about the petsc-users mailing list