I am getting a MUMPS error in numerical factorization... Anyway, your B matrix is singular, with a high-dimensional nullspace. Maybe this is producing small negative values when computing v'*B*v. There is no way to relax the check. You should solve the problem as non-symmetric. Or use Arpack if it works for you. Jose
El 30 oct 2017, a las 17:16, Franck Houssen <[email protected]> escribió:
I deal with domain decomposition. It was faster/easier to generate files with 1 proc: I guess the "dirichlet" and "neumann" matrices are the same in this case, so one get the same files in the end... I didn't realized that when I sent the files. My mistake.
At my side, when I use krylovschur, SLEPc fails using 1, 2, 4, 8, ... procs (each proc performs a SLEPc solve that may fail or not - difficult to catch one). For instance, I attached data of one failed domain out of 8 (8 MPI procs): matrices are very close but different. Moreover, I added EPS logs of the same run and domain but replacing krylovschur with arpack when SLEPc does not fail (regarding your remark that B could be indefinite, I added -mat_mumps_icntl_33 1 to get the determinant).
Anyway, I don't expect you spend too much time on this. My understanding is that there is no way to relax this check ? Correct ?
Franck
----- Mail original -----
De: "Jose E. Roman" <[email protected]> À: "Franck Houssen" <[email protected]> Cc: "For users of the development version of PETSc" <[email protected]> Envoyé: Samedi 28 Octobre 2017 17:40:41 Objet: Re: [petsc-dev] SLEPc failure
The two matrices are the same ...
El 28 oct 2017, a las 13:11, Franck Houssen <[email protected]> escribió:
I just added that before EPSSetOperators: PetscViewer viewerA; PetscViewerBinaryOpen(PETSC_COMM_WORLD,"Atau.out",FILE_MODE_WRITE,&viewerA); MatView(A,viewerA); PetscViewer viewerB; PetscViewerBinaryOpen(PETSC_COMM_WORLD,"Btau.out",FILE_MODE_WRITE,&viewerB); MatView(B,viewerB);
At first, I avoided binary as I didn't know if the format handles big/little endianness... So I prefered ASCII.
Binary data are attached.
Franck
PS : running debian with little endian.
python -c "import sys;print(0 if sys.byteorder=='big' else 1)" 1
----- Mail original -----
De: "Jose E. Roman" <[email protected]> À: "Franck Houssen" <[email protected]> Cc: "For users of the development version of PETSc" <[email protected]> Envoyé: Vendredi 27 Octobre 2017 18:52:56 Objet: Re: [petsc-dev] SLEPc failure
I cannot load the files you sent. Please send the matrices in binary format. The easiest way is to run your program with -eps_view_mat0 binary:Atau.bin -eps_view_mat1 binary:Btau.bin
However, the files are written at the end of EPSSolve() so if the solve fails then it will not create the files. You can try running with -eps_max_it 1 or add code in your main program to write the matrices.
Jose
El 27 oct 2017, a las 12:28, Franck Houssen <[email protected]> escribió:
Maybe could be convenient for the users to have an option (or an EPSSetXXX) to relax that check ? Data are attached.
Franck
----- Mail original -----
De: "Jose E. Roman" <[email protected]> À: "Franck Houssen" <[email protected]> Cc: "For users of the development version of PETSc" <[email protected]> Envoyé: Vendredi 27 Octobre 2017 10:15:44 Objet: Re: [petsc-dev] SLEPc failure
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 <[email protected]> escribió:
I use the development version (bitbucket clone). How to relax the check ? At command line option ?
Franck
----- Mail original -----
De: "Jose E. Roman" <[email protected]> À: "Franck Houssen" <[email protected]> Cc: "For users of the development version of PETSc" <[email protected]> Envoyé: Jeudi 26 Octobre 2017 18:49:22 Objet: Re: [petsc-dev] SLEPc failure
El 26 oct 2017, a las 18:36, Franck Houssen <[email protected]> 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
<ABtau.tar.gz>
<ABtau.tar.gz>
<slepc.tar.gz>