On Sep 8, 2013, at 1:14 PM, Jed Brown <[email protected]> wrote: > Barry Smith <[email protected]> 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
