1. psb_?_hdia_csmv.f90: with beta /= 0 the kernel scaled y(i) instead of
y(rdisp+i), so every hack after the first used the wrong element and
the result was silently wrong. Verified against CSR: the error was
1.08e+02 on a 1000x1000 tridiagonal test, now 3.6e-15.
2. psb_?_cp_dia_to_coo.f90: the file did not use psi_ext_util_mod, so the
call to psi_?_xtr_coo_from_dia had no explicit interface and the
optional rdisp argument was seen as present with a garbage value.
Any conversion out of DIA crashed. Added the module, as the HDIA
version already does.
3. psi_?_xtr_coo_from_dia.f90: the extraction wrote one COO entry per
stored position, padding zeros included, while the caller sizes the
buffer with get_nzeros(). Skip the zeros, which also keeps the
round trip DIA -> COO -> DIA exact in the number of nonzeros.
psb_?_cp_dia_to_coo.f90 now calls set_nzeros with the count that the
extraction returns.
4. psb_?_cp_hdia_from_coo.f90: diaOffsets holds one integer per diagonal
per hack, but was allocated with hacksize*iszd, so 31/32 of the array
was never used. On a 40^3 pdegen matrix the format occupied 5,314,884
bytes instead of 3,601,204 (-32%); at 500^3 it would waste about
3.4 GB per process.
5. psb_?_cp_hdia_from_coo.f90: a%nzeros counted the padded positions
rather than the nonzeros, so get_nzeros() returned 442,222 instead of
438,400 on the same matrix, inflating the MFLOPS of every benchmark
and breaking the comparison with the other formats.
Stack-1
sfilippone
sfilippone