Bugs fixed related to transposed operations

[jesusbonilla]

I noticed a few minor bugs related to transposed operations (one related to issue #1070 ).

I have fixed all the ones I knew how to do it, but I believe there is still one more bug that I am no sure how to fix. In /src/parcsr_mv/communicationT.c col_starts is used as if it was an array of length num_procs+1, but this is no longer true.

hypre/src/parcsr_mv/communicationT.c

Line 262 in ee74c20

if (col_map_offd[k] >= col_starts[i] &&

Is a possible fix the communication of column start positions and locally constructing a different col_starts_ array with all the column starts for all process, or is there a better alternative with communication involved?

[victorapm]

Hi @jesusbonilla, thank you for the proposed fix!

It seems that the routine hypre_ParCSRAAt and related ones such as hypre_MatTCommPkgCreate became quite outdated and additional fixes to them need to be implemented. I will bring this up in our next hypre team meeting and will update you after we make a plan.

Assuming that your goal is to multiply two rectangular matrices (are they tall-and-skinny?), I would suggest, for now, to compute the transpose explicitly and perform the multiplication:

hypre_ParCSRMatrixTranspose(A, At, 1);
AAt = hypre_ParCSRMatMat(A, At);

This has the advantage of being GPU-enabled wrt hypre_ParCSRAAt, but the disadvantage of using more memory.

[jesusbonilla]

Hi @victorapm thanks for taking a look to it and for your suggestions!

Yes, indeed the matrix is tall-and-skinny. I'll follow your suggestion of explicitly computing the transpose. For the moment, performance shouldn't be an issue, and I'll just update my code once hypre_ParCSRAAt is updated. Thanks!