[petsc-dev] Removing VecGetArrayPrivate3

Barry Smith bsmith at mcs.anl.gov
Wed Nov 24 16:47:22 CST 2010

On Nov 24, 2010, at 4:36 PM, Jed Brown wrote:

> 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.

   It would be executed if Seq was NOT a petscnative, but since it is a petscnative it should never get called :-(

> > 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.

   Not sure exactly how to do this. I  think I want each implementation to do whatever checking is appropriate for its data storage. For example, one can do a VecDot() with a native Vec that is currently gotten with a read or a write but for implementations that make a copy with the get array they cannot. Or the implementation could turn off the assembled flag while the array is gotten.


> Jed

More information about the petsc-dev mailing list