[petsc-dev] [petsc-users] Column #j is wrong in parallel from message "Inserting a new nonzero (i, j) into matrix"

[Eric Chamberland]

Hi Barry,

On 03/25/2015 07:25 PM, Barry Smith wrote:
>      This is an issue with any use of "nested" matrices (of which MPIBAIJ is a special, two level case). One way we could handle this is (I think universally) would be to introduce a unique PETSC_ERR_MAT_ENTRY_NONZERO error flag and then when any outer MatSetValues() calls an inner MatSetValues() check the error code and if this one print an error message with its level of row and column indices. So for example
>
>    Inside MatSetValuesBlocked_MPIBAIJ()
>
>    ierr = MatSetValuesBlocked_SeqBAIJ(baij->B,1,&row,1,&col,barray,addv);
>    if (ierr == PETSC_ERR_MAT_ENTRY_NONZERO) (*PetscErrorPrintf)("%s Matrix row and column block indices (%d %d)\n",__FUNC__,im[i],in[j]);
>    CHKERRQ(ierr);
>
>    The resulting error message would look something like
>
> [0]PETSC ERROR: MatSetValuesBlocked_SeqBAIJ() line 564 in /home/mefpp_ericc/petsc-3.5.3/src/mat/impls/baij/mpi/mpibaij.c Inserting a new nonzero (135, 9) into matrix
> ... a stack trace line or two here
> [0] PETSC ERROR: MatSetValuesBlocked_MPIBAIJ() line ... Matrix row and column block indices (135,537)

I would prefer either:
#1 - Inserting a new nonzero on line 135.  (internal col_identifier(not 
number, hash??) 9)
#2-  and then, for the remaining, what you proposed is correct.

Maybe it would worth to mention (or not?) that these (135,537) are 
global indices... so there is no possible confusion... anyway, even if 
this message is long, it is there to help the faulty user... ;-)

> In three level nesting there would be three sets of indices.
>
> We could use a macro to handle the error (to minimize the ugliness of the code).
>
> Is this worth pursing? The resulting messages are still a bit cryptic and ugly but at least they provide the user with correct information as opposed to the current situations where for nested matrices it is meaningless misleading numbers.
>
> The only other alternative I see is passing the global numbers all the way down in the calls (as extra variables) which seems pretty bad.
>
>   Any other thoughts?

My thought is:: the time you spend correcting this, will result in time 
saving to other who encounter the problem...  your paying it forward... ;-)

anyway, thanks for the upcoming fix! :-)

Eric