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