Auto-refinement (-a) crashes with repeated “InsertConstrEdge()” assert failures, then segfaults, on concentric-sphere geometry

[obelabbas-dotcom]

Summary

Running FasterCap with the -a (auto mesh refinement) flag on a two-conductor
concentric-sphere test case causes the console to print an endless stream of

./src/.../Geometry/Triangulate.cpp(930): assert "0" failed in InsertConstrEdge().
./src/.../Geometry/Triangulate.cpp(851): assert "0" failed in InsertConstrEdge().

repeated indefinitely (does not self-terminate; must be killed with Ctrl+C).

On a second attempt with a lower -a target error, it instead completes one
refinement iteration -- but that iteration already produces an asymmetric
capacitance matrix (C_12 != C_21, which should be impossible for a real
capacitance matrix by Maxwell reciprocity) -- and then segfaults on the next
"Increasing the geometric refinement.." step.

Switching from -a to manual refinement (-m, -mc) on the identical
geometry runs cleanly, completes in well under a second, and produces a
correctly symmetric, physically valid matrix that agrees with the exact
analytic solution (concentric-sphere capacitance formula) to within ~0.3%.
This strongly suggests the bug is specific to the -a auto-refinement /
re-triangulation code path, not the solver itself.

Environment

• FasterCap version: 6.0.7 (matches current master branch's
  FCG_HEADER_VERSION string at time of testing)
• OS: Linux Mint (Cinnamon)
• Built from source on the reporter's machine (standard CMake build, no
  modifications to source)

Steps to reproduce

1. Use the attached spheres.lst / spheres.qui (two concentric conductors,
   inner sphere radius 5cm, outer sphere radius 10cm, both meshed as
   subdivided icospheres -- 1280 triangles each, 2560 total. No poles / fan
   vertices in this mesh, ruling out degenerate pole-triangle slivers as the
   cause.)

2. Run:
   ./FasterCap spheres.lst -a0.001 -e

3. Observe: console prints repeated
   assert "0" failed in InsertConstrEdge()
   lines indefinitely, with no further progress (had to be killed manually).

   On a separate run with a different target error the same command instead
   produces one completed (but already-broken) iteration:
   Capacitance matrix is:
   Dimension 2 x 2
   g1_inner 1.3264e-11 -2.14526e-11
   g1_outer -1.07263e-11 2.65277e-11
   Note C_12 = -2.14526e-11 but C_21 = -1.07263e-11 -- these should be
   identical for any valid capacitance matrix. FasterCap then proceeds to a
   second refinement iteration ("Increasing the geometric refinement..") and
   segfaults:
   Segmentation fault (core dumped)

Expected behavior

-a auto-refinement should converge to a symmetric, physically valid
capacitance matrix (as manual refinement does on the same geometry), without
asserting or crashing.

Actual behavior

Either an infinite assert-failure loop, or one broken (asymmetric) iteration
followed by a segfault on the next refinement pass.

Workaround found

Manual refinement instead of auto:
./FasterCap spheres.lst -m0.01 -mc5 -t1e-5 -e
completes normally (0.35s) and produces:
g1_inner 1.10859e-11 -1.10907e-11
g1_outer -1.1082e-11 2.21778e-11
C_12 and C_21 agree to ~0.08% (consistent with float/discretization noise),
and the mutual capacitance (1.10907e-11 F) matches the exact analytic value
for concentric spheres of these radii (1.1127e-11 F) to within ~0.33%.

Attached files

• spheres.lst
• spheres.qui (single combined geometry file, both conductors,
  named "inner" and "outer")

These are a minimal reproducer -- just two conductors, no dielectric
interfaces, no unusual geometry beyond ordinary concentric spheres.

fastercap_bugreport.zip