Not sure if I understand you. Do you mean that a complex SBAIJ Mat with MAT_HERMITIAN flag can be assumed to have zero imaginary part? I don't think so. This matrix should have real diagonal entries, but off-diagonal entries should be allowed to have nonzero imaginary part. This is what is done in MatMult_SeqSBAIJ_1_Hermitian(), where off-diagonal entries are conjugated when used for the strict lower triangular part. So I guess the right fix is to implement MatMult_SeqSBAIJ_2_Hermitian(), MatMult_SeqSBAIJ_3_Hermitian() and so on with appropriate use of PetscConj().
Jose > El 11 sept 2019, a las 10:36, Pierre Jolivet <pierre.joli...@enseeiht.fr> > escribió: > > Nevermind, this is the wrong fix. > The proper fix is in PETSc. It should not error out if the matrix is also > symmetric. > Indeed, complex symmetric Hermitian => complex with no imaginary part. > Thus all operations like MatMult, MatMultHermitianTranspose, Cholesky… will > work for bs > 1, since all is filled with zeroes. > I will take care of this, I’m c/c’ing petsc-dev so that they don’t have to > “reverse engineer” the trivial change to MatSetOption_SeqSBAIJ. > > Sorry about the noise. > > Thank you, > Pierre > >> On 10 Sep 2019, at 8:37 AM, Pierre Jolivet <pierre.joli...@enseeiht.fr> >> wrote: >> >> Hello, >> Could you consider not setting MAT_HERMITIAN here >> http://slepc.upv.es/documentation/current/src/sys/classes/st/interface/stsles.c.html#line276 >> when using SBAIJ matrices with bs > 1? >> This makes PETSc error out with >> # [1]PETSC ERROR: No support for this operation for this object type >> # [1]PETSC ERROR: No support for Hermitian with block size greater than 1 >> >> The change does not bring any regression, since PETSc is always giving an >> error without it, but on the contrary, it improves the range of >> applicability of SLEPc, e.g., for complex Hermitian problems with SBAIJ >> matrices and bs > 1 that _don’t_ require the flag MAT_HERMITIAN set to true. >> >> Thanks, >> Pierre >
