Hi Vaclav,
> On 21 Jun 2019, at 12:14, Hapla Vaclav via petsc-dev <[email protected]>
> 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.
Lawrence
