NEC Implementations
Cores, Limitations, and Work-Arounds

L. B. Cebik, W4RNL (SK)

n this series of columns, we have examined the NEC-2 and NEC-4 programs, with some attention to MININEC, in order to master to some degree the geometry and control commands and to assure that our models are as adequate to various modeling tasks as we can make them. We have not used various programs to recommend the particular implementations of NEC, but only to illustrate how we may reach or approximate (in some cases) a point where the core will calculate usable results. However, we have not undertaken in any systematic way an account of some of the differences among implementations of the cores. We shall turn our attention to this subject from time to time. Our goal is not to review programs. Nor is it to make recommendations. Instead, the aim is to note the various ways by which we may achieve the same goals in modeling using different means.

When working with implementations of NEC and MININEC, all notes carry a time-stamp. They are--assuming that I make no major blunders along the way--limited to program capabilities at the time of writing, which is always well in advance of publication. Therefore, if I assign a task method or a limitation to a program, the program may have changed by the time you read these notes. Hence, you have the final responsibility of investigating implementations of NEC or MININEC to determine current techniques and limitations before committing to one of them.

1. Core Concerns

Our first step is to note that both available versions of NEC (-2 and -4) and all versions of MININEC begin by assuming that the antenna is composed of thin round wires. Both use the Method of Moments to calculate the mutual impedance among the segments in a wire and in all of the wires that make up the antenna's geometry. From that point, the programs calculate the current in each segment relative to an assigned source, and from there the programs go on to calculate a wide variety of useful antenna performance data. The most commonly used data is the far-field radiation pattern, although some NEC entry-level programs also allow calculation of near-field, ground wave, and other data, depending upon the implementation.

NEC-2 is in the public domain. Therefore, programmers may modify the core as necessary to create a unified software package. For example, EZNEC, when using the NEC-2 core, does not transfer data to the core using the standard input file, illustrated in Fig. 1. In contrast, NEC-Win Plus creates a special input file in the standard format so that the core remains a separable module.

Licensing agreements with LLNL/UCal, which holds proprietary rights on NEC-4, require programmers to use the core as given or only with authorized correctives that emerge from time to time. There are, at present, only two programming sources for NEC-4 programs: EZNEC (Pro/4) and Nittany-Scientific (GNEC). [Ed: We do not recommend Nittany-Scientific for lack of program upgrades and technical support]. Both create standard ASCII format input files for core runs. Since the use of NEC-4 requires a separate license from LLNL/UCal--in addition to any costs associated with commercial implementations--the licensee may use the supplied core with any other I/O system available and compatible. For example, both Multi-NEC and 4NEC2 permit (with greater or lesser difficulty) access to any NEC core using their input and output facilities. A good number of NEC-4 licensees have developed their own interface systems, either because it is a challenge or because there may be special individual or company needs.

NEC-4 from the 1990s is an advance over NEC-2. The 1980s core had some significant limitations, many centered on the current algorithm used. Two of those limitations prompted extensive further developments. NEC-2 could not handle buried wires, that is, wires placed with Z less than zero when using a real ground. As well, NEC-2 introduced significant errors in the performance calculations associated with antenna elements using a diameter taper schedule. The most common taper schedule is the gradual reduction in the wire (or tubing) diameter from the center of a dipole-type element to its tips. However, the limitation also applies to biconical elements constructed in the same manner. NEC-4 uses a more complex current algorithm that overcomes much--but not all--of the tapered element difficulty. It also permits the placement of wires below the surface of a ground medium, but with geometry rules for handling wires that pass through the surface.

The most accurate way to handle element taper schedules amounts to a program add-on by those who develop modeling software. The method involves the use of the Leeson correctives, which create uniform-diameter substitute elements equivalent to the tapered-diameter element. Programs perform calculations using the substitute elements, which have proven to be highly accurate for HF antenna design work when rightly used. One common modeler flaw involves allowing the segments in the substitute sections to have radically different lengths, especially in the high-current regions of the element. As well, the Leeson corrections are only applicable to linear elements without loads (except at the very center) within about +/-15% of self-resonance. (The substitute elements are also applicable to tapered diameter monopoles fed at the base with loads only at the base.) Fig. 2 illustrates a tapered element wire table and the substitute uniform-diameter element.

