MatMult_Scatter woes

[Jed Brown]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090408/44582d46/attachment.sig>