<div dir="ltr"><div class="gmail_extra">Barry,</div><div class="gmail_extra"><br></div><div class="gmail_extra">When users apply Cholesky to a non-symmetric matrix, </div><div class="gmail_extra">petsc uses his upper half matrix and would produce incorrect solutions without user's knowledge.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Adding such check under "<span style="color:rgb(80,0,80)">#PETSC_USE_DEBUG", user sees</span></div><div class="gmail_extra"><span style="color:rgb(80,0,80)">1) his code crashes when matrix is non-symmetric</span></div><div class="gmail_extra"><span style="color:rgb(80,0,80)">or</span></div><div class="gmail_extra"><span style="color:rgb(80,0,80)">2) too slow due to checking, which prompts user to set symmetric flag.</span></div><div class="gmail_extra"><span style="color:rgb(80,0,80)">I do not see any harm to call </span>MatIsSymmetric() in this situation.</div><div class="gmail_extra"><span style="color:rgb(80,0,80)"><br></span></div><div class="gmail_extra"><font color="#500050">Hong</font></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 29, 2017 at 10:57 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
No, never do the MatIsSymmetric() that was me just "thinking aloud" in my first mail<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
Barry<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
> On Sep 29, 2017, at 8:33 AM, Hong <<a href="mailto:hzhang@mcs.anl.gov">hzhang@mcs.anl.gov</a>> wrote:<br>
><br>
> Taking both suggestions, how about<br>
><br>
> 2) Tests:<br>
> a) complex build && ftype==CHOLESKY:<br>
> if (mat->hermitian) throw an "not supported" error<br>
><br>
> b) all builds:<br>
> if (!mat->sbaij && (CHOLESKY || ICC))<br>
> if (!mat->symmetric) //user does not indicate mat is symmetric<br>
> #PETSC_USE_DEBUG<br>
> call MatIsSymmetric(mat,0.0,&symm)<br>
> if (!symm) throw an error<br>
> #else<br>
> throw an error<br>
> #endif<br>
><br>
> Hong<br>
><br>
> On Fri, Sep 29, 2017 at 10:25 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> No I don't want you to actually check if the matrix is symmetric (too expensive) just throw an error if the user has not indicated the appropriate properties of the matrix<br>
><br>
><br>
> > On Sep 29, 2017, at 8:19 AM, Hong <<a href="mailto:hzhang@mcs.anl.gov">hzhang@mcs.anl.gov</a>> wrote:<br>
> ><br>
> > Thanks for all the input. I can do following:<br>
> > 1) Move test to MatGetFactor()<br>
> > - If there is sufficient requests from user, we are able to add Hermitian support to petsc sequential Cholesky.<br>
> ><br>
> > 2) Tests:<br>
> > a) complex build && ftype==CHOLESKY:<br>
> > if (mat->hermitian) throw an "not supported" error<br>
> ><br>
> > b) all builds:<br>
> > if (!sbaij && (CHOLESKY || ICC))<br>
> > if (!mat->symmetric)<br>
> > call MatIsSymmetric(mat,0.0,&symm)<br>
> > if (!symm) throw an error<br>
> ><br>
> > Hong<br>
> ><br>
> ><br>
> > On Fri, Sep 29, 2017 at 9:55 AM, Greg Meyer <<a href="mailto:gregory.meyer@gmail.com">gregory.meyer@gmail.com</a>> wrote:<br>
> > FYI my perspective as a user--something that really tricked me was that after setting the solver to Hermitian problem, the algorithm returned real eigenvalues so they seemed OK. When I turned off Hermitian as I was trying to debug, the eigenvalues were not at all just real, and thus it was clear that they were wrong. So I think the check at least when Hermitian is set is very important, since by construction real eigenvalues are returned.<br>
> ><br>
> ><br>
> > On Fri, Sep 29, 2017, 7:37 AM Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
> ><br>
> > 1) The test is definitely in the wrong place. If we are testing and erroring if using Cholesky and mat is not marked as symmetric or hermitian the test should be in MatGetFactor() not in a particular implementation.<br>
> ><br>
> > 2) It is a tough call if we should do this check or not. There are good arguments in both directions.<br>
> ><br>
> > One thing we could do is if the matrix is not marked as symmetric/hermitian is we could just check at that point (but expensive) or we could just check in debug mode.<br>
> ><br>
> > But I think we should require the user to set the flag (note for SBAIJ the flag for symmetric (or hermitian? which one) should be automatically set at creation).<br>
> ><br>
> > Hong can you move the test up to the MatGetFactor() level?<br>
> ><br>
> > Thanks<br>
> > Barry<br>
> ><br>
> ><br>
> > > On Sep 28, 2017, at 11:35 PM, Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com">stefano.zampini@gmail.com</a>> wrote:<br>
> > ><br>
> > > Hong,<br>
> > ><br>
> > > I personally believe that commit <a href="https://bitbucket.org/petsc/petsc/commits/966c94c9cf4fa13d455726ec36800a577e00b171" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/<wbr>petsc/commits/<wbr>966c94c9cf4fa13d455726ec36800a<wbr>577e00b171</a> should be reverted.<br>
> > > I agree on the fact that when the user sets an option (the hermitian one in this case) and that feature is not supported we should throw an error (<a href="https://bitbucket.org/petsc/petsc/commits/8f21f52c465b775a76cda90fe9c51d0c742078c7" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/<wbr>petsc/commits/<wbr>8f21f52c465b775a76cda90fe9c51d<wbr>0c742078c7</a>) , but I don't like the fact that the user is forced to set on option to use a feature that he already requested (as in <a href="https://bitbucket.org/petsc/petsc/commits/966c94c9cf4fa13d455726ec36800a577e00b171" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/<wbr>petsc/commits/<wbr>966c94c9cf4fa13d455726ec36800a<wbr>577e00b171</a>).<br>
> > ><br>
> > > Barry, what do you think?<br>
> > ><br>
> > > 2017-09-29 5:28 GMT+03:00 Hong <<a href="mailto:hzhang@mcs.anl.gov">hzhang@mcs.anl.gov</a>>:<br>
> > > Greg:<br>
> > > Thanks so much for the detailed response. I am glad to know the reason behind it--hopefully we eventually figure out why the solvers have this behavior! Hong, I really appreciate you working on a patch to throw an error in this case. It definitely bit me and some people using my code... Hopefully it doesn't happen to anyone else! :)<br>
> > ><br>
> > > I added an error flag for using MUMPS Cholesky factorization on Hermitian matrix. See branch hzhang/mumps-<wbr>HermitianCholesky-errflag<br>
> > > <a href="https://bitbucket.org/petsc/petsc/commits/8f21f52c465b775a76cda90fe9c51d0c742078c7" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/<wbr>petsc/commits/<wbr>8f21f52c465b775a76cda90fe9c51d<wbr>0c742078c7</a><br>
> > ><br>
> > > Jose,<br>
> > > PETSc does not support Cholesky for Hermitian matrix.<br>
> > ><br>
> > > The linear solver table probably needs to be updated. I have tried several Cholesky solvers. With mkl_pardiso I get an explicit error message that it does not support Cholesky with complex scalars. The rest (PETSc, MUMPS, CHOLMOD) give a wrong answer (without error message). The problem is not related to your matrix, nor to shift-and-invert in SLEPc. I tried with ex1.c under PETSC_DIR/src/ksp/ksp/<wbr>examples/tutorials. The example works in complex scalars, but the matrix is real. As soon as you add complex entries Cholesky fails, for instance adding this:<br>
> > > ierr = MatSetValue(A,0,1,1.0+PETSC_i,<wbr>INSERT_VALUES);CHKERRQ(ierr);<br>
> > > ierr = MatSetValue(A,1,0,1.0-PETSC_i,<wbr>INSERT_VALUES);CHKERRQ(ierr);<br>
> > ><br>
> > > In this case, you must call<br>
> > > MatSetOption(A,MAT_HERMITIAN,<wbr>PETSC_TRUE);<br>
> > ><br>
> > > Then, petsc will throw an error for '-pc_type cholesky'.<br>
> > ><br>
> > > I don't know if it is a bug or that the algorithm cannot support complex Hermitian matrices. Maybe Hong can confirm any of these. In the latter case, I agree that all packages should give an error message, as mkl_pardiso does.<br>
> > ><br>
> > > I also add an error flag for Cholesky/ICC if user does not set<br>
> > > MatSetOption(A,MAT_SYMMETRIC,<wbr>PETSC_TRUE) for aij matrix.<br>
> > > See <a href="https://bitbucket.org/petsc/petsc/commits/966c94c9cf4fa13d455726ec36800a577e00b171" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/<wbr>petsc/commits/<wbr>966c94c9cf4fa13d455726ec36800a<wbr>577e00b171</a><br>
> > ><br>
> > > Let me know if you have any comments about this fix.<br>
> > ><br>
> > > Hong<br>
> > ><br>
> > > > El 25 sept 2017, a las 7:17, Greg Meyer <<a href="mailto:gregory.meyer@gmail.com">gregory.meyer@gmail.com</a>> escribió:<br>
> > > ><br>
> > > > Hi all,<br>
> > > ><br>
> > > > Hong--looking at your link, there may be no special algorithm for Hermitian matrices in MUMPS, but that doesn't mean it can't solve them like it would any matrix. Furthermore it appears that Cholesky of complex matrices is supported from this link: <a href="https://www.mcs.anl.gov/petsc/documentation/linearsolvertable.html" rel="noreferrer" target="_blank">https://www.mcs.anl.gov/petsc/<wbr>documentation/<wbr>linearsolvertable.html</a><br>
> > > ><br>
> > > > So do you or anyone have any idea why I get incorrect eigenvalues?<br>
> > > ><br>
> > > > Thanks,<br>
> > > > Greg<br>
> > > ><br>
> > > > On Thu, Sep 21, 2017 at 5:51 PM Greg Meyer <<a href="mailto:gregory.meyer@gmail.com">gregory.meyer@gmail.com</a>> wrote:<br>
> > > > Ok, thanks. It seems that PETSc clearly should throw an error in this case instead of just giving incorrect answers? I am surprised that it does not throw an error...<br>
> > > ><br>
> > > > On Thu, Sep 21, 2017 at 5:24 PM Hong <<a href="mailto:hzhang@mcs.anl.gov">hzhang@mcs.anl.gov</a>> wrote:<br>
> > > > Greg :<br>
> > > > Yes, they are Hermitian.<br>
> > > ><br>
> > > > PETSc does not support Cholesky factorization for Hermitian.<br>
> > > > It seems mumps does not support Hermitian either<br>
> > > > <a href="https://lists.mcs.anl.gov/mailman/htdig/petsc-users/2015-November/027541.html" rel="noreferrer" target="_blank">https://lists.mcs.anl.gov/<wbr>mailman/htdig/petsc-users/<wbr>2015-November/027541.html</a><br>
> > > ><br>
> > > > Hong<br>
> > > ><br>
> > > ><br>
> > > > On Thu, Sep 21, 2017 at 3:43 PM Hong <<a href="mailto:hzhang@mcs.anl.gov">hzhang@mcs.anl.gov</a>> wrote:<br>
> > > > Greg:<br>
> > > ><br>
> > > > OK, the difference is whether LU or Cholesky factorization is used. But I would hope that neither one should give incorrect eigenvalues, and when I run with the latter it does!<br>
> > > > Are your matrices symmetric/Hermitian?<br>
> > > > Hong<br>
> > > ><br>
> > > > On Thu, Sep 21, 2017 at 2:05 PM Hong <<a href="mailto:hzhang@mcs.anl.gov">hzhang@mcs.anl.gov</a>> wrote:<br>
> > > > Gregory :<br>
> > > > Use '-eps_view' for both runs to check the algorithms being used.<br>
> > > > Hong<br>
> > > ><br>
> > > > Hi all,<br>
> > > ><br>
> > > > I'm using shift-invert with EPS to solve for eigenvalues. I find that if I do only<br>
> > > ><br>
> > > > ...<br>
> > > > ierr = EPSGetST(eps,&st);CHKERRQ(<wbr>ierr);<br>
> > > > ierr = STSetType(st,STSINVERT);<wbr>CHKERRQ(ierr);<br>
> > > > ...<br>
> > > ><br>
> > > > in my code I get correct eigenvalues. But if I do<br>
> > > ><br>
> > > > ...<br>
> > > > ierr = EPSGetST(eps,&st);CHKERRQ(<wbr>ierr);<br>
> > > > ierr = STSetType(st,STSINVERT);<wbr>CHKERRQ(ierr);<br>
> > > > ierr = STGetKSP(st,&ksp);CHKERRQ(<wbr>ierr);<br>
> > > > ierr = KSPGetPC(ksp,&pc);CHKERRQ(<wbr>ierr);<br>
> > > > ierr = KSPSetType(ksp,KSPPREONLY);<wbr>CHKERRQ(ierr);<br>
> > > > ierr = PCSetType(pc,PCCHOLESKY);<wbr>CHKERRQ(ierr);<br>
> > > > ...<br>
> > > ><br>
> > > > the eigenvalues found by EPS are completely wrong! Somehow I thought I was supposed to do the latter, from the examples etc, but I guess that was not correct? I attach the full piece of test code and a test matrix.<br>
> > > ><br>
> > > > Best,<br>
> > > > Greg<br>
> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > --<br>
> > > Stefano<br>
> ><br>
> ><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>