[petsc-dev] Fwd: MatSetValues with v=0

[Barry Smith]

  AFTER you first put values into the matrix and call MatAssemblyBegin/End() you can use 
MatSetValuesRow() to set an entire row (just the entries in that row that previously had been set). So if your problem somehow naturally gives you new matrix values a row at a time (sorted) then use MatSetValuesRow() for very fasted repeated setting of values. Note you can only set local rows with this.

  Barry



On Apr 17, 2014, at 3:01 PM, Eric Chamberland <Eric.Chamberland at giref.ulaval.ca> wrote:

> On 04/17/2014 03:47 PM, Jed Brown wrote:
>> Eric Chamberland <Eric.Chamberland at giref.ulaval.ca> writes:
>>> Now I noticed another thing while measuring performances (notice: I used
>>> a PETSc compiled with debugging=yes... please don't flame me...):
>>> 
>>> The first assembly for a 549252 square matrix takes me 4.505s but if i
>>> sort the indices passed to MAT_SET_VALUES (which I can do since I add
>>> only zeros) it takes only 1.655s!!!!!  Sorting the indices costs me only
>>> 0.4s...
>> 
>> How many nonzeros per row?  If you pass unsorted entries to the first
>> assembly, insertion/row management will degrade from O(nnz*log(nnz)) to
>> O(nnz^2).  This doesn't matter for short rows.
>> 
> 
> Mostly 52 nz per rows.
> 
> Total nz is 28 086 003;
> 
>> Meanwhile, PETSc does not know if you pass all entries for a row in one
>> call or will be calling several times.  If you pass all the entries, it
>> could make sense for _us_ to sort for you, but otherwise, it doesn't get
>> around the more expensive row shifting.
> 
> This is exactly what I am doing: I pass all the entries for identical lines... (if any).
> 
>> 
>>> Is this a normal behavior?  If so, it means we shall number our DOF in a
>>> way that the elementary matrices have DOF # that are mostly sorted while
>>> doing the "standard" assembly?
>> 
>> After the first assembly, it shouldn't make much difference, though
>> there are mild optimizations we could make if people wanted to guarantee
>> sorted input.  (It's not clear these matter; usually assembly is faster
>> after the first time.)
>> 
> 
> ok.
> 
> Thank you!
> 
> Eric
>