March 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] GASM
by Dmitry Karpeev 29 Mar '12

29 Mar '12

Are you sure this is correct? KSPDestroy(&eksp) will still call PCDestroy() on subpc: http://petsc.cs.iit.edu/petsc/petsc-dev/file/76f5543c7e89/src/ksp/ksp/inter… Dmitry. On Thu, Mar 29, 2012 at 12:54 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Mar 29, 2012 at 10:45, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > >> Pushed: http://petsc.cs.iit.edu/petsc/petsc-dev/rev/76f5543c7e89 >> > > And the corresponding update to make GAMG stop leaking this PC. > > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/2d7a3ef1709a >

1 0

Re: [petsc-dev] GASM
by Jed Brown 29 Mar '12

29 Mar '12

On Thu, Mar 29, 2012 at 10:45, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > Pushed: http://petsc.cs.iit.edu/petsc/petsc-dev/rev/76f5543c7e89 > And the corresponding update to make GAMG stop leaking this PC. http://petsc.cs.iit.edu/petsc/petsc-dev/rev/2d7a3ef1709a

1 0

Re: [petsc-dev] GASM
by Dmitry Karpeev 29 Mar '12

29 Mar '12

Incidentally, any call to XXXReset() is, presumably, to be followed by a call to XXXSetUp(): why not roll the former into the latter? One argument against this would be that in between the calls the user might want to call XXXSetYYY(), which might otherwise be rejected until after XXXReset(), but in this case building a whole new XXX from scratch might be the right thing to do: we are no longer reusing the configuration. Dmitry. On Thu, Mar 29, 2012 at 11:45 AM, Dmitry Karpeev <karpeev(a)mcs.anl.gov>wrote: > Pushed: http://petsc.cs.iit.edu/petsc/petsc-dev/rev/76f5543c7e89 > > > On Thu, Mar 29, 2012 at 11:07 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> >> I think Jed is suggesting changing: >> >> PetscErrorCode KSPDestroy(KSP *ksp) >> { >> PetscErrorCode ierr; >> >> PetscFunctionBegin; >> if (!*ksp) PetscFunctionReturn(0); >> PetscValidHeaderSpecific((*ksp),KSP_CLASSID,1); >> if (--((PetscObject)(*ksp))->refct > 0) {*ksp = 0; >> PetscFunctionReturn(0);} >> >> ierr = KSPReset((*ksp));CHKERRQ(ierr); >> >> >> >> to >> >> >> PetscErrorCode KSPDestroy(KSP *ksp) >> { >> PetscErrorCode ierr; >> PC pc = (*ksp)->pc; >> >> PetscFunctionBegin; >> if (!*ksp) PetscFunctionReturn(0); >> PetscValidHeaderSpecific((*ksp),KSP_CLASSID,1); >> if (--((PetscObject)(*ksp))->refct > 0) {*ksp = 0; >> PetscFunctionReturn(0);} >> >> >> pc = (*ksp)->pc; >> (*ksp)->pc = PETSC_NULL; >> ierr = KSPReset((*ksp));CHKERRQ(ierr); >> (*ksp)->pc = pc; >> >> >> Since KSPDestroy() doesn't need to have PCReset() called. This doesn't >> require any special code for users. >> >> Barry >> >> >> On Mar 29, 2012, at 10:38 AM, Dmitry Karpeev wrote: >> >> > >> > >> > On Thu, Mar 29, 2012 at 10:13 AM, Jed Brown <jedbrown(a)mcs.anl.gov> >> wrote: >> > On Thu, Mar 29, 2012 at 08:28, Dmitry Karpeev <karpeev(a)mcs.anl.gov> >> wrote: >> > Back to the original problem: how shall we prevent a shared pc from >> being gutted by an unprotected PCReset() cascading from a KSPDestroy() on >> one of the containing ksps? I can factor out >> KSPReset_Private()/PCReset_Private() as indicated before, unless there are >> objections. >> > >> > What do you think of my suggestion of masking ksp->pc when KSPDestroy >> calls KSPReset? Then KSPReset does not call PCReset if ksp->pc does not >> exist. >> > I guess that works too, but I thought your suggestion applied to >> userland code right before calling KSPDestroy(&ksp)? >> > I suppose that will fix Mark's problem. Maybe that's the right >> approach: he got himself into this mess by reusing a pc >> > in the inner ksp, he should know how to extricate himself :-) >> > >> > Dmitry. >> > >> >> >

1 0

Re: [petsc-dev] GASM
by Dmitry Karpeev 29 Mar '12

