Choosing an engine: cost, memory, accuracy

Eight engines over seven solver families answer through one kernel, and every one of them is reachable by name — as a --basis argument, as its own momwire-nec2c-<basis> command in SimNEC’s dialog (all but the razor pair: a NEC-2 deck feeds a segment centre and razor places its gap at a knot, so that front door refuses it by name, momwire#821), or as the solver behind EZNEC’s engine slot (which serves the default, and is where razor lives). This page is the engine-side answer to the question every host dialog raises: which name, and what does it cost?

The numbers here come from three standing benchmark studies — the solver-selection benchmark (10 designs × 7 engines, free space), the ground-model benchmark (the same designs × 4 ground models), and the basis-convergence census (91 designs, meshes N=7–641). Timings quoted at N=81 segments/wire on a 4-core box unless stated.

The selection matrix

The choice turns on two axes — total problem size, and single-structure vs. array geometry:

Antenna class	Use	Why
Single elements, small loops, beams, multiband dipoles	`bspline` (degree 2 — the default everywhere), with `sinusoidal` as a cross-check	both solve in milliseconds here; d=2 converges at far coarser meshes (below), the other confirms the answer
Large single-wire structures (rhombics, long-wires, big loops)	`hmatrix` (ACA)	sub-quadratic scaling — the only engine in the field that wins `rhombic` at high segmentation
Arrays of identical / few-shape elements (loop/bowtie arrays, LPDA)	`arrayblock`	element-aware block-low-rank; near-linear scaling, 7–12× faster than the NEC-2 lineage on large arrays
Cross-checking against NEC-5 behaviour	`razor-2p`	the formulation twin — rides the licensed engine’s own convergence path (below)
Telling basis effects from testing effects	`sinusoidal-galerkin`	same basis as `sinusoidal`, variational testing — the attribution instrument of Act V
Reading a textbook scheme against the modern ones	`pulse`	Harrington’s 1967 pulse expansion, point-matched — the oldest thin-wire MoM there is, and the slowest-converging engine here by a wide margin (below)
Buried radials, screens, buried fed elements	`bspline` (or `bspline-d1`), with `sinusoidal-galerkin` and `razor-2p` as independent buried lanes	each carries its own below-interface fill and serves impedance/currents/charges and the radiation pattern over the Sommerfeld ground; `sinusoidal` serves wholly buried and detached decks (since 0.66) and a single near-normal crossing (its two members’ tilts off vertical summing to 30° or less), such as a ground rod or the buried radial vertical, whose rise meets a buried hub below the plane; it refuses oblique crossings, a hub at the crossing node itself, and several crossings per deck by name, `pulse` refuses buried decks by name, and so does the compressed pair — `hmatrix` and `arrayblock` have no per-segment media (see the serve matrix)

The same picks hold with a ground in play — the ground model changes what a solve costs, not which engine wins it. One exception is capability, not cost: wires below the interface are served by bspline, bspline-d1, sinusoidal-galerkin and razor-2p, and by sinusoidal when no wire crosses the interface or one near-normal crossing does (a ground rod, or a radial screen whose rise meets its hub below the plane; an oblique crossing, or radials meeting the mast at the plane itself, refuse by name), and a buried deck’s first solve pays a one-time build of its below-interface Sommerfeld tables.

Runtime

The ground-cost ladder is consistent everywhere: free ≈ PEC < reflection-coefficient < Sommerfeld. PEC is nearly free (an image, no material solve); the reflection-coefficient ground runs ~1.5–3× a free-space solve on the dense bases; the full Sommerfeld ground ~2–5×. The Sommerfeld premium is mostly the first solve of a session: the interpolation-grid fill grows linearly with antenna size (not quadratically) and is reused across a band’s frequencies, so warm sweep ticks undercut even the NEC-2 lineage’s per-tick steady state on 86/90 benchmark designs (session benchmark).
ACA earns its place on the rhombic — fastest engine in free space (~4.0 s, scaling ~2×/step where dense engines go ~5×/step), and under Sommerfeld the low-rank structure survives (the smooth ground remainder rides one compressed term): 9.3 s vs the dense B-spline’s 18.7 s.
ArrayBlock dominates arrays on every ground — LPDA free space: ~1.2 s vs the NEC-2 lineage’s 14 s; Sommerfeld: 2.8 s vs 24 s.
At a fixed segment count, sinusoidal is the fastest dense basis on small/medium single structures, on every ground. But the fair comparison is at fixed accuracy, and the census flipped that verdict — next section.

Accuracy per segment: why `bspline` d=2 is the default

The basis-convergence census (91 designs) measured accuracy against mesh density: B-spline degree 2 is within 2 % of the converged answer at N=15–21 segments per quarter-wave on 80 % of scorable designs, where the sinusoidal basis needs 3–15× more segments to reach the same value. Single closed loops converge on d=2 as coarse as N=7. The gap is largest on port-fed, junction-heavy, and closely-spaced-wire geometry — and the momwire#182 instrument showed most of it is the point matching, not the basis: rerun under Galerkin testing (sinusoidal-galerkin), the 1–23 % junction-heavy gaps collapse to 0.01–0.33 %.

Dense cost scales as N² in memory and N²–N³ in fill/factor time, so an engine that converges at one-third the mesh is roughly an order of magnitude cheaper at equal accuracy. That, not a benchmark sprint, is why bspline d=2 is the default in every portal and every host.

The razor lane, and its certification twin

razor-2p — razor-nec5 is its deprecated spelling — tests the tent expansion with NEC-5’s razor-blade rule at NEC-5’s own identified two-point quadrature. It is the orderable member of RazorSolver. The class also takes Gauss-Legendre nodes along the same testing path, which was a second roster entry, plain razor, until momwire#753 retired it (decided 2026-09-02): the two lanes are one class differing only in that sampling choice, and measured 2026-08-18, the GL lane cost 20x the wall time (20.2 s vs 0.97 s at N=1600 free space) for a 0.001 Ω difference from razor-2p — not worth ordering. The class stays; the GL lane is reached by constructing RazorSolver(nec5_quadrature=False, ...) directly rather than through --basis or a portal name.

	`razor-2p` / `razor-nec5`	GL quadrature (`RazorSolver` constructed directly)
Role	Interactive lane	Convergence / certification lane
Speed	Sub-second to N≈300–400 free, N≈200–400 grounded; 2–4× behind `bspline` beyond that	12–80× slower than `bspline`; over a second even at N=100 under any ground
Memory	Same order as the other dense bases	Exceeds an 8 GB working set by N≈800 grounded / N≈1600 free
Use for	Ordinary solves, A/B checks against NEC-5 behaviour	Convergence ladders, certification against NEC-5 printouts

On the models where we hold a licensed reference, razor-2p rides the licensed engine’s own convergence path at the 0.01 % level — it converges along NEC-5’s trajectory, not merely to its endpoint. Node gaps (momwire#603), the extended kernel (on a buried deck, on the above-ground wires, as bspline serves it; momwire#1614), contact over the Sommerfeld ground (momwire#624), buried wires and the crossing junction are all served; what the row still refuses — a feed named by arclength (feeds=) at a junction of three or more wire ends (a deck’s node address serves a source on a crossing node under one rising wire at any member count, since 0.79), a wire crossing the interface mid-span rather than at a junction, ground contact combined with buried wires, contact under the reflection-coefficient ground, and a feed named at a segment centre, which is why razor is not a nec2 engine (momwire#821) — is documented in docs/razor-solver.md and in the capability matrix, each with a named message.

`pulse`: the honest slow one

pulse is HarringtonSolver — a pulse (piecewise-constant) current basis with point matching, which is the scheme every other engine on this list was chosen to improve on. It is here because reading a modern answer against the classical one is worth being able to do without leaving the roster, not because it competes: it converges at O(1/N) where degree-2 B-splines converge far faster, so it wants a mesh several times finer for the same figure.

Measured on a 10 m dipole at 14 MHz against bspline’s converged 64.02 − 54.81j Ω:

Segments	Δ/a	`pulse`
11	909	81.82 + 63.82j
41	244	68.22 − 25.55j
101	99	65.62 − 43.52j
401	25	64.36 − 52.22j

At the segment counts a host dialog defaults to, that is a visibly different answer, and it is the formulation’s own error rather than a defect — pick it when that is what you want to see, and bspline otherwise.

It also serves less: no wire loading (an LD 5 or LD 6 is refused by name), no junction ports, no node gaps, no extended kernel, and one scalar radius. The EZNEC drop-in does not offer it at all — that dialect drives a node, and this family puts its gap at the nearest segment centre, so it refuses every deck there for the same reason sinusoidal does.

Memory

The dense bases form an N×N complex matrix: memory grows as N², and a runaway segment count costs hundreds of megabytes before it costs minutes. Practical envelopes on an 8 GB working set: the GL-quadrature certification lane (RazorSolver constructed directly with nec5_quadrature=False — off the --basis roster since momwire#753) exceeds it by N≈800 grounded / N≈1600 free (the table above); the other dense bases reach further at the same N because their peak was engineered down deliberately — the memory-release series (momwire 0.29.0’s certified peaks, then the #318/#323 B-spline reductions) trimmed multi-gigabyte transient peaks to near the resident matrix size. The compressed engines (hmatrix, arrayblock) skip the dense matrix entirely, which is exactly why they exist for large problems.

These envelopes were measured at RazorSolver’s outer path order of 32 (so 64 observation points per testing path), which was the default until momwire#800 made it DERIVE from the mesh on 2026-09-02. At the mesh densities in this section the derivation returns 16, halving the outer integral’s cost — so the N≈800 / N≈1600 figures are the conservative reading rather than the current one. An explicit n_qp_path=32 reproduces what they were measured at, bit for bit.

The extended kernel, in one paragraph

Every engine solves a thin-wire equation; the EK card’s O(a²) tube correction matters below Δ/a ≈ 3 and costs about 1.0–1.3× the reduced solve. All six families serve it — the razor twins were the last holdout, reduced-kernel by design until momwire#603 gave them the tube correction too. One narrow refusal survives: sinusoidal-galerkin declines EK on a deck where two wires of different radii meet at a junction, measured divergent rather than merely inaccurate there. On a deck with buried wires bspline, razor-2p and sinusoidal-galerkin (since momwire#1626) serve it in part: extended on the above-ground wires, reduced on the buried ones; sinusoidal solves such a deck reduced (momwire#1636). On ordinary thin wire it changes the answer by less than the mesh does. A NEC-2 deck asks for it with its EK card. NEC-4 and NEC-5 decks get it by default (momwire#1326), because both programs’ thin-wire models behave as the extended kernel. Where a deck or a basis cannot take it, such a deck falls back to the reduced kernel with an advisory.

The workbench view

The antennaknobs solver guide carries the same engines from the app’s side — workbench controls, the convergence-sweep tool, feed-model choices, and the hosted instance’s size caps — and the validation story holds the full three-formulation parity record and the wild-corpus census.