Complex eigenvalue error in `bf_lbo` on MFEM sphere

[pbeckman]

For the next mesh /h/5/, I believe I get a complex eigenvalue?

(lldb) ./bf_lbo --matPath=../../../../butterfly-LBO-models/sphere_meshes/h/5/ --useOctree --tol=1e-3 --freqTreeDepth=2
Process 63632 launched: '/Users/beckman/Documents/Research/NYU/potter-butterfly-GP/code/butterfly-beckman-fork/builddir/examples/lbo/bf_lbo' (arm64)
using FEM matrices loaded from binaries in directory ../../../../butterfly-LBO-models/sphere_meshes/h/5/ (16386 verts)
wrote octree cells to octree_boxes.txt
row tree has depth 9
computed lambda_max = 46489.7 [0.9s]
building frequency tree with depth 2 (k = 8)
streaming full eigenvector matrix
Process 63632 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x100561b70)
    frame #0: 0x0000000100561b70 libbutterfly.dylib`bfSetError(error=BF_ERROR_RUNTIME_ERROR) at error.c:21:3
   18   }
   19  
   20   void bfSetError(enum BfError error) {
-> 21     BF_ASSERT(!error);
   22  
   23     currentError = error;
   24   }
Target 0: (bf_lbo) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x100561b70)
  * frame #0: 0x0000000100561b70 libbutterfly.dylib`bfSetError(error=BF_ERROR_RUNTIME_ERROR) at error.c:21:3
    frame #1: 0x0000000100570eb0 libbutterfly.dylib`bfGetShiftedEigs(A=0x0000000147f04720, M=0x0000000147f047d0, sigma=6.0032161883244317, k=10, PhiTransposePtr=0x000000016fdfe3b8, LambdaPtr=0x000000016fdfe3b0) at linalg.c:675:7
    frame #2: 0x00000001005716a4 libbutterfly.dylib`getPairsCoveringInterval(A=0x0000000147f04720, M=0x0000000147f047d0, interval=0x0000000117009600, LamData=0x0000000100108ae0, PhiTransposeData=0x0000000100108b00) at linalg.c:849:3
    frame #3: 0x0000000100571da4 libbutterfly.dylib`getEigenband_covering(A=0x0000000147f04720, M=0x0000000147f047d0, interval=0x000000016fdfe5b8, PhiPtr=0x000000016fdfe5e0, LambdaPtr=0x000000016fdfe5d8) at linalg.c:949:24
    frame #4: 0x00000001005721a8 libbutterfly.dylib`bfGetEigenband(A=0x0000000147f04720, M=0x0000000147f047d0, interval=0x000000016fdfe5b8, method=BF_EIGENBAND_METHOD_COVERING, PhiTransposePtr=0x000000016fdfe5e0, LambdaPtr=0x000000016fdfe5d8) at linalg.c:1020:5
    frame #5: 0x000000010056eeb0 libbutterfly.dylib`bfLboFeedFacStreamerNextEigenband(facStreamer=0x0000000100108a10, freqs=0x0000000100108970, L=0x0000000147f04720, M=0x0000000147f047d0) at lbo.c:100:3
    frame #6: 0x0000000100003340 bf_lbo`main(argc=5, argv=0x000000016fdfed38) at bf_lbo.c:396:5
    frame #7: 0x000000019d0960e0 dyld`start + 2360

[pbeckman]

We discussed simply ignoring complex parts of eigenvalues (maybe with a warning if the complex part exceeds 1e-8 or so)

[sampotter]

@pbeckman I actually don't get this error:

using FEM matrices loaded from binaries in directory ../../../../butterfly-LBO-models/sphere_meshes/h/5/ (16386 verts)
wrote octree cells to octree_boxes.txt
row tree has depth 9
computed lambda_max = 46489.7 [3.9s]
building frequency tree with depth 2 (k = 8)
streaming full eigenvector matrix
feed: bracket = (-inf, 11.35), num. eigs = 9
- streamed 9 eigs (0.1% of total)
- compressed size:   1.125 MB
- uncompressed size: 1.125 MB
- compression rate:  1.000
feed: bracket = [11.35, 45.40), num. eigs = 41
- streamed 50 eigs (0.3% of total)
- compressed size:   6.013 MB
- uncompressed size: 6.251 MB
- compression rate:  1.039
feed: bracket = [45.40, 102.15), num. eigs = 51

and then I hit that "shouldn't be a leaf node" assert in the other issue.

I'm wondering if you're using out of date MFEM meshes, or if there's some other subtle issue... Let's sort the other issue first and then look at the output we get (plot some decompressed eigenvectors). I bet that will shed light on the issue.

[pbeckman]

This may have been subtly related to the "bottoming out" issue, because I'm not able to reproduce this error following your recent commit. Both of these smell like inter-platform UMFPACK differences to me, since the only differences in our outputs come from small differences in computed eigs... Again not something we need to solve this second.