onec v2.2.0 (commit 6621787, Linux x86_64) computes wrong results on the deck style 4nec2 itself generates when emulating EX 6 current sources: one phantom 1-segment wire per source parked at a fictitious height, an EX 0 on each phantom carrying the current phasor, and an NT gyrator (Y11=Y22=0, Y12=Y21=j) forcing that current into the real segment. Since onec's own docs describe it as a drop-in engine for 4nec2, decks of this shape will reach it whenever a 4nec2 model uses current sources.
Possibly related to the NT state handling in #10, though this reproduces with a single XQ.
Reproduction
A 3-element phased vertical array (3.6 MHz), three gyrator-driven feeds requesting currents exactly (0+1j, −2+0j, 0−1j) — the deck below is the emulation 4nec2 produces for three EX 6 cards, with the LD card removed to sidestep issue #11:
CM 3.6 MHz phased verticals, 4nec2-style EX 6 gyrator emulation
CE
GW 1 25 -68.304 0 0 -68.304 0 75.5 0.083335
GW 2 25 0 0 0 0 0 75.5 0.083335
GW 3 25 68.304 0 0 68.304 0 75.5 0.083335
GS 0 0 0.3048
GW 4 1 0.0 0 16885.26 1.6655 0 16885.26 0.008328
GW 5 1 16.655 0 16885.26 18.3207 0 16885.26 0.008328
GW 6 1 33.3103 0 16885.26 34.9758 0 16885.26 0.008328
GE 1
GN 1
FR 0 1 0 0 3.6 1
NT 4 1 0 1 0 0 0 1 0 0
NT 5 1 0 26 0 0 0 1 0 0
NT 6 1 0 51 0 0 0 1 0 0
EX 0 4 1 0 -6.123233995736766e-17 1.0
EX 0 5 1 0 -2.0 0.0
EX 0 6 1 0 -6.123233995736766e-17 -1.0
XQ
EN
Expected (nec2c 1.3, same deck — and matching 4nec2/NEC-2D on the original model)
STRUCTURE EXCITATION DATA at the real segments: delivered currents exactly the requested phasors, physical driving-point impedances:
tag 1 seg 1: I = 1.000+0.000j Z = 119.13+165.14j
tag 2 seg 26: I = 0.000+2.000j Z = 53.68+ 86.52j
tag 3 seg 51: I = −1.000−0.000j Z = 22.59+ 52.88j
Actual (onec)
tag 2 seg 26: I = 1.000+0.000j Z = 30.97−2012.7j
tag 3 seg 51: I = 1.000+0.000j Z = 31.65−2012.5j
tag 1 seg 1: I = −0.0099−0.0032j Z = −29.40−91.43j
The delivered currents ignore the drive phasors (ports 2 and 3 both read 1+0j; port 1 reads a leakage-scale current), and the ~−2 kΩ reactances look like the phantom wires' self-impedance leaking into the real-port rows — i.e. the gyrator NT coupling isn't being composed into the solution the way NEC-2 does it.
Found while evaluating onec as a batch reference engine for the antennaknobs deck-import corpus (which contains a number of 4nec2 current-source models); the exact deck above is validated three ways on our side (nec2c, 4nec2/NEC-2D on Windows, and an independent MoM solver) so the expected values are solid. Happy to re-test when this changes.
onec v2.2.0 (commit 6621787, Linux x86_64) computes wrong results on the deck style 4nec2 itself generates when emulating
EX 6current sources: one phantom 1-segment wire per source parked at a fictitious height, anEX 0on each phantom carrying the current phasor, and anNTgyrator (Y11=Y22=0, Y12=Y21=j) forcing that current into the real segment. Since onec's own docs describe it as a drop-in engine for 4nec2, decks of this shape will reach it whenever a 4nec2 model uses current sources.Possibly related to the NT state handling in #10, though this reproduces with a single
XQ.Reproduction
A 3-element phased vertical array (3.6 MHz), three gyrator-driven feeds requesting currents exactly (0+1j, −2+0j, 0−1j) — the deck below is the emulation 4nec2 produces for three
EX 6cards, with theLDcard removed to sidestep issue #11:Expected (nec2c 1.3, same deck — and matching 4nec2/NEC-2D on the original model)
STRUCTURE EXCITATION DATA at the real segments: delivered currents exactly the requested phasors, physical driving-point impedances:
Actual (onec)
The delivered currents ignore the drive phasors (ports 2 and 3 both read 1+0j; port 1 reads a leakage-scale current), and the ~−2 kΩ reactances look like the phantom wires' self-impedance leaking into the real-port rows — i.e. the gyrator NT coupling isn't being composed into the solution the way NEC-2 does it.
Found while evaluating onec as a batch reference engine for the antennaknobs deck-import corpus (which contains a number of 4nec2 current-source models); the exact deck above is validated three ways on our side (nec2c, 4nec2/NEC-2D on Windows, and an independent MoM solver) so the expected values are solid. Happy to re-test when this changes.