Re: [petsc-users] Calling MatDestroy on MatGetDiagonalBlock

2016-01-05 Thread Barry Smith

> On Jan 5, 2016, at 7:29 PM, Jed Brown  wrote:
> 
> Matthew Knepley  writes:
> 
>> How devastating would it be for Deal.II if we renamed them
>> MatCreateSubMatrix()? ;)
> 
> I know it's consistent with respect to reference counting semantics, but
> it might be harder for new users to find when searching the docs.  I
> have no data either way.  I recall discussing years ago that having
> paired MatGetSubMatrix/MatRestoreSubMatrix would simplify bookkeeping in
> PCFieldSplit and some common user code.

  Hmm, I don't recall this at all but it sounds like an intriguing idea.

  Barry

> 
> If the name is changed, it's easy to support the deprecated name from C.



Re: [petsc-users] Calling MatDestroy on MatGetDiagonalBlock

2016-01-05 Thread Jed Brown
Matthew Knepley  writes:

> How devastating would it be for Deal.II if we renamed them
> MatCreateSubMatrix()? ;)

I know it's consistent with respect to reference counting semantics, but
it might be harder for new users to find when searching the docs.  I
have no data either way.  I recall discussing years ago that having
paired MatGetSubMatrix/MatRestoreSubMatrix would simplify bookkeeping in
PCFieldSplit and some common user code.

If the name is changed, it's easy to support the deprecated name from C.


signature.asc
Description: PGP signature


Re: [petsc-users] Calling MatDestroy on MatGetDiagonalBlock

2016-01-05 Thread Matthew Knepley
How devastating would it be for Deal.II if we renamed them
MatCreateSubMatrix()? ;)

   Matt

On Tue, Jan 5, 2016 at 5:53 PM, Barry Smith  wrote:

>
>   Yeah, looks like MatGetSubMatrix() and MatGetSubMatrices() didn't get
> renamed to the "current" approach.
>
>Barry
>
> > On Jan 5, 2016, at 5:46 PM, Bhalla, Amneet Pal S 
> wrote:
> >
> >
> >
> >> On Jan 5, 2016, at 3:32 PM, Barry Smith  wrote:
> >>
> >> So  get -> no destroy
> >>create -> destroy
> >
> > Is MatGetSubMatrices() exception to this rule? The manual says to call
> the destroy() function after done with it.
> >
> >
> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatGetSubMatrices.html
>
>


-- 
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


Re: [petsc-users] Calling MatDestroy on MatGetDiagonalBlock

2016-01-05 Thread Barry Smith

  Yeah, looks like MatGetSubMatrix() and MatGetSubMatrices() didn't get renamed 
to the "current" approach.

   Barry

> On Jan 5, 2016, at 5:46 PM, Bhalla, Amneet Pal S  wrote:
> 
> 
> 
>> On Jan 5, 2016, at 3:32 PM, Barry Smith  wrote:
>> 
>> So  get -> no destroy
>>create -> destroy
> 
> Is MatGetSubMatrices() exception to this rule? The manual says to call the 
> destroy() function after done with it. 
> 
> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatGetSubMatrices.html



Re: [petsc-users] Calling MatDestroy on MatGetDiagonalBlock

2016-01-05 Thread Bhalla, Amneet Pal S


On Jan 5, 2016, at 3:32 PM, Barry Smith 
mailto:bsm...@mcs.anl.gov>> wrote:

So  get -> no destroy
   create -> destroy

Is MatGetSubMatrices() exception to this rule? The manual says to call the 
destroy() function after done with it.

http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatGetSubMatrices.html


Re: [petsc-users] Calling MatDestroy on MatGetDiagonalBlock

2016-01-05 Thread Barry Smith

  In general XXXGetYYY() do not increase the reference count and you should not 
destroy. Some XXXGetYYY() have a corresponding XXXRestoreYYY(). 

  XXXCreateYYY() DO increase the reference count and should have destroy called.

  So  get -> no destroy
create -> destroy

  Barry

In the past we were not consistent between the usages but now I think it is 
consistent.


> On Jan 5, 2016, at 5:24 PM, Bhalla, Amneet Pal S  wrote:
> 
> 
> 
>> On Jan 5, 2016, at 3:20 PM, Dave May  wrote:
>> 
>> This statement would imply that in the absence of calling 
>> PetscObjectReference() yourself, you should not call MatDestroy() on the 
>> matrix returned
> 
> Got it. Thanks!
> 



Re: [petsc-users] Calling MatDestroy on MatGetDiagonalBlock

2016-01-05 Thread Bhalla, Amneet Pal S


On Jan 5, 2016, at 3:20 PM, Dave May 
mailto:dave.mayhe...@gmail.com>> wrote:

This statement would imply that in the absence of calling 
PetscObjectReference() yourself, you should not call MatDestroy() on the matrix 
returned

Got it. Thanks!



Re: [petsc-users] Calling MatDestroy on MatGetDiagonalBlock

2016-01-05 Thread Satish Balay
Looking at example usages in src/ksp/pc/impls/bjacobi/bjacobi.c or
src/ksp/pc/impls/gasm/gasm.c - there is no call to MatDestroy..
[or MatRestoreDiagonalBlock]

Satish

On Tue, 5 Jan 2016, Bhalla, Amneet Pal S wrote:

> Hi Folks,
> 
> Is it safe to call MatDestroy on the sequential matrix returned by 
> MatGetDiagonalBlock() after it’s no longer used?
> 
> 
> Thanks,
> 
> — Amneet
> =
> Amneet Bhalla
> Postdoctoral Research Associate
> Department of Mathematics and McAllister Heart Institute
> University of North Carolina at Chapel Hill
> Email: amn...@unc.edu
> Web:  https://abhalla.web.unc.edu
> =
> 
> 


Re: [petsc-users] Calling MatDestroy on MatGetDiagonalBlock

2016-01-05 Thread Dave May
The manpage

http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatGetDiagonalBlock.html
indicates the reference counter on the returned matrix (a) isn't
incremented.

This statement would imply that in the absence of calling
PetscObjectReference() yourself, you should not call MatDestroy() on the
matrix returned.
If you do call MatDestroy(), a double free will occur when you call
MatDestroy() on the parent matrix from which you pulled the block matrix
out of.

Cheers,
  Dave

On 6 January 2016 at 00:14, Bhalla, Amneet Pal S 
wrote:

> Hi Folks,
>
> Is it safe to call MatDestroy on the sequential matrix returned by
> MatGetDiagonalBlock() after it’s no longer used?
>
>
> Thanks,
>
> — Amneet
> =
> Amneet Bhalla
> Postdoctoral Research Associate
> Department of Mathematics and McAllister Heart Institute
> University of North Carolina at Chapel Hill
> Email: amn...@unc.edu
> Web:  https://abhalla.web.unc.edu
> =
>
>