NEC (-2 and -4) allows the user to introduce at the very beginning of a model file the CM input or card. CM means comment, and the user can introduce as many CM lines as needed to say anything that he or she wishes to say about the model. Each 80-character line allows 77 text characters (allowing for the necessary CM and space at the beginning of each line). With a virtually unlimited number of lines, one might come close to writing a full report on the model.
The string of CM cards requires a closing line entry line, CE. This entry terminates the comments and must be followed by a geometry entry, such as a GW wire entry. The NEC output report will print all of the CM lines at the beginning of the file. CM lines have no affect on any computation made by the NEC core.
Various commercial implementations of NEC handle the CM inputs in different ways. For example, EZNEC has two different CM-relevant entries: the antenna model title, which is saved within the .EZ model file, and the antenna notes, which are saved in a separate .TXT file having the same file name as the model itself. The title is visible whenever the user calls up the model. As shown in Fig. 1, the comments appear in a separate window only when called. In the Pro version of the program, when the user converts an .EZ file to .NEC format, both the title and the notes become CM lines in the converted file.
NEC-Win Plus also has a special screen for comments, a sample of which appears in Fig. 2. Since this screen contains the file name and location, adding that data to the comments is unnecessary unless conversion of the .NWP file to .NEC format is anticipated. There is no separate model title, so that information must be included in the comments. All of the data in the special "Comments" box becomes a set of CM lines in a file saved in the .NEC format.
Programs such as NEC-Win Pro and GNEC present the user with a standard ASCII page of lines making up a .NEC-format model file. Hence, the user introduces comments by opening a new line, labeling it CM, and then filling the remaining spaces, as needed, with whatever the user views as an appropriate comment.
Why Dwell on Comments?
A natural question is why I should linger over a calculationally non- functional aspect of NEC. Perhaps the answer may become obvious from Fig. 3, a simple model file (of a 3-element 2-meter Yagi) in .NEC format.
The sole CM line yields a model title, and in highly truncated form at that. Perhaps the only clear information is the design frequency: 146 MHz. Missing is the antenna type--which we may glean from examining the GW lines--and any other data about the antenna.
This style of model file used to be common in my directories, and is typical of files from others that have come my way. Indeed, I have stored reams of paper with information about the models that I have constructed and evaluated. Correlating the paperwork with an actual model on file has often been a laborious task--even when I remembered to write down the location of the file.
Gradually, I began to realize that I was passing up a potentially important NEC facility. So over a period of time, I developed a system of using the CM lines to encapsulate the most important model data. The system that I developed is based on the main lines of work that I do. Hence, it will not be satisfactory for every modeler. However, it might set the wheels in motion for the development of your own system.
The main categories of CM entries that I use are the following ones.
These categories are fully functional for my work, which focuses on models of antennas with energy sources, where the key data include the source impedance, the far field information, sometimes the near-field information, and sometimes the relative current magnitudes and phase angles on the antenna elements. There are numerous other applications of NEC, including electromagnetic compatibility analyses, radar profiles, receiving tests using plane-wave excitation, etc. These applications may require the development of different categories of information to place within the CM lines of the model.
The key benefit of developing a standard list of information categories is that one may simply label the information group with the category number and save a good bit of typing. As well, the information will be consistent from one model to the next, allowing direct comparisons.
Some Details of the Category Contents
Let's look at each category in a bit more detail.
1. Model file location and file name: This information may seem otiose, since it is buried in the model itself and not outside of the system of directories where the models lie in storage. Granted, I do keep an external list of models, with a basic title and their locations. However, I often have the occasion to move a model from one directory to another to group it with relevantly similar or comparative models. In each case, I add the new location to the old within the model CM lines, including any file name changes that might occur due to the new use of the model. I also add to the list any direct scalings of a model from one frequency range to another. This series of entries gives me the ability to track the heritage of a model.
2. Full modeling task specifications and/or origin of the antenna modeled: This category has 2 functions owing to the different reasons for which I may approach a model. One reason for modeling is either to develop a working design or to analyze an existing design. These tasks do not occur in a vacuum, but are often parts of a specific task. Listing both the task and the task parameters provides insight into later remarks in category 6, the reactive commentary to the model. Hence, the task specification should be as complete as possible within the limitations of truncated entries. If the task involves analysis for the achievement of certain levels of gain, beam width, bandwidth, rear pattern performance, etc., all of these should be noted. Comparing two models many moons later becomes simpler when the performance of the models is read in the context of the original tasks that generated the models.
Many models have their basis in existing antennas or antenna designs. Listing the essential particulars of the design origin is critical to avoiding errors in model reports, to re-inventing already existing designs, and to finding other details about the antenna design. Notes should also include revisions to an original or basic design, so that a sequence of models--perhaps versions A through G--reveal the evolution of a modified design.
3. Overview of the basic construction of the model: An overview of the model's basic construction can save a good bit of time ferreting out the information from the lines of a model (or from the various windows in some implementations of NEC). The data should include the units of measure used in the GW lines. These units may be different from the units used to express construction details and, hence, may allow correlations of numbers without calculation between some source material for the antenna and the actual model entries. The basic data should also include the element diameter, if that is the most usual wire measure used in your design work, since the .NEC wire entries will use the radius. (Numerous implementations of NEC provide a wire construction table that employs the wire diameter.) The element material should find a place in this list as a check on subsequent LD5 entries. As well, one should note the level of segmentation used, whether expressed in terms of the number of segments per element or segments per (half-)wavelength.
Of course, we should not omit a set of element dimensions. The format that we use for these dimensions may vary with the system that we use to enter coordinates. For free-space simple (1 antenna) models, one might use element lengths expressed in terms of the "+/-" values of half lengths. If we model a system of antennas where the overall dimensions might be opaque due to scattering the multiple antennas throughout a coordinate system, full length measurements of elements may prove more useful. The separation of elements in a multi-element antenna can follow whatever convention one uses for constructing the model. Some modelers center such antennas equally behind and ahead of one of the coordinate system axes. Others count from zero for the rearmost element, with positive values for the other elements. Still others place the driven element at zero and count fore and aft of that element. A consistent convention from one model to the next--or a second data set if a certain task forces one to use a non-normal convention--generally saves interpretation time. Amassing data is only useful if it simplifies interpretation. If the data concentration complicates interpretation, it is likely time for a re-evaluation of system of recording it.
4. Special features of the model: Every data collection system needs a catch-all bin for data that just seem to have no home but are important to a model. The lack of a home is usually a function of the fact that the data involved are model-specific and do not appear with all models within a roughly coherent collection. So I created a home for all such data.
The data that I almost always include in this category range from the antenna environment (free-space, x WL above y ground, etc.), structural aspects of the antenna (such as the element relationship to a supporting boom), and the specified feed system and any matching systems used to obtain a specific feedpoint impedance. However, many antennas have specific data applicable almost only to them.
For many models, there are special data pertaining to sources, loads, and/or transmission lines that may be apt for this category. To give just one example, consider Fig. 4, the outline of a 5-band 2-element quad beam using a separate feedpoint for each band.
Quad loops require 4 wires each, and there are two sets of loops per band. Keeping track of the source wires and segment numbers for each band can be daunting, especially if the model does not use a strictly progressive mode of construction. In this case, the wire order is 20, 15, and 10 meters (driven, then reflector wires) followed by 17 and 12 meters (driven and director wires). I know this instantly from the comments, where I stored the requisite source information, recorded in Fig. 5. Gleaning this information from the GW wires would take a good bit of time, especially if I had not worked with the model for some months.
Of course, there is more than one way of handling the sources in cases like this. We may keep a single EX (excitation) input line and change the requisite details. However, in some programs, such as EZNEC, one enters the source information in a table. In such cases, we might wish to use the lower portion of Fig. 5 as a means of source entry. We enter the location of all of the sources and then activate only one of them by assigning a source magnitude that is greater than zero.
Load data for load types LD0 and LD1 show the value of inductance or capacitance. We might wish to enter in category 4 the corresponding reactance value at the center design frequency. Alternatively, a load type LD4 uses a reactance value, and we might enter here the corresponding value of inductance or reactance.
Transmission lines have many functions, including their use simply as transmission lines. However, open and shorted stubs are often common features of models used for impedance matching and phasing lines in collinear arrays. Horizontal and vertical phased arrays also require transmission lines. Category 4 is a convenient place to record the functions of each transmission line (TL) in the model, with such other particulars as may be useful to sort out a potentially confusing morass of TL constructs.
Although our original sample model Yagi is in free space, it might well be placed at a specific height in terms of a wavelength above a ground of a certain type, whether simple or complex. Entries in category 4 can obviate the need to interpret the numeric entries on GN or GD lines in the model.
How many more special entries you might need depends on the model particulars. The useful data will emerge in part from the model parameters and in part from the overall modeling task. However, if a large series of models that are part of a long-term general task have consistently used data elements, then you might consider creating an additional regular or major CM data category.
5. A basic performance report: The CM lines are not likely the best place to store complete frequency sweep data for a given model. However, a truncated performance report at the center design frequency may be useful when surveying models. For the class of antennas that I typically model, far field and source data generally form the core of my needs. For the Yagi in Fig. 3, the gain, front-to-back ratio, beamwidth at -3 dB points, source impedance, and 50-Ohm SWR comprise the central data. Since the antenna is a wide-band unit, my interest would extend to the band edges as well as including the mid-band frequency. Hence, I might record a short data table for 144, 146, and 148 MHz.
The results of all of our data summarizing appear in a revision of Fig. 3, shown in Fig. 6. The CM lines now occupy more space in the file than the geometry and control inputs that affect calculations. However, ASCII files are very small, and the added data requires very little storage space. Hence, adding the information costs little more than the time it takes to record it.
Having the data within the model file allows me to re-learn what I originally learned by running the model. Now I need to run the model only if there are additional data that I find a need to accumulate. Whether to include some of the new data in the CM lines becomes a real time decision based upon an estimate of my later needs for seeing that new data.
6. Commentary on the model, including reactions, potential uses, comparisons, etc.: We have so far omitted category 6. from the list to this point, because it is perhaps the most task-driven entry of all. The comment shown in Fig. 6 indicates my initial interest in the Yagi, as a possible directional utility antenna for the 2-meter amateur band. The boom length (under 28") promised a light-weight antenna that one might construct using a non-conductive boom material and supporting from the rear. Hence, with a suitably flexible support system, one might easily change the orientation from horizontal to vertical and back again, a desirable feature in a utility antenna. I might also add to the simple remark in Fig. 6 open questions about transforming the model into a real antenna. For example, any implementation of the antenna would require a split driven element for direct feed, and this fact promises to complicate construction relative to the simple mounts required by the parasitic elements.
Since the exact information suited to this category is task specific, it is impossible to say in general what sorts of entries would be most useful. In a series of models set up for comparison, one might record the ranking of the given model--or a series of rankings within the series based upon a list of critical parameters. It likely is also useful to record reactions, especially if they result from surprise--perhaps at how well or how poorly an antenna performs in one or another department of concern. As well, one might enter here what model modifications are envisioned, and the file name and location of the model that incorporates those revisions.
Equally important to recording evaluative remarks that fit within the task at hand is to enter comments that are relevant to the model but which fall outside a defined task. To see a potentially new use for an antenna type is significant, even if not within the scope of work.
Printing
The utility of the CM lines as a basic data storage medium can be lost if we only save the model file and never refer to it again. Therefore, my practice has been to print a copy of the model file and include it in the sheaf of papers recording output data. This practice requires attention to the provisions of the modeling program used. In EZNEC, one may print the comments from one screen and print an antenna model description from another. NEC-Win Pro permits saving a model in .NEC format, and thus printing can be a single step. Generic NEC programs would use the input file as the basis for printing.
Very often, printing the input file can save reams of paper often necessary to print the NEC output file. A number of programs permit one to print selected sections of the output file and thus avoid having to waste paper on portions of the NEC output file that serve little function relative to an assigned task. Of course, in very large models, the input file itself may run to many pages, especially if one does not take legitimate short-cuts. For example, a 200-wire model with all wires having identical material loads (type LD5) requires in many set-ups an extra 200 lines of LD entries. We may truncate these to a single line using techniques spelled out in the NEC manuals. (Not all programs permit conversion of LD5 lines into a single line, while others permit only a single material load entry for an entire antenna structure.)
We have explored one systematic way of using the CM lines as an aid to modeling. The system shown is one that suits a specific modeler, namely, me. It may require anywhere from minor to major revision to be suitable to some other modeler. In a departmental setting, I can imagine the situation devolving into a series of interminable meetings trying to decide the best set of categories for everyone involved in the modeling enterprise. One can only hope that simple rationality will prevail over modern group dynamics.
Nevertheless, the sample system that we have explored does demonstrate that the CM lines represent a resource that we can too easily overlook. If these notes make you aware of the potential for these lines, then they will have done their work.
Go to Main Index