> On 11 Sep 2019, at 3:46 PM, Smith, Barry F. <bsm...@mcs.anl.gov> wrote:
>
>
> The phrase Hermitian symmetric was originally an attempt to make the text
> clearer, but in fact it is confusing and wrong. The phrase Hermitian
> symmetric should be removed and just Hermitian used.
>
> Real matrices are either either both symmetric and Hermitian or not
> symmetric and not Hermitian
>
> Complex matrices can be set to symmetric or Hermitian. For SBAIJ this
> changes the meaning of the values in the matrix; for matrices with full
> storage this means the user is stating that the matrix values are actually
> symmetric or Hermitian in the storage.
>
> Currently for complex matrices one can state the matrix is both symmetric
> and Hermitian which would mean one is stating the imaginary parts are all
> zero; if this is the case then it doesn't matter if the
> MatMult_SeqSBAIJ_1_Hermitian() or the MatMult_SeqSBAIJ_1() is used for
> SeqBAIJ. Note that calling both of these doesn't mean the imaginary parts
> will be zeroed out, it is statement by the user that the imaginary parts are
> zero.
>
> For parallel matrices, even in debug node, checking the user is telling
> the truth when they set symmetric or Hermitian is considered too expensive
> so we just trust the user.
>
> With the replacement of Hermitian symmetric by Hermitian will the text
> now be clear or should more clarification be given in the manual pages (as
> above)?
I think it makes the text more clear.
However, it’s not very clear to me:
1) how to setup a SeqSBAIJ Mat as Hermitian, i.e., is MatSetOption(A,
MAT_SYMMETRIC, PETSC_FALSE); MatSetOption(A, MAT_HERMITIAN, PETSC_TRUE); OK?
2) why isn’t there more checks in MatSetOption_SeqSBAIJ. As we can all agree
one, if(MAT_SYMMETRIC and MAT_HERMITIAN), then there should be no error for bs
> 1, but on the contrary, isn’t (!MAT_SYMMETRIC and MAT_HERMITIAN and bs > 1)
problematic right now?
3) why any of those checks should be performed in MatSetOption_SeqSBAIJ.
Calling MatAXPY with two matrices of the same type with the same flags is
feasible no matter the value of bs.
Thanks,
Pierre
> Barry
>
>
> case MAT_HERMITIAN:
> #if defined(PETSC_USE_COMPLEX) /* MAT_HERMITIAN is a synonym for
> MAT_SYMMETRIC with reals */
> if (!A->assembled) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_ARG_WRONGSTATE,"Must
> call MatAssemblyEnd() first");
> if (A->cmap->n < 65536 && A->cmap->bs == 1) {
> A->ops->mult = MatMult_SeqSBAIJ_1_Hermitian_ushort;
> } else if (A->cmap->bs == 1) {
> A->ops->mult = MatMult_SeqSBAIJ_1_Hermitian;
> } else SETERRQ(PETSC_COMM_SELF,PETSC_ERR_SUP,"No support for Hermitian
> with block size greater than 1");
> #endif
>
>
>
> case MAT_SYMMETRIC:
> mat->symmetric = flg;
> if (flg) mat->structurally_symmetric = PETSC_TRUE;
> mat->symmetric_set = PETSC_TRUE;
> mat->structurally_symmetric_set = flg;
> #if !defined(PETSC_USE_COMPLEX)
> mat->hermitian = flg;
> mat->hermitian_set = PETSC_TRUE;
> #endif
> break;
> case MAT_HERMITIAN:
> mat->hermitian = flg;
> if (flg) mat->structurally_symmetric = PETSC_TRUE;
> mat->hermitian_set = PETSC_TRUE;
> mat->structurally_symmetric_set = flg;
> #if !defined(PETSC_USE_COMPLEX)
> mat->symmetric = flg;
> mat->symmetric_set = PETSC_TRUE;
> #endif
>
>
>
>
>> On Sep 11, 2019, at 5:55 AM, Pierre Jolivet via petsc-dev
>> <petsc-dev@mcs.anl.gov> wrote:
>>
>> (Putting back petsc-dev on c/c)
>> I don’t think you are the one that needs to do the changes.
>> There should be clarifications from the PETSc side of things, first.
>> From the man page your are quoting
>> (https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MATSEQSBAIJ.html):
>> 1) how to make a SBAIJ Mat Hermitian but not symmetric? Is this handled by
>> PETSc? Is this legal to do MatSetOption(A, MAT_SYMMETRIC, PETSC_FALSE)
>> followed by MatSetOption(A, MAT_HERMITIAN, PETSC_TRUE)? I think this is the
>> case where bs>1 is not handled internally by PETSc, so for this case it
>> should be OK to error out.
>> 2) “Hermitian symmetric” is a fancy way of saying that the matrix has no
>> imaginary part. Or is just “Hermitian" what is supposed to be written on the
>> page? In which case, how do you tell to PETSc that you are indeed dealing
>> with a matrix with no imaginary part.
>>
>> Thanks,
>> Pierre
>>
>>> On 11 Sep 2019, at 11:51 AM, Jose E. Roman <jro...@dsic.upv.es> wrote:
>>>
>>> Now I understand better. You are right. Maybe I should do some changes in
>>> SLEPc. I will think about this next week.
>>>
>>>
>>>> El 11 sept 2019, a las 11:38, Pierre Jolivet <pierre.joli...@enseeiht.fr>
>>>> escribió:
>>>>
>>>>
>>>>
>>>>> On 11 Sep 2019, at 11:21 AM, Jose E. Roman <jro...@dsic.upv.es> wrote:
>>>>>
>>>>> In
>>>>> https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MATSEQSBAIJ.html
>>>>> it says "To make it Hermitian symmetric you can call MatSetOption(Mat,
>>>>> MAT_HERMITIAN);" So my understanding is that in SBAIJ assumes
>>>>> MAT_SYMMETRIC and the user must set MAT_HERMITIAN if desired.
>>>>
>>>> Right, that is exactly what you do in STMatSetHermitian. You get from the
>>>> user a SBAIJ matrix (so SYMMETRIC = true), and you set yourself HERMITIAN
>>>> = true.
>>>>
>>>>> I don't think it makes sense to set both MAT_HERMITIAN and MAT_SYMMETRIC.
>>>>
>>>> Why? A symmetric (or Hermitian) matrix with no imaginary part is both
>>>> Hermitian and symmetric, so at least this set of options defines correctly
>>>> the structure of the matrix (which is not the case if you only assume it
>>>> is _either_ symmetric or Hermitian).
>>>>
>>>>> But I may be wrong because I find this part of PETSc very confusing.
>>>>>
>>>>>
>>>>>> El 11 sept 2019, a las 11:08, Jose E. Roman <jro...@dsic.upv.es>
>>>>>> escribió:
>>>>>>
>>>>>> Do you mean setting both flags MAT_HERMITIAN and MAT_SYMMETRIC? Is this
>>>>>> possible?
>>>>
>>>> It was possible before my commit for bs == 1, but not for bs > 1.
>>>>
>>>> At least now my tests are not failing.
>>>>
>>>>>>> El 11 sept 2019, a las 11:04, Pierre Jolivet
>>>>>>> <pierre.joli...@enseeiht.fr> escribió:
>>>>>>>
>>>>>>> Symmetric <=> a_ij = a_ji
>>>>>>> Hermitian <=> a_ij = conj(a_ji)
>>>>>>>
>>>>>>> Symmetric + Hermitian <=> a_ij = conj(a_ji) = a_ji <=> imag(a_ji) = 0
>>>>>>> \forall ij
>>>>>>>
>>>>>>> Or am I stupid?
>>>>>>>
>>>>>>>> On 11 Sep 2019, at 10:59 AM, Jose E. Roman <jro...@dsic.upv.es> wrote:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
