[petsc-dev] SLEPc failure

[Jose E. Roman]

There is no new option. What I mean is that from 3.7 to 3.8 we changed the line that produces this error. But it seems that it is still failing in your problem. Maybe your B matrix is indefinite or not exactly symmetric. Can you send me the matrices?
Jose

> El 27 oct 2017, a las 9:57, Franck Houssen <franck.houssen at inria.fr> escribió:
> 
> I use the development version (bitbucket clone). How to relax the check ? At command line option ?
> 
> Franck
> 
> ----- Mail original -----
>> De: "Jose E. Roman" <jroman at dsic.upv.es>
>> À: "Franck Houssen" <franck.houssen at inria.fr>
>> Cc: "For users of the development version of PETSc" <petsc-dev at mcs.anl.gov>
>> Envoyé: Jeudi 26 Octobre 2017 18:49:22
>> Objet: Re: [petsc-dev] SLEPc failure
>> 
>> 
>>> El 26 oct 2017, a las 18:36, Franck Houssen <franck.houssen at inria.fr>
>>> escribió:
>>> 
>>> Here is a stack I end up with when trying to solve an eigen problem (real,
>>> sym, generalized) with SLEPc. My understanding is that, during the Gram
>>> Schmidt orthogonalisation, the projection of one basis vector turns out to
>>> be null.
>>> First, is this correct ? Second, in such cases, are there some recommended
>>> "recipe" to test/try (options) to get a clue on the problem ? (I would
>>> unfortunately perfectly understand the answer could be no !... As this
>>> totally depends on A/B).
>>> 
>>> With arpack, the eigen problem is solved (so the matrix A and B I use seems
>>> to be relevant). But, when I change from arpack to
>>> krylovschur/ciss/arnoldi, I get the stack below.
>>> 
>>> Franck
>>> 
>>> [0]PETSC ERROR: #1 BV_SafeSqrt()
>>> [0]PETSC ERROR: #2 BVNorm_Private()
>>> [0]PETSC ERROR: #3 BVNormColumn()
>>> [0]PETSC ERROR: #4 BV_NormVecOrColumn()
>>> [0]PETSC ERROR: #5 BVOrthogonalizeCGS1()
>>> [0]PETSC ERROR: #6 BVOrthogonalizeGS()
>>> [0]PETSC ERROR: #7 BVOrthonormalizeColumn()
>>> [0]PETSC ERROR: #8 EPSFullLanczos()
>>> [0]PETSC ERROR: #9 EPSSolve_KrylovSchur_Symm()
>>> [0]PETSC ERROR: #10 EPSSolve()
>> 
>> Is this with SLEPc 3.8? In SLEPc 3.8 we relaxed this check so I would suggest
>> trying with it.
>> Jose
>> 
>>