[petsc-users] MatChop
Stefano Zampini
stefano.zampini at gmail.com
Fri May 21 13:12:19 CDT 2021
> 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
More information about the petsc-users
mailing list