[petsc-dev] Integrating PFLOTRAN, PETSC & SAMRAI

[Barry Smith]

  So are you suggesting we replace 




PetscErrorCode  VecAXPY(Vec y,PetscScalar alpha,Vec x)
{
  PetscErrorCode ierr;

  PetscFunctionBegin;
  PetscValidHeaderSpecific(x,VEC_CLASSID,3);
  PetscValidHeaderSpecific(y,VEC_CLASSID,1);
  PetscValidType(x,3);
  PetscValidType(y,1);
  PetscCheckSameTypeAndComm(x,3,y,1);
  PetscCheckSameSizeVec(x,y);
  if (x == y) SETERRQ(((PetscObject)x)->comm,PETSC_ERR_ARG_IDN,"x and y cannot be the same vector");
  PetscValidLogicalCollectiveScalar(y,alpha,2);

  ierr = PetscLogEventBegin(VEC_AXPY,x,y,0,0);CHKERRQ(ierr);
  ierr = (*y->ops->axpy)(y,alpha,x);CHKERRQ(ierr);
  ierr = PetscLogEventEnd(VEC_AXPY,x,y,0,0);CHKERRQ(ierr);
  ierr = PetscObjectStateIncrease((PetscObject)y);CHKERRQ(ierr);
  PetscFunctionReturn(0);


with the equivalent of 

PetscErrorCode  VecAXPY(Vec y,PetscScalar alpha,Vec x)
{
  PetscErrorCode ierr;

  PetscFunctionBegin;
  PetscValidHeaderSpecific(x,VEC_CLASSID,3);
  PetscValidHeaderSpecific(y,VEC_CLASSID,1);
  PetscValidType(x,3);
  PetscValidType(y,1);
  PetscCheckSameTypeAndComm(x,3,y,1);
  PetscCheckSameSizeVec(x,y);
  if (x == y) SETERRQ(((PetscObject)x)->comm,PETSC_ERR_ARG_IDN,"x and y cannot be the same vector");
  PetscValidLogicalCollectiveScalar(y,alpha,2);

  ierr = PetscLogEventBegin(VEC_AXPY,x,y,0,0);CHKERRQ(ierr);

  { PetscInt statey = ((PetscObject)y)->state;
  ierr = (*y->ops->axpy)(y,alpha,x);CHKERRQ(ierr);
   if (((PetscObject)y)->state ==  statey) SETERRQ("did not increase state!"}


  ierr = PetscLogEventEnd(VEC_AXPY,x,y,0,0);CHKERRQ(ierr);
  PetscFunctionReturn(0);

 I like very much the idea, just do not like my implementation, especially that statey variable (what if two vectors are changed in some routine, can the proposed macros handle that?).

  If someone proposes a good set of macros I'll implement it.


   Barry


On Jun 6, 2011, at 4:56 PM, Jed Brown wrote:

> On Mon, Jun 6, 2011 at 23:49, Boyce Griffith <griffith at cims.nyu.edu> wrote:
> But if the model is that the Vec implementation is responsible for updating the state, then would it be better if PETSc did NOT increase the state, e.g., in calls to VecAXPY, or MatVecMult?  It seems like it might be better if it did not, so that if one has a non-"compliant" implementation, one finds out more quickly that their code is broken.
> 
> Good point. We could replace the increments with debug-mode checks that the state actually did get incremented, with errors if it didn't. There are perhaps 50 call sites to update. It would not be a big deal.
> 
> This would be great for SNESComputeFunction() too because a common mistake is to forget to put anything in the output vector. This would check that they at least got access to the vector (though we still couldn't confirm that they put anything into it).