In general, an input data-deck for "VARDIM" has the following structure:
1. DEFAULT request card (optional) 2. SCALE request card (optional) 3. The RAM TABLES request
4. grouping of three cards, containing the list sizes (mandatory) 3. Offset-card for non-simulation overlays (optional) Let's discuss these card formats one by one now.
1 The DEFAULT request card (optional)
Input to VARDIM begins with an optional "default" card. This card multiplies all default list settings by a constant. (See table 1)
The table sizes thus obtained can only be overruled by the SCALE request (see point 2 data) or by list specifications on the mandatory grouping of three cards. (see point 4 data)
If no such modification is desired, the user should leave all fields blank on this mandatory grouping of three cards, and omit usage of the SCALE request.
The card format to be used for this DEFAULT request card looks as follows:
12345678901234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6 7 8
DEFAULT E8.0
DEFFAC
1
Parameter:
DEFFAC: the multiplication factor to the default size (see table 1)
2 The SCALE declaration (optional)
Input to VARDIM can also contain an optional "SCALE" request. This card multiplies all list settings (default as well as user-specified) by a constant.
The card format to be used looks as follows:
2345678901234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6 7 8
1
SCALE E8.0
S CAFAC
2
Parameter:
SCAFAC: the multiplication factor to all variable fields (default as well as user-specified).
Rulebook ATP (junio 1996 - internet) H01g
Note: SCALE differs from DEFAULT in the way that DEFAULT only applies to balnk fields (user-specified rields remain unchanged). The SCALE factor, however, applies to all table sizes. If both declarations are used, then,
a) any blank field is sized using the PRODUCT of the two multipliers (i.e.
SCAFAC * DEFFAC), applied to the default table size (see table 1);
b) any user-specified field is sized using the SCAFAC multiplier, applied to the concerning field value.
The RAM TABLES request (optional)
The format to be used is as follows:
2345678901234567890123456789012345678901234567890123456789012345678901234567890 1 2 3 4 5 6 7 8 1
RAMTABLES
3
If this keyword is found, then listsize 29 is internally defined to equal LTLABL (i.e. "LABCOM" size in INTEGER words), thereby creating duplicate, alternate storage space for tables that can be used by some computers for the storage of STATISTICS/SYSTEMATIC energizations.
Grouping of three cards, containing the list sizes
The following grouping of three cards is mandatory. Here, the user can specify table sizes, fitted to his actual needs. In order to allow more flexibility, following remark is adequate:
- The table sizes obtained using the "DEFAULT" option (see point 1 data) can only be overruled by list specifications on the mandatory grouping of three cards, explained hereafter.
- If no such modification is desired, the user should leave all fields blank on this mandatory grouping of three cards.
- The SCALE factor applies as a multiplier on all fields (blank as well as user-defined).
Let us discuss the card format now. The meaning of all list sizes is already explained in section I.G.1 and will not be repeated here.
The input card for list 1-10
This input is always read. Values that should not be changed must be left blank. The card format to be used is as follows:
12345678901234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6 7 8
I8 I8 I8 I8 I8 I8 I8 I8 I8 I8
LBUS LBRNCH LDATA LEXCT LYMAT LSWTCH LSIZE7 LPAST LNONL LCHAR
4
Rulebook ATP (junio 1996 - internet) H01g
The input card for list 11-20
This input is always read. Values that should not be changed must be left blank. The card format to be used is as follows:
12345678901234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6 7 8
I
8 I8 I8 I8 I8 I8 I8 I8 I8 I8
LSMOUT LSIZ12 LSIZ13 LBSTAC LCTACS LIMASS LSYN MAXPE LTACST LFSEM
5
The input card for list 21-28
This input is always read. Values that should not be changed must be left blank. The card format to be used is as follows.
12345678901234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6 7 8
I
8 I8 I8 I8 I8 I8 I8 I8
LFD LHIST LSIZ23 NCOMP LSPCUM LSIZ26 LSIZ27 LRTACS
I 8
LSIZ29
6
Offset card for non-simulation overlays (optional)
Certain primary-level non-solution overlays have giant working arrays (a maximum of one per overlay) that are sized the same as "LABCOM" except for a possible built-in offset that very crudely adjusts for the amount of code of the overlay. If the user wants to apply an additional offset manually to this storage, he can add a data card as follows:
12345678901234567890123456789012345678901234567890123456789012345678901234567890 1 2 3 4 5 6 7 8
I
8 I8 I8 I8 I8 I8
ROOT20 Unused Unused ROOT25 ROOT26 ROOT27
7
The functioning is as follows:
1) "ROOT20", cols. 1-8, for plotting and statistics tabulations;
4) "ROOT25", cols. 25-32, for "LINE CONSTANTS";
5) "ROOT26", cols. 33-40, for "SEMLYEN SETUP";
6) "ROOT27", cols. 41-48, for "CABLE CONSTANTS".
Users of overlaid program versions should be using this feature carefully.
But virtual program versions are more common, and in this case, data requirements are much simpler. All UTPF overlays use the same virtual storage,
Rulebook ATP (junio 1996 - internet) H01g
so only a single offset, keyed in columns 1-8, will be used. Further, the size does not matter much, for machines with wide-open virtual memory management.
But there are exceptions (e.g., the badly-constrained AT&T UNIX PC).
The sign and the size of the offset or offsets is impossible to predict.
When the idea began, overlaid computers were used, and offsets were generally positive. The non-simulation overlays were shorter than the time-step loop, so a positive offset allowed greater table size without any greater burden on memory. The idea was to extend non-simulation overlays to the length of the time-step loop (overlay 16, which was the longest EMTP overlay). But then along came virtual computers, and enormous list sizes were requested. Unless specially compensated for, the giant working arrays would be dimensioned far beyond any reasonable program needs. To compensate, offsets became negative.
For VAX, during March of 1980, an offset of -128500 was being used. This was at a time when LTLABL (the size of "LABCOM") was 207363 integer words.
Using the negative offsets saved a little virtual address. Finally, some program versions were modified so as to save "LABCOM" within the working space of non-simulation overlays, so there was a return to positive offsets. There are no general rules other than that the user is referred to the installation-dependent section for his computer of interest.