[petsc-dev] is VecGetValuesSection correct?

Hapla Vaclav vaclav.hapla at erdw.ethz.ch
Fri Jun 21 07:32:21 CDT 2019



On 21 Jun 2019, at 13:58, Lawrence Mitchell <wence at gmx.li<mailto:wence at gmx.li>> wrote:

Hi Vaclav,

On 21 Jun 2019, at 12:14, Hapla Vaclav via petsc-dev <petsc-dev at mcs.anl.gov<mailto:petsc-dev at mcs.anl.gov>> wrote:

VecGetValuesSection() returns pointer values obtained as follows:

VecGetArray(v, &baseArray);
*values = &baseArray[s->atlasOff[p]];
VecRestoreArray(v, &baseArray);

It looks to me scary.
VecGetArray manpage says: If the underlying vector data is not stored in a contiguous array this routine will copy the data to a contiguous array and return a pointer to that.
VecRestoreArray manpage says: For any special vectors that do not store local vector data in a contiguous array, this routine will copy the data back into the underlying vector data structure from the array obtained with VecGetArray().

So I guess VecRestoreArray() is free to destroy that contiguous array, right?
In this case values would point to some nonsensical location in memory.

Yes, for example

VecGetArray_Nest(Vec X, PetscScalar **x)
{
 // allocate space
 ierr = PetscMalloc1(m,x);CHKERRQ(ierr);
 // copy in elided
}

VecRestoreArray_Nest(Vec X, PetscScalar **x)
{
  // copy out elided
  ierr = PetscFree(*x);CHKERRQ(ierr);
}

So VecGetValuesSection is definitely not safe if using VecType == NEST.

I suspect the right thing to do is to make VecGetValuesSection be a method (rather than a single VecSeq implementation). VecNest doesn't support SetValues/GetValues, so arguably it just shouldn't support SetValuesSection/GetValuesSection.

Thanks, Lawrence. Sounds good. I can do that like this.

Vaclav


Lawrence

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190621/00b9efe9/attachment-0001.html>


More information about the petsc-dev mailing list