29 Mar '12

Pushed: http://petsc.cs.iit.edu/petsc/petsc-dev/rev/76f5543c7e89 On Thu, Mar 29, 2012 at 11:07 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > I think Jed is suggesting changing: > > PetscErrorCode KSPDestroy(KSP *ksp) > { > PetscErrorCode ierr; > > PetscFunctionBegin; > if (!*ksp) PetscFunctionReturn(0); > PetscValidHeaderSpecific((*ksp),KSP_CLASSID,1); > if (--((PetscObject)(*ksp))->refct > 0) {*ksp = 0; > PetscFunctionReturn(0);} > > ierr = KSPReset((*ksp));CHKERRQ(ierr); > > > > to > > > PetscErrorCode KSPDestroy(KSP *ksp) > { > PetscErrorCode ierr; > PC pc = (*ksp)->pc; > > PetscFunctionBegin; > if (!*ksp) PetscFunctionReturn(0); > PetscValidHeaderSpecific((*ksp),KSP_CLASSID,1); > if (--((PetscObject)(*ksp))->refct > 0) {*ksp = 0; > PetscFunctionReturn(0);} > > > pc = (*ksp)->pc; > (*ksp)->pc = PETSC_NULL; > ierr = KSPReset((*ksp));CHKERRQ(ierr); > (*ksp)->pc = pc; > > > Since KSPDestroy() doesn't need to have PCReset() called. This doesn't > require any special code for users. > > Barry > > > On Mar 29, 2012, at 10:38 AM, Dmitry Karpeev wrote: > > > > > > > On Thu, Mar 29, 2012 at 10:13 AM, Jed Brown <jedbrown(a)mcs.anl.gov> > wrote: > > On Thu, Mar 29, 2012 at 08:28, Dmitry Karpeev <karpeev(a)mcs.anl.gov> > wrote: > > Back to the original problem: how shall we prevent a shared pc from > being gutted by an unprotected PCReset() cascading from a KSPDestroy() on > one of the containing ksps? I can factor out > KSPReset_Private()/PCReset_Private() as indicated before, unless there are > objections. > > > > What do you think of my suggestion of masking ksp->pc when KSPDestroy > calls KSPReset? Then KSPReset does not call PCReset if ksp->pc does not > exist. > > I guess that works too, but I thought your suggestion applied to > userland code right before calling KSPDestroy(&ksp)? > > I suppose that will fix Mark's problem. Maybe that's the right > approach: he got himself into this mess by reusing a pc > > in the inner ksp, he should know how to extricate himself :-) > > > > Dmitry. > > > >

1 0

Re: [petsc-dev] GASM
by Barry Smith 29 Mar '12

29 Mar '12

I think Jed is suggesting changing: PetscErrorCode KSPDestroy(KSP *ksp) { PetscErrorCode ierr; PetscFunctionBegin; if (!*ksp) PetscFunctionReturn(0); PetscValidHeaderSpecific((*ksp),KSP_CLASSID,1); if (--((PetscObject)(*ksp))->refct > 0) {*ksp = 0; PetscFunctionReturn(0);} ierr = KSPReset((*ksp));CHKERRQ(ierr); to PetscErrorCode KSPDestroy(KSP *ksp) { PetscErrorCode ierr; PC pc = (*ksp)->pc; PetscFunctionBegin; if (!*ksp) PetscFunctionReturn(0); PetscValidHeaderSpecific((*ksp),KSP_CLASSID,1); if (--((PetscObject)(*ksp))->refct > 0) {*ksp = 0; PetscFunctionReturn(0);} pc = (*ksp)->pc; (*ksp)->pc = PETSC_NULL; ierr = KSPReset((*ksp));CHKERRQ(ierr); (*ksp)->pc = pc; Since KSPDestroy() doesn't need to have PCReset() called. This doesn't require any special code for users. Barry On Mar 29, 2012, at 10:38 AM, Dmitry Karpeev wrote: > > > On Thu, Mar 29, 2012 at 10:13 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Mar 29, 2012 at 08:28, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > Back to the original problem: how shall we prevent a shared pc from being gutted by an unprotected PCReset() cascading from a KSPDestroy() on one of the containing ksps? I can factor out KSPReset_Private()/PCReset_Private() as indicated before, unless there are objections. > > What do you think of my suggestion of masking ksp->pc when KSPDestroy calls KSPReset? Then KSPReset does not call PCReset if ksp->pc does not exist. > I guess that works too, but I thought your suggestion applied to userland code right before calling KSPDestroy(&ksp)? > I suppose that will fix Mark's problem. Maybe that's the right approach: he got himself into this mess by reusing a pc > in the inner ksp, he should know how to extricate himself :-) > > Dmitry. >

1 0

Re: [petsc-dev] GASM
by Jed Brown 29 Mar '12

29 Mar '12

On Thu, Mar 29, 2012 at 09:38, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > I guess that works too, but I thought your suggestion applied to userland > code right before calling KSPDestroy(&ksp)? > I suppose that will fix Mark's problem. Maybe that's the right approach: > he got himself into this mess by reusing a pc > in the inner ksp, he should know how to extricate himself :-) > At first blush, I think the interface is better to do it inside KSPDestroy. I don't think PCReset should be called in that context except via PCDestroy.

