BoundaryMode/WavePort solve converges slowly in cases with lossy BCs

[simlapointe]

In BoundaryMode/WavePort cases with lossy BCs, the solve can take a large number (e.g. >~100) of GMRES iterations, while it usually converges in <5 iterations with PEC boundary conditions, as mentioned in #903 (comment). This is because the sparse-direct preconditioner used in the BoundaryMode solve only uses the real part of the system matrix, so convergence is degraded when there are significant imaginary contributions. This issue is to investigate this and improve the BoundaryMode preconditioner so it handles those cases better.

[benvial]

I tested #921 on our CPW case attached (pr921-testcase.zip, 2 wave ports spanning the full end cross-section, so the port
solve inherits absorbing + conductivity Robin terms). Nice work, the difference is dramatic:

• Wave Ports: ~422 s to 6.2 s at a single frequency (4 ranks, order 2)
• Port GMRES: hundreds of iterations (~0.99 reduction) to 7–10 iterations (~0.13)
• Results are now cap-independent: with Solver.Linear.MaxIts = 45 everything still converges and kₙ matches the uncapped answer, where the old preconditioner silently truncated.

One thing worth knowing about, though I don't think it's caused by this PR: on this case the default (Ar + Ai) path deterministically converges a spurious eigenpair on one of two nominally identical ports at 1 GHz, and the |Re(kₙ) − kₙ_target| sort then selects it:

Port 1, mode 1: kₙ = 5.103e+01+5.677e+03i m⁻¹   (Im/Re ≈ 111)
Port 2, mode 1: kₙ = 3.807e+01-4.445e+00i m⁻¹   (correct)

which drives |S11| to +44.8 dB at the low end of a sweep.

With "ComplexCoarseSolve": true both ports get the correct mode. The sort target is kn_target = ω·√(1.1·μεmax) with GetMaxMuEpsilon() a plain max over the cross-section materials: here that's ε = 7.5 from a 1.9 μm Si₃N₄ film in a 218 μm cross-section, putting the target at 60.2 m⁻¹ at 1 GHz, closer to the spurious Re = 51 than to the true guided Re = 38. So whenever the spurious pair converges, the sort must pick it.

A few ideas:

• warn via the existing IsPropagating check, which is currently only called from the BoundaryMode driver;
• expose a per-port target override (e.g. "NEff" or "Target"), like the 3D Eigenmode solver already has, that would also help layered stacks generally, since a thin high-ε film that can't guide anything at low frequency still anchors the search today.

Another observation: the port-stage cost of ComplexCoarseSolve is modest (Wave Ports is 10.2 s vs 6.2 s at one frequency). The practical cost is that the same knob also switches the 3D coarse solve to the complex factorization (600 s vs 200 s per frequency here). Since on this case the exact path is the one that picks the correct mode, a way to opt into it for the port solve without also flipping the 3D coarse solve might be worth considering.

[simlapointe]

Thanks for testing and sharing the test case, super helpful!

The spurious eigenpair in your case seems to be caused by a loose linear solver tolerance. If I reduce from 1e-6 to 1e-8 I no longer see that spurious mode. Relatedly, I realized that the wave ports config settings (WavePorts.KSPTol and WavePorts.MaxIts were not internally being passed to the wave port solver, and instead the 3D linear solver settings (Solver.Linear.Tol and Solver.Linear.MaxIts) were being used for both the 3D solve and the 2D wave port solve. I fixed this small bug in #921 and now WavePorts.KSPTol and WavePorts.MaxIts control the wave port linear solve, independently of the 3D solve settings. The default WavePorts.KSPTol is 1e-8 so this change fixes your issue.

Following your suggestion, I also added WavePorts.ComplexCoarseSolve in #921 so this can be controlled at the wave port level without affecting the 3D linear solve settings.

[benvial]

Thanks for tracking this down and implementing the fix so quickly. Glad it helped, and this should be useful on our side too.