Jed,
Should this utilize the Get/Restore paradigm?
If not should the name be different to prevent confusion? Currently we
have
XXXCreate --> user needs to call a destroy
XXXXGetYYY --> user needs to call a restore (but not always?)
Could we introduce say
XXXAccessYYY --> user does not call destroy or restore ?
Barry
> On May 19, 2017, at 9:20 AM, Jed Brown <[email protected]> wrote:
>
> Thanks. I just pushed this.
>
> commit 96a6f12955a790d77f6eb7eb6b1dcf9dd5e1cf30
> Author: Jed Brown <[email protected]>
> Date: Fri May 19 08:17:45 2017 -0600
>
> MatISGetLocalMat: add note on reference counting
>
> Reported-by: Franck Houssen <[email protected]>
>
> diff --git a/src/mat/impls/is/matis.c b/src/mat/impls/is/matis.c
> index dc4a894aae..287c0aa554 100644
> --- a/src/mat/impls/is/matis.c
> +++ b/src/mat/impls/is/matis.c
> @@ -837,6 +837,9 @@ PetscErrorCode MatISGetLocalMat_IS(Mat mat,Mat *local)
> matrix and want to provide it to the inner matrix object to improve the
> performance
> of the MatSetValues() operation.
>
> + This function does not increase the reference count for the local Mat. Do
> not destroy it and do not attempt to use
> + your reference after destroying the parent mat.
> +
> .seealso: MATIS
> @*/
> PetscErrorCode MatISGetLocalMat(Mat mat,Mat *local)
>
> Franck Houssen <[email protected]> writes:
>
>> Hello,
>>
>> Do I need to MatDestroy the local matrix returned by MatISGetLocalMat ? (the
>> global matrix has been created with MatCreateIS)
>>
>> Tried to look in the source tree... But I'am not sure to get the answer: in
>> petsc-3.7.6/src/mat/impls/is/matis.c, MatISGetLocalMat seems to call
>> MatISGetLocalMat_C, but, I can't find MatISGetLocalMat_C in the source tree
>> !?...
>>
>> Franck