Both NEC-2 and NEC-4 originated as Fortran code for use on mainframe computers. As PCs developed faster speeds and much larger memory capacities, compiled Fortran that would run in the DOS/Windows environments became common and is at the heart of almost all present implementations of NEC. However, in the 1980s, those developments were yet to come. Rockway and Logan developed an alternative modeling program with reduced features that would run on mini-computers: MININEC. The current public domain version is 3.13, although without extensive modification, the program has many inadequacies when taken above the mid-HF region or into complex antenna geometries. The early MININEC resulted in a number of commercial DOS implementations, most notably EZNEC by W7EL and AO (MN) by K6STI. Although both programmers introduced some correctives to overcome MININEC limitations, the emergence of NEC-2 supplanted those efforts. Rockway and Logan re-developed the fundamental MININEC algorithms and have marketed various levels of Expert MININEC. Teri Software has extensively modified the calculation routines to produce perhaps the most accurate version of MININEC, and in the process added features only available previously in NEC, for example, the high accuracy Sommerfeld-Norton ground calculation system. There are freeware versions of MININEC available, such as MMANA. However attractive interface and auxiliary function provisions may make the program, the basic core accuracy remains the key to acceptability. For work that is to have widespread acceptance, only Antenna Model (AM) has overcome MININEC limitations so that, in regions where NEC-4 has known accuracy, benchmark models have matched the performance of the current standard in round-wire antenna modeling.

Both NEC-4 and AM's MININEC have limitations, and the use of the "other" core may be necessary for reasonable results. For example, MININEC cannot handle buried wires. Hence, for good results with buried radial fields of various sizes, NEC-4 remains necessary. On the other hand, NEC-4 tends to go astray with angular junctions of wires having different diameters, a common occurrence in many antennas using a folded geometry. MININEC does not suffer this limitation and may be necessary for these types of problems.

Unfortunately, I do not know of an implementation of the modeling cores that allows one to shift from one type of core (NEC or MININEC) to the other within the same program. One exception exists, although it is an Excel application: Multi-NEC by AC6LA. We might classify Multi-NEC as a spreadsheet shell containing both input and output facilities, but without a core of its own (other than a public-domain NEC-2 core). Rather, it will access certain cores that it recognizes and (for commercial implementations) for which it has prior agreements. Currently, Multi-NEC can access stand-alone NEC cores as well as the cores within NEC-Win/GNEC (Nittany-Scientific), EZNEC, 4NEC2, and Antenna Model. For crosschecking the results of a model in NEC and MININEC, Multi-NEC may be the easiest route.

2. File Keeping and Swapping

The alternative to using Multi-NEC to move among cores is to swap files from one program to another. This is not always as easy a process as it may seem on the surface, since many implementations of NEC and MININEC use unique formats or proprietary file coding to meet the needs of the individual implementation.

1. Formats: The model file may be stored as an ASCII file or in a proprietary format created by the programmer. In general, the use of an ASCII file becomes evident if you can open the file using Notepad. The file shown in Fig. 1 is perhaps the most rudimentary and universal type of file, and the file name would normally be followed by the extension .NEC. For reasons that will become clear as we go along, it is readable as given by almost any of the programs that we have mentioned.

EZNEC, NEC-Win Plus, and Antenna Model use non-ASCII file formats. There are many reasons for using such formats. For example, NEC-Win Plus uses a spreadsheet format that is capable of including equations in spreadsheet form. However, the program can also import and save files in .NEC format (of the most basic form). That does not mean, however, that the program can handle any .NEC model, since it recognizes only the commands that it uses in normal operation.

Not all ASCII-readable model files are readable by other programs as model input files. For example, as suggested by the sample in Fig. 3, NEC2GO files are in ASCII format, but under the extension .ANT. The format of the file derives from but is not limited to the MININEC program MN (part of AO) by K6STI, and the later NEC-Wires program. The format allows the modeler to include in the model file a collection of symbolic definitions and equations, which then enter the wire lines as symbols rather than numbers.

Compatibility: NEC2GO illustrates another limitation in swapping files. In its FAQ, the programmer notes that this version of NEC-2 is a flexible program for certain modeling purposes, but it does not offer full support of all NEC-2 input and output possibilities.

Nec2Go does not have provision for the following NEC2 Geometry/Control statements: GA - Wire Arc
GF - Read Greens Function file
GH - Helix/Spiral specification
GR - Generate Cylinder
GX - Reflection in coordinate planes
SP - Surface Patch
SM - Multiple Surface Patch
CP - Maximum Coupling calculation
NE/NH - Near Fields
PQ - Print control for charge on wires
WG - Write Greens Function

Other entry-level programs are similarly but not identically limited. For example, both EZNEC and NEC-Win Plus construct all model geometries using only the GW command (with an implicit GE command separating the geometry from the control commands that follow). To replicate the functions of some NEC commands, programs use different techniques. EZNEC employs a collection of structural facilities to develop various shapes. In contrast, NEC-Win Plus offers a spreadsheet with full variable and equation facilities by which one can create similar structures. In NEC2GO, the symbols and equations become part of the ASCII model file, while NEC-Win Plus uses a non-ASCII file format. When saving a file in .NEC form, NEC-Win Plus strips the file of the variables and equations and uses only the current set of numerical values derived from those variables and equations.

