NECR2D2 — Bringing 1981 NEC2 Back From VAX Fortran
As recently as 1997, defense was still running PDP-11s, and I was using VMS. Plenty of universities in the late '80s were still on VAX minicomputers, or Sun servers into the early '90s — Sun really owned that market until Linux was ready for prime time. I was lucky enough to catch the tail end of that era: doing tape backups on VMS every Friday, watching SPARCstations arrive before Linux and Windows servers took over. This article grabs the NEC2 engine in its original Fortran 66/77, fixes it, compiles it with a modern 64-bit toolchain, and runs it. It's still a genuinely capable simulator; its roots just go back a long way.
Grabbing NEC2 the Old-Fashioned Way
Today we're reviving NEC2 by grabbing it from the internet — the internet, not the web. Before the web, you
navigated by a printed book of FTP and Telnet addresses, and most countries had an academic network you could
browse the same way. NEC2's source is still sitting on one of those: the still-operational
ftp.funet.fi, the Finnish Universities Network.
A quick cd pub, cd ham, cd antenna, cd NEC, and there it is
among a directory of a hundred-plus antenna models and archived NEC utilities: nec2_src.tar.Z. This
particular copy still has VAX references baked into it, so it's an old lineage — not necessarily the very first
release, but close enough, and NEC1 itself started life as a privately written government contract long before it
ever reached a university or a national lab (more on that below). Switch to binary mode, get the
file, and it unpacks to two files:
nec2d.f 249,243 bytes -- the entire Fortran 66/77 source
NEC2DPAR.INC 43 bytes -- one line: array size limitsThat .INC file is a nice reminder of the era: PARAMETER (MAXSEG=1000, MAXMAT=1000),
nothing more. Fortran 66/77 had no dynamically assignable arrays, so the segment and matrix limits had to be
baked into the executable at compile time — bump the numbers, recompile, get a bigger problem size. Tools like
4NEC2 ship several pre-built binaries at different sizes for exactly this reason.
The Toolchain: gfortran and a Teach-Yourself Book
Fortran is part of the GCC toolset, including a Windows build, so getting a compiler isn't the hard part. Reading eight-thousand-plus lines of 1970s Fortran without falling over is. Fortunately, Archive.org has Computer Programming in FORTRAN by Arthur S. Radford, free to borrow — a "Teach Yourself" primer covering both Fortran 66 and 77, exactly the vintage this source needs.
Hitting the Wall: 1970s Fortran vs. a 2020s Compiler
The first attempt — gfortran nec2d.f -fno-automatic -o nec2d.exe — produces several hundred
warnings, almost all one of two kinds: Hollerith constants (the old way of packing text into numeric variables,
e.g. DATA HPOL/6HLINEAR,5HRIGHT,4HLEFT/) and deleted Fortran 2018 features like the arithmetic
IF statement and non-END DO loop terminators. Turning warnings off to see just the
errors narrows it down to a much shorter, much more interesting list:
Error: READONLY at (1) is a DEC extension, enable with '-fdec'
Error: Invalid character in name at (1) -- TYPE 1,MSG(...) (VAX's TYPE, not standard Fortran)
Error: BOZ constant at (1) uses nonstandard postfix syntax -- '0407'X, a VAX hex literal
Error: 'time' argument of 'second' intrinsic at (1) must be of kind 4
Error: Type mismatch in argument 't' at (1); passed REAL(4) to REAL(8)Roughly two dozen more errors turn out to be the same last category repeated: a bare 0. literal
(single precision) passed into a routine expecting REAL(8) (double precision) — completely legal
under the old VAX compiler's implicit conversions, not under a modern one. Once you see the pattern, the whole
error list stops being intimidating: one reserved word (SECOND), a handful of VAX/DEC-specific
syntax, and a lot of the same single-to-double literal mismatch. Very fixable.
The Patch (Available Below, Not Printed Here)
The fix is a standard diff patch — one line changed, one line added, one function's guts replaced, repeated
about a dozen times across an 8,000-line file. Rather than reprint the whole thing inline here, since I've still
got a couple of tweaks I want to make to it, it's included as a plain-text download at the bottom of this page.
In outline, it does four things: drops the VAX-only READONLY file-open extension; promotes every
bare 0. literal that's landing in a double-precision argument to 0.0D0; swaps VAX's
TYPE statement for standard WRITE(*,...); and replaces the VAX-specific
SECOND CPU-timing routine — which peeked directly at VMS's process-information block via
%LOC() and a hand-rolled hex opcode — with a portable stub that just returns zero. NEC2 doesn't
actually need wall-clock timing to produce correct results; it only used it to print how long a run took.
The Home Run
Patch applied, recompile:
gfortran necR2D2.f -fno-automatic -w -o necR2D2.exeNo errors. A fresh 64-bit necR2D2.exe, built from 1981 sources, on Windows, forty-some years
later. Running it drops you straight into the same prompt NEC2 always gave you:
ENTER NAME OF INPUT FILE >I put together a simple input deck — note the terminology, "decks" and "cards," straight from the punch-card era — for a 14 MHz, 20-metre half-wave dipole:
CE 14MHz HALF-WAVE DIPOLE ANTENNA
GW 1 21 0. 0. -5.35 0. 0. 5.35 0.001
GE
FR 0 1 0 0 14.0
EX 0 1 11 0 1.
RP 0 181 1 1000 0. 0. 1. 0.
RP 0 1 361 1000 90. 0. 0. 1.
ENFeed that in, name an output file, and NEC2 writes a plain-text results file — nothing binary in or out of NEC, ever. I wrote a small Java viewer to plot the pattern rather than read raw numbers:
NEC vs. MININEC: Two Answers to the Same Problem, Told Differently
Both codes solve the same underlying problem — thin-wire method of moments — and both came out of the same sponsoring world (more on that below). What actually separates them comes down to what each was allowed to assume about the machine it would run on.
The kernel. I wrote up MININEC's kernel treatment in detail on the MININEC v2 page: it subtracts the thin-wire kernel's near-field singularity out analytically using a fixed rational-plus-log approximation to an elliptic integral, so each matrix entry costs a few dozen flops — cheap enough for BASIC on a microcomputer with no floating-point hardware. NEC, running on a CDC 6600 or a VAX rather than a field microcomputer, doesn't need that shortcut. It evaluates the thin-wire kernel far more rigorously, and — for structures with wire-to-surface junctions or large conducting plates — adds the Numerical Green's Function and a magnetic-field integral equation for surface patches, neither of which has any MININEC equivalent at all. MININEC is wire-only; NEC can mix wires and surfaces in the same model.
The ground. MININEC's ground handling, in the variant covered elsewhere on this site, is either free space or a perfect-conductor image plane — a mirror image of the geometry, cheap, no lossy-earth physics at all. NEC implements the full Sommerfeld/Norton treatment for a real, lossy ground: dielectric constant, conductivity, radial ground screens, the actual physics of a wave partially reflecting off and partially coupling into real dirt. That's a substantially harder numerical problem — Sommerfeld integrals don't have a closed form —- and it's exactly the kind of computation that was simply out of reach for the machines MININEC targeted a few years later.
Put plainly: NEC is the more accurate, more general tool, and it earned that by demanding a bigger computer. MININEC is what you get when someone asks "how much of this can we keep if the budget is a microcomputer instead of a minicomputer" — which is precisely the brief NOSC gave itself a few years after NEC-2 shipped.
A Potted History: From a Rocket-Gun Company to a National Lab
NEC's lineage starts somewhere I didn't expect until I went looking: MBAssociates, a small California defense contractor perhaps better known for a completely different invention — the Gyrojet, a rocket-propelled pistol from the 1960s. In the early 1970s, under contract to the US Air Force's Space and Missile Systems Center, MBAssociates wrote BRACT: a pure method-of-moments code for uniform-wire structures in free space, running on a CDC 6600, with no ground-effects modeling at all — good enough for satellites and aircraft, not for anything sitting on the earth.
A second contract, this time for the Naval Research Laboratory and the USAF Rome Air Development Center, turned BRACT into AMP — the Antenna Modeling Program — adding ground-plane effects and moving from punch cards to disk-based text input. AMP2 followed, adding the ability to model extended closed surfaces like reflectors.
From there the work moved to the Lawrence Livermore National Laboratory, where Gerald Burke and Andrew Poggio, funded jointly by the Naval Ocean Systems Center and the Air Force Weapons Laboratory, turned AMP2 into NEC-1 — better current calculations, better thick-wire handling. NEC-2 followed in 1981, adding the Numerical Green's Function and improved lossy-ground modeling, and it remains, to this day, the highest version of NEC available in the public domain without a license — which is exactly the version this whole article has been reviving.
NEC-3 added Sommerfeld modeling for wires buried in or near the ground; NEC-4 improved small-antenna modeling and current sources but moved to a license agreement, remaining the property of Lawrence Livermore and the University of California; and NEC-5, built on a mixed-potential integral equation formulation, arrived not long before Gerald Burke's death in 2021 and isn't actively maintained. Historically, NEC-3 and NEC-4 also carried a "Military Critical Technology" export classification — a status NEC's own maintainers have periodically noted they hoped would eventually be lifted.
Wrapping It Up
So there it is: a rocket-pistol company's Air Force contract, handed off through the Navy and Livermore, ending up as a public-domain Fortran file on a Finnish FTP server that still compiles clean on a 64-bit Windows machine in 2026 with about a dozen lines of patching. NEC and MININEC solve the same equation with two completely different philosophies about what the era's hardware could afford — and forty years later, both still run, on machines that would have seemed like science fiction to the people who wrote them.