MatMult_Scatter woes

[Barry Smith]

    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