[petsc-users] MatChop

[Stefano Zampini]

> On 21 May 2021, at 8:10 PM, Lawrence Mitchell <wence at gmx.li> wrote:
> 
> 
> 
>> On 21 May 2021, at 17:53, Stefano Zampini <stefano.zampini at gmail.com> wrote:
>> 
>>> I see, anyway you do not need the check if the loop range [rStart,rEnd). So now I don’t understand why the loop must be [rStart,rStart+maxRows], Matt?
>>> 
>>> It is terrible, but I could not see a way around it. We want to use MatGetRow() for each row, but that requires an assembled matrix.
>> 
>> What is the use case for calling MatChop on an unassembled matrix ?
> 
> It's rather that the matrix is modified "through the front door" by just calling MatSetValues repeatedly to replace the small values with zero. This is because an in-place modification of the matrix would require a method for each matrix type.
> 

If the matrix is assembled, this procedure will not insert new values, nor replace old ones if we set MatSetOption(MAT_IGNORE_ZEROENTRIES,PETSC_FALSE). 
This should never fail, or am I wrong?


> So the process is:
> 
> for each row:
>    rowvals = MatGetRow(row)
>    rowvals[abs(rowvals) < tol] = 0
>    MatSetValues(rowvals, ..., INSERT)
>    MatRestoreRow(row)
>    MatAssemblyBegin/End <- so that the next MatGetRow does not error.
> 
> Now, one "knows" that this assembly will not need to communicate (because you only set local values), but the automatic state tracking can't know this.
> 
> A disgusting hack that is tremendously fragile would be to do:
> 
> for each row:
>    ...
>    mat->assembled = PETSC_TRUE
> mat->assembled = PETSC_FALSE
> MatAssemblyBegin/End
> 
> But I would probably refuse to accept that could :)
> 
> Lawrence