The control commands are equally limited in many entry-level programs. Virtually all entry-level NEC-2 programs allow access only to the standard voltage source in NEC. Programmers have developed a means of using a remote source wire and a network command--invisible to the user--to provide a virtual current source. (In contrast, MININEC, as in Antenna Model, employs a true current source.) In either type of system, the user does not have access to options for plane-wave excitation and some of the current-printing facilities that are useful in connection with this command. In contrast, full versions of NEC programs allow access to the entire command structure that the core can accept. In many cases, the use of these commands requires the modeler to understand the command entry requirements. One typical error that can infect even the work of an experienced modeler is to construct a wire geometry in a unit of measure other than meters and then forget that all control commands calling for dimensions must have them only in terms of meters.

The output calculations are similarly limited in entry-level programs to the RP0 or far-field radiation patterns. In some cases, there is also no provision for the modeler to vary XNDA. However, such programs may have special functions to provide an Average Gain Test--which involves several set-up steps to be accurate. One of those steps is a change in the so-called "normal" XNDA setting. Programs may overcome some of the limitations by post-core-run calculations. One feature that is growing in popularity is the calculation of left-hand and right-hand circular polarization components.

Only some entry-level programs allow access to the near-field commands, and then usually only in tabular form. Although the development of polar 2-D and 3-D plots has reached a high level, developing graphical displays for near-field calculation results has so far defied most NEC programs.

Not all model files that end with the extension .NEC and that are ASCII-readable are fully compatible with each other. For example, the 4NEC2 file shown in Fig. 4 derives from a set of algorithms from which one may develop models of a 3-element Yagi having certain properties over a very wide range of frequencies and element diameters. The original model used the spreadsheet function within NEC-Win Plus and has subsequently been transferred to an independent spreadsheet. Arie Voors, the developer of 4NEC2 has converted the required calculations to the file format that applies to his program, resulting in a model file with much more space devoted to the calculations than to the actual model structure.

In 4NEC2, symbolic expressions have a special code: SY. Otherwise, the progression of the NEC file follows the usual form for a .NEC file. Compare this file with the one in Fig. 3. Although both files do similar work, they are not fully compatible with each other.

NEC-4: Compatibility of files does not solely concern the storage format. It also involves cores. For example, NEC-4 has introduced new commands relative to NEC-2. For example, IS and UM do not exist in NEC-2. It has also eliminated others, such as EK. More easily overlooked in attempts to swap files is the fact that numerous NEC-4 commands differ in whole or part from their NEC-2 counterparts. The inter-relationships among the RP (radiation pattern), GE (geometry end), and the ground commands differ for the two programs. The GH (helix formation) command is wholly different between the two cores. As well, a few commands have added new floating decimal entries into which the NEC-4 user can place significant values. Therefore, not all NEC-2 .NEC files will run correctly with a NEC-4 core, and NEC-4 files may run incorrectly or not at all with NEC-2. There are enough perfectly compatible files relative to the two cores that it is easy to overlook the critical differences.

File Swapping: Setting aside the cautions that we have covered, the most-used way to move files from one program to another is by using the basic numerical entry .NEC file as the medium. Advanced versions of EZNEC can input and output files in .NEC format. In general, it informs the user when a command is not translatable, and as development time passes, fewer commands become unacceptable. NEC-Win Plus has always had the ability to input and output files in .NEC format, although always within the boundaries of its entry-level command structure. It will abort conversions that involve unrecognized commands. NEC2GO has added .NEC file compatibility.

Even the MININEC program Antenna Model will now read and convert .NEC files to its format. The process is not just a matter of file-format conversion, but also involves modifying the file to fit the MININEC requirements. Whereas NEC places all sources and loads within segments of wires, MININEC places sources and loads on pulses, which are located at the junction of wire segments. AM will move sources and loads to the nearest pulse. Since a centered feedpoint or source is such a common antenna feature, AM will also add a segment to the source wire to ensure that the NEC-centered source is also a MININEC-centered source position.

One of the most flexible vehicles for file-format swapping is Multi-NEC. Because this spreadsheet shell works so closely with the cores of existing programs, it also has the ability to accept files and to save files in a variety of formats. Besides the native Excel spreadsheet format (.WEG), the program handles files in EZNEC (.EZ), Antenna Model (.DEF), and standard (.NEC) formats. Within the limitations of recognized commands and numerical formats, one may use Multi-NEC as a means of transferring antenna geometries based on the wires (GW) commands from almost any program to almost any other--at least among the group that we have been considering. (Of course, Multi-NEC has numerous other features that recommend it, but those are for future episodes.)


Our initial entry into looking at divergent implementations of NEC and MININEC has focused primarily on differences among programs and cores. Nothing here represents a review of the implementations and even less a grading or ranking of the various programs available for round-wire antenna modeling. The focus on differences has aimed to alert the modeler who may move among programs to potential pitfalls and frustrations in order to avoid them to the degree possible. Various implementations have relatively exclusive features and auxiliary functions that we may wish to use from time to time. Understanding how the program facilities differ can ease the process--and even tell us whether we can do what we want to do.

In the end, the modeler must take final responsibility for the compatibility of his models with the program he wishes to apply to them. Knowing the differences among the cores and what is available and excluded by various implementations can change that task from guesswork into informed decision-making.

Go to Main Index