On Wed, Jul 22, 2020 at 3:52 PM Alex Fleeter <luis.satur...@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 <bsm...@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.satur...@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 <mfad...@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.satur...@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/>
