[petsc-dev] sor smoothers

[Barry Smith]

On Sep 8, 2013, at 1:14 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
>> We should add MatResidual() to the basic Mat methods (note this is the
>> same as MatMultSub() if we had such a thing) then all the many places
>> in PETSc where we have MatMult(); MatAXPY/AYPX(); 
> 
> * VecAXPY

   I did a search of MatMult(), we have a variety of inconsistent ways of computing the residual :-)

> 
>> can be replace with that one call and PCMGSetResidual() and
>> PCMGResidualDefault() would just disappear.  We could have
>> MatResidual_Default() that did the usual MatMult followed by VecAYPX()
>> but each Mat implementation can implement an optimized one if they
>> want.
> 
> An alternative would be to add a scalar parameter to MatMultAdd.

   MatResidual() is an important enough case to merit its own method. The odd ball scalar parameter that is not 1 or -1 is so extremely rare as to lead to confusion instead of useful generality. 

> 
> To make the caching safe, the Mat impl would record the State of the Vec
> for which it was caching a triangular application.

   I said that.

> 
> Perhaps PetscObjects should get a 64-bit unique ID assigned by a global

   Why 64 bit? Surely we will never have more than 2 billion objects created?

> counter, or even a slightly longer hash of information that should never
> repeat.  Caching the pointer leaves the ABA problem.

  We currently have 
  h->id                    = idcnt++;
  in PetscHeaderCreate_Private(). 

   The id is not consistent across processes for a given object but I don't think that matters. Why can't we just stash this value? I think this value plus the Vec/Mat state uniquely define the values in the Vec/Mat.  

There is a possibility of some processes having the same state and others different ones and thus errors due to different functions being used; for example if one process called VecGetArrayWrite() but another one didn't. This is perverse so ….?

  Barry