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

Weird interaction between VecDuplicate and VecSetBlockSize
by Blaise Bourdin 30 Mar '12

30 Mar '12

Hi, I am trying to make use of the more advanced features of the hdf5 viewer. I get the following error when running src/vec/vec/examples/tutorials/ex19.c: [0]PETSC ERROR: VecLoad_HDF5() line 251 in /opt/HPC/petsc-dev/src/vec/vec/utils/vecio.c Block size 1 specified for vector does not match blocksize in file 2 Upon further investigating, I noticed that if Vec x2 is obtained by duplicating x1, then setting the block size for x2 also sets it for x1. Is this really the desired behavior? I am attaching an trivial example. Blaise -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin

1 0

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

30 Mar '12

Mark, It looks like you should destroy ASMLocalIDsArr[level] before zeroing it out: GASM increfs it internally, and when you set this IS to 0, you leak the reference you acquired when creating it in PetscCDGetASMBlocks(). Dmitry. On Fri, Mar 30, 2012 at 9:04 AM, Mark F. Adams <mark.adams(a)columbia.edu>wrote: > Thanks, it seems to work but I have a memory leak. I use: > > ierr = PCGASMSetLocalSubdomains( subpc, sz, is, PETSC_NULL ); > CHKERRQ(ierr); > ierr = PetscFree( is ); CHKERRQ(ierr); > > and it looks like the ISs are not getting destroyed in GASM. > > Mark > > On Mar 29, 2012, at 9:35 PM, Dmitry Karpeev wrote: > > Now it should work the way you intended. > Let me know if it doesn't, though. > > Dmitry. > > On Thu, Mar 29, 2012 at 7:49 PM, Mark F. Adams <mark.adams(a)columbia.edu>wrote: > >> >> On Mar 29, 2012, at 11: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 :-) >> >> >> BTW, this is not a matter of being lazy, I need an eigen estimate of the >> smoothers preconditioned operator. In the past I created a new PC from the >> command line database (ugly), but this GASM smoother can not be >> reconstructed from the database (it uses the AMG aggregates). I could do a >> deep copy of the smoother but that would require two setups of the GASM PC, >> which would be ugly. >> >> Mark >> >> >> Dmitry. >> >> >> > >

1 0

Re: [petsc-dev] GASM
by Mark F. Adams 30 Mar '12

30 Mar '12

Thanks, it seems to work but I have a memory leak. I use: ierr = PCGASMSetLocalSubdomains( subpc, sz, is, PETSC_NULL ); CHKERRQ(ierr); ierr = PetscFree( is ); CHKERRQ(ierr); and it looks like the ISs are not getting destroyed in GASM. Mark On Mar 29, 2012, at 9:35 PM, Dmitry Karpeev wrote: > Now it should work the way you intended. > Let me know if it doesn't, though. > > Dmitry. > > On Thu, Mar 29, 2012 at 7:49 PM, Mark F. Adams <mark.adams(a)columbia.edu> wrote: > > On Mar 29, 2012, at 11: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 :-) > > BTW, this is not a matter of being lazy, I need an eigen estimate of the smoothers preconditioned operator. In the past I created a new PC from the command line database (ugly), but this GASM smoother can not be reconstructed from the database (it uses the AMG aggregates). I could do a deep copy of the smoother but that would require two setups of the GASM PC, which would be ugly. > > Mark > >> >> Dmitry. >> > >

1 0

Re: [petsc-dev] Jed didn't like the directory private but he has no problem with finclude?
by Jed Brown 30 Mar '12

30 Mar '12

On Thu, Mar 29, 2012 at 20:19, Sean Farley <sean(a)mcs.anl.gov> wrote: > Since AR Jed felt we should change the name of include/private (and I >> agree it was appropriate) shouldn't we also change the name of >> include/finclude? It has the same problem of pollution when dumped in a >> --prefix location. >> >> Should it be petsc-fortran? Or petsc-fortran-include? > > > You can call PETSc from fortran? How quaint! How about > include/petsc-quaint? > I would call it petsc-fortran if we are going to rename it. It's not a conflict per se since the headers inside finclude/ are still namespaced. It also impacts normal Fortran users which the private rename does not. I don't feel strongly either way about doing the rename. We should probably start recommending the use of modules instead of the #include stuff that is currently required.

1 0

Re: [petsc-dev] Jed didn't like the directory private but he has no problem with finclude?
by Sean Farley 29 Mar '12

29 Mar '12

> > Since AR Jed felt we should change the name of include/private (and I > agree it was appropriate) shouldn't we also change the name of > include/finclude? It has the same problem of pollution when dumped in a > --prefix location. > > Should it be petsc-fortran? Or petsc-fortran-include? You can call PETSc from fortran? How quaint! How about include/petsc-quaint?

1 0

Jed didn't like the directory private but he has no problem with finclude?
by Barry Smith 29 Mar '12

29 Mar '12

Since AR Jed felt we should change the name of include/private (and I agree it was appropriate) shouldn't we also change the name of include/finclude? It has the same problem of pollution when dumped in a --prefix location. Should it be petsc-fortran? Or petsc-fortran-include? Barry

1 0

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

29 Mar '12

Now it should work the way you intended. Let me know if it doesn't, though. Dmitry. On Thu, Mar 29, 2012 at 7:49 PM, Mark F. Adams <mark.adams(a)columbia.edu>wrote: > > On Mar 29, 2012, at 11: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 :-) > > > BTW, this is not a matter of being lazy, I need an eigen estimate of the > smoothers preconditioned operator. In the past I created a new PC from the > command line database (ugly), but this GASM smoother can not be > reconstructed from the database (it uses the AMG aggregates). I could do a > deep copy of the smoother but that would require two setups of the GASM PC, > which would be ugly. > > Mark > > > Dmitry. > > >

1 0

Re: [petsc-dev] GASM
by Mark F. Adams 29 Mar '12

29 Mar '12

On Mar 29, 2012, at 11: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 :-) BTW, this is not a matter of being lazy, I need an eigen estimate of the smoothers preconditioned operator. In the past I created a new PC from the command line database (ugly), but this GASM smoother can not be reconstructed from the database (it uses the AMG aggregates). I could do a deep copy of the smoother but that would require two setups of the GASM PC, which would be ugly. Mark > > Dmitry. >

1 0

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

29 Mar '12

Okay, I see: refcnt is incremented in KSPGetPC(). On Thu, Mar 29, 2012 at 1:12 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > And refct is decremented from 2 to 1. > On Mar 29, 2012 12:04 PM, "Dmitry Karpeev" <karpeev(a)mcs.anl.gov> wrote: > >> 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

And refct is decremented from 2 to 1. On Mar 29, 2012 12:04 PM, "Dmitry Karpeev" <karpeev(a)mcs.anl.gov> wrote: > 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