Perhaps the name MatScatter should then be changed to MatScatterAdd to clarify the meaning?
I appreciate your arguments. Here is my issue (which is only indirectly related to this whole discussion). I an ideal PETSc, I think that if one creates a VecScatter where two different locations are mapped to the same output location and then uses it with INSERT_VALUES I think that should generate an error. To implement this we could have the scatter create detect this case and set a flag in the scatter, then if the scatter is used with insert and the flag is set generate an error. The checking could be wrapped in an #if defined(PETSC_USE_DEBUGGING). Barry On Apr 8, 2009, at 12:30 PM, Jed Brown wrote: > On Wed 2009-04-08 12:12, Barry Smith wrote: >> >> On Apr 8, 2009, at 3:11 AM, Jed Brown wrote: >> >>> On Tue 2009-04-07 21:02, Barry Smith wrote: >>>> >>>> Jed, >>>> >>>> Please remind me of what the simplest fix is? Can we just zero >>>> the >>>> vector before the scatter for the MatMult and MatMultTranspose? >>>> What about for MatMultAdd and MatMultTransposeAdd, does anything >>>> need to >>>> be done? >>> >>> The simplest fix is to zero the vector before and always use >>> ADD_VALUES. >> >> Why ADD_VALUES? I don't see that as being any more "correct" then >> INSERT_VALUES >> in the case when two different x locations are assigned to a single y >> location. > > * It is consistent with MatMultAdd > * It is deterministic when the destination IS is not injective > * It is equivalent to INSERT_VALUES when the destination IS is > injective > >> Perhaps the matrix class based on the scatter should have an option >> allowing the >> user to determine add or insert? MatScatterSetType()? > > I don't see the point. INSERT_VALUES is an optimization that you can > use when the destination IS is injective (but really only useful > when it > is also surjective so that you can skip VecZeroEntries [*]). > > [*] For some destination IS, nontemporal stores (only possible with > INSERT_VALUES) might improve cache performance. Such > (architecture-dependent) cache considerations aside, I would not > expect > a performance difference between INSERT_VALUES and ADD_VALUES since > they > will be bandwidth limited. This means that INSERT_VALUES is only an > optimization when the destination IS is bijective so that > VecZeroEntries can be skipped. > > Jed