[petsc-users] PCComposite

Hui Zhang mike.hui.zhang at hotmail.com
Mon May 28 09:49:48 CDT 2012


On May 28, 2012, at 4:40 PM, Hui Zhang wrote:

> 
> On May 28, 2012, at 3:42 PM, Jed Brown wrote:
> 
>> On Mon, May 28, 2012 at 8:40 AM, Hui Zhang <mike.hui.zhang at hotmail.com> wrote:
>> 
>> On May 28, 2012, at 3:20 PM, Jed Brown wrote:
>> 
>>> On Mon, May 28, 2012 at 5:19 AM, Hui Zhang <mike.hui.zhang at hotmail.com> wrote:
>>> Sorry for repost the following question, but after reading composite.c and asm.c,
>>> I can not understand.  I observed that my subroutine for modifying submatrices of PCASM was
>>> called twice.  In composite.c it seems there is no calling of PCSetUp on its componential PC's.
>>> In asm.c, the PCSetUp_ASM first determines whether pc->setupcalled is true.
>>> 
>>> I think this is a general question for PCComposite say pc. If it consists of two pc's  pc0, pc1
>>> and I have PCSetUp(pc0), I would not expect pc0 to be SetUp again.  I can not understand
>>> in my case why PCASM seems SetUp twice.
>>> 
>>> Does the routine do anything or just return immediately? If nothing has been changed since the last time a PC was set up, it should return immediately. If you have changed some configuration, it may need to be set up again.
>> 
>> Thanks. But I said something wrong.  The source code asm.c does call the ModifySubMatrices
>> whenever PCSetUp is called on PCASM, no matter whether it was called before.  So this 
>> explains my observation (two calls of ModifySubMatrices).  My new question is:  can you
>> add a user control to determine whether MatGetSubMatrices and PCModifySubMatrices 
>> should be called inside PCSetUp_ASM ?  But maybe this is too invasive and not
>> very useful to most people (although useful to me).
>> 
>> It does not reach PCSetUp_ASM unless something has changed. Run with -info and/or in a debugger to see why.
>> 
>> PetscErrorCode  PCSetUp(PC pc)
>> {
>>   PetscErrorCode ierr;
>>   const char     *def;
>> 
>>   PetscFunctionBegin;
>>   PetscValidHeaderSpecific(pc,PC_CLASSID,1);
>>   if (!pc->mat) SETERRQ(((PetscObject)pc)->comm,PETSC_ERR_ARG_WRONGSTATE,"Matrix must be set first");
>> 
>>   if (pc->setupcalled > 1) {
>>     ierr = PetscInfo(pc,"Setting PC with identical preconditioner\n");CHKERRQ(ierr);
>>     PetscFunctionReturn(0);
>> 
> 
> 
> Thanks for the hints.  I found why (I hope).  We have KSP named ksp and its PC is pc,
> and pc is PCComposite with pc0, pc1. The program runs like KSPSetUp on ksp, which
> calls PCSetUp on pc, i.e. PCSetUp_Composite on pc.  The source codes read
> 
> static PetscErrorCode PCSetUp_Composite(PC pc)
> 168: {
> 169:   PetscErrorCode   ierr;
> 170:   PC_Composite     *jac = (PC_Composite*)pc->data;
> 171:   PC_CompositeLink next = jac->head;
> 
> 174:   if (!jac->work1) {
> 175:    MatGetVecs(pc->pmat,&jac->work1,0);
> 176:   }
> 177:   while (next) {
> 178:     PCSetOperators(next->pc,pc->mat,pc->pmat,pc->flag);
> 179:     next = next->next;
> 180:   }
> 181:   return(0);
> 182: }
> Note the 178 line which calls PCSetOperators on pc0 and pc1.  The source codes of PCSetOperators
> read
> 
> 1050:  if (pc->setupcalled == 2 && flag != SAME_PRECONDITIONER) {
> 1051:     pc->setupcalled = 1;
> 1052:   }
> Note the 1051 line reset pc->setupcalled to 1, here the pc from PCSetUp_Composite is pc0 and pc1.
> So although if pc0  has been set up, this will cause pc0 be set up again. 
> 
> Is my reading correct?

I forgot to say: I first PCSetUp on pc0 before KSPSetUp on ksp.  Because construction of my pc1
needs to use PCSetUp'ed pc0. It seems current petsc assumes PCComposite is first SetUp before
its components pc0 and pc1 are SetUp'ed.



> 
> Thanks a lot!
> Hui
> 
> 
>>  
>> 
>> 
>>> 
>>>  
>>> 
>>> Thanks!
>>> Hui
>>> 
>>> 
>>> > I have got a new question.  I'm now constructing a PCComposite from PCASM and another PCKSP (coarse
>>> > problem). And construction of PCKSP needs to use the subksp's of PCASM. So I need to PCSetUp on the
>>> > PCASM, right?  But the KSP using PCComposite would setup PCASM again.  How can I avoid twice setup
>>> > of PCASM ?
>>> 
>>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120528/8eb51aad/attachment-0001.html>


More information about the petsc-users mailing list