1 0

Re: [petsc-dev] GASM
by Dmitry Karpeev 29 Mar '12

29 Mar '12

On Thu, Mar 29, 2012 at 10:13 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Mar 29, 2012 at 08:28, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > >> Back to the original problem: how shall we prevent a shared pc from being >> gutted by an unprotected PCReset() cascading from a KSPDestroy() on one of >> the containing ksps? I can factor out KSPReset_Private()/PCReset_Private() >> as indicated before, unless there are objections. >> > > What do you think of my suggestion of masking ksp->pc when KSPDestroy > calls KSPReset? Then KSPReset does not call PCReset if ksp->pc does not > exist. > I guess that works too, but I thought your suggestion applied to userland code right before calling KSPDestroy(&ksp)? I suppose that will fix Mark's problem. Maybe that's the right approach: he got himself into this mess by reusing a pc in the inner ksp, he should know how to extricate himself :-) Dmitry.

1 0

Re: [petsc-dev] GASM
by Jed Brown 29 Mar '12

29 Mar '12

On Thu, Mar 29, 2012 at 08:28, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > Back to the original problem: how shall we prevent a shared pc from being > gutted by an unprotected PCReset() cascading from a KSPDestroy() on one of > the containing ksps? I can factor out KSPReset_Private()/PCReset_Private() > as indicated before, unless there are objections. > What do you think of my suggestion of masking ksp->pc when KSPDestroy calls KSPReset? Then KSPReset does not call PCReset if ksp->pc does not exist.

1 0

Re: [petsc-dev] GASM
by Dmitry Karpeev 29 Mar '12

29 Mar '12

On Thu, Mar 29, 2012 at 9:04 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Mar 29, 2012 at 07:58, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > >> I am not sure how to solve the problem of the relationship between >> KSPReset() and PCReset() when the pc is being shared. >> How useful are KSPReset() and PCReset() anyway? All but one uses I found >> were "trivial" -- called from a PCReset_XXX, where XXX uses a KSP >> internally. The only nontrivial use I found was in VIRS, where the KSP and >> PC are reset when the active set changes. Would a simple KSPDestroy() do >> here instead? Perhaps there are uses of KSPReset()/PCReset() in user code, >> though. >> > > The purpose of all the XXReset() routines is to destroy internal data > structures so that the size of the matrix can be changed without needing to > reconfigure a new solver. For example, an AMR simulation would change the > mesh, create new matrices and vectors, but want to reuse a solver > _configuration_. > Okay. I guess if a pc is being shared by multiple ksps, either all or none of these ksps had better want to reset, because a KSPReset() by one of them will reset the pc for all of them. Back to the original problem: how shall we prevent a shared pc from being gutted by an unprotected PCReset() cascading from a KSPDestroy() on one of the containing ksps? I can factor out KSPReset_Private()/PCReset_Private() as indicated before, unless there are objections. Dmitry.

1 0

Re: [petsc-dev] GASM
by Jed Brown 29 Mar '12

29 Mar '12

On Thu, Mar 29, 2012 at 07:58, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > I am not sure how to solve the problem of the relationship between > KSPReset() and PCReset() when the pc is being shared. > How useful are KSPReset() and PCReset() anyway? All but one uses I found > were "trivial" -- called from a PCReset_XXX, where XXX uses a KSP > internally. The only nontrivial use I found was in VIRS, where the KSP and > PC are reset when the active set changes. Would a simple KSPDestroy() do > here instead? Perhaps there are uses of KSPReset()/PCReset() in user code, > though. > The purpose of all the XXReset() routines is to destroy internal data structures so that the size of the matrix can be changed without needing to reconfigure a new solver. For example, an AMR simulation would change the mesh, create new matrices and vectors, but want to reuse a solver _configuration_.

1 0