[petsc-dev] vec/vec/examples/tests/ex37.c "Nest vector functionality. has bugs

Jed Brown jed at 59A2.org
Sun Feb 20 14:07:03 CST 2011

On Sun, Feb 20, 2011 at 20:52, Barry Smith <bsmith at mcs.anl.gov> wrote:

>  ierr = VecDestroy(a);CHKERRQ(ierr);   ierr = VecDestroy(b);CHKERRQ(ierr);
>  ierr = VecAssemblyBegin(X);CHKERRQ(ierr);
>  ierr = VecAssemblyEnd(X);CHKERRQ(ierr);
>  ierr = VecMax( b, &index, &val );CHKERRQ(ierr);
>  PetscPrintf( PETSC_COMM_WORLD, "(max-b) = %f : index = %d \n", val, index
> );
>  b is destroyed and then used later.

Well, sort of. The Vec is not actually destroyed because the VecNest X
retains a reference. VecDestroy is called to relinquish ownership, not to
actually free the memory. Although this is perhaps not very pretty, neither
is calling PetscObjectDereference((PetscObject)b) for the same purpose. I
think that waiting until the end of the function body to call VecDestroy is
harder to reason about: when you read the function from the top down,
ownership becomes ambiguous and you have to scan to the end of the function
body to find out who keeps ownership.

In this example, the max could easily be computed before creating X, but I
guess we need a style guideline for other cases where we want to relinquish
ownership, but still be able to inspect. The verbose choice is to VecDestroy
and then immediately call VecNestGetSubVec (a low-level function that I
would prefer people not need to call very often) or VecGetSubVector (the
generic function, but you need index sets for that, not just PETSC_NULL) to
get a non-ownership reference to the same thing you passed in.

Or still use VecDestroy, but always include a comment about it just
relinquishing ownership. I realize that usage conflicts with your plan to
make XXDestroy() or XXDestroy_() or something zero the pointer (which by no
means prevents stale references, but takes care of some of the obvious
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110220/6853a111/attachment.html>

More information about the petsc-dev mailing list