You can run with -fp_trap to have the program stop as soon as the first Nan or Inf appears, this can help track down why it is happening. In a debugger you can also set the debugger to trap on floating point exceptions (syntax is debugger dependent) to focus in on where it first happens.
Barry > On Sep 7, 2022, at 3:20 AM, Jose E. Roman <jro...@dsic.upv.es> wrote: > > > >> El 7 sept 2022, a las 6:18, Patrick Alken <patrick.al...@geomag.info> >> escribió: >> >> I sometimes get Nan output values in computed eigenvectors for the >> generalized symmetric eigenvalue problem produced by slepc. Is this a known >> issue, and is it related to the conditioning of the matrix pair (A,B)? Is >> there some way to compute a "condition number" of the matrix pair ahead of >> time to see if i have a good chance of getting stable eigenvectors out? > > You should never get NaN. Can you send a reproducible example? > >> >> In a possibly related issue, i am finding that petsc/slepc compiled with >> debugging vs optimization can produce very different eigenvectors for the >> same problem, while the eigenvalues are the same. The eigenvectors seem more >> accurate when I use the debugging version of the libraries. Could this be >> also a conditioning problem with the matrix pair? > > What do you mean more accurate? The residual norm computed with > EPSComputeError() should be below the tolerance in both debugging and > optimized versions. > > Jose >
