On Nov 24, 2010, at 3:51 PM, Jed Brown wrote:
> I thought the purpose of this function was to avoid calling VecGetArray
> multiple times on identical arguments.
Yes, that was the purpose.
> In particular, consider a Vec implementation that was not backed by a
> contiguous array. Must these implementations keep a reference count of how
> many times the same array was checked out?
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.
>
> 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(). 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.
All those VecGetArrayPrivateXXX() stuff was too complicated and messy, I
did not like it. Hideously complicated crap for something very simple.
Please let me know specific concerns you have with the "new" model so I can
make sure that everything works.
Barry
>
> Jed
