[petsc-dev] Removing VecGetArrayPrivate3

[Jed Brown]

On Wed, Nov 24, 2010 at 23:18, Barry Smith <bsmith at mcs.anl.gov> wrote:

> Presumably. Or we could pull the reference counting up into the base method
> and only call the VecGet/RestoreArray[Read]() method the first/last time so
> that each implementation does not need to manage it. For "standard" PETSc
> vectors the counting is not needed except for checking that the user has
> done things correctly.
>
> >  This violates the present API implied by VecGetArray_Seq:
> >
> > if (vin->array_gotten) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_ORDER,"Array has
> already been gotten for this vector,you may\nhave forgotten a call to
> VecRestoreArray()");
>
>     This particular piece of code should not normally (ever) be triggered.
> Do you have code where this error is generated? Please let me know where.
> Eventually this check will be tossed.
>

When is VecGetArray_Seq actually executed?  I thought it always fell under
the x->petscnative clause.


> > Do you want to relax this restriction on the API (placing extra burden on
> the implementation), or revert the patch?
>
>     The current model (which does not have code to check if it is violated,
> except for the code fragment above you found) is that multiple
> VecGetArrayRead() reads can be done on the same Vec but only a single
> VecGetArray[Write]().  A write can be called on a Vec that has an open
> VecGetArrayRead().
>

I think this is correct behavior, though not strictly conforming from
Fortran.  C users can restrict-qualify when they know that they have
distinct memory.


> After the VecRestoreArray[Write]() is called the values are copied back to
> their original location, when all reads and writes are closed the array can
> be freed. Restoring the Write array results in an increase in the Vec state.
>

Could VecGetArray[Write] also set a flag so that the usual Vec operations
error when write access is checked out.

Jed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20101124/8396a8c3/attachment.html>