a7 & TRANSIENTS FROGRAM MEMORAN DUM Ot. 2 24 December 1981 ‘Dr. Hermann Doumel, Prof., Univ. of B.C., Vancouver, CANA) jo Bueno Guimaraes, FUBNAS, Rio de Janeiro, BRAZIL ‘Dr. Arun Phadke, AEP Service Corp., New York, N.Y. listed addressees . W, Scott Meyer an, ‘(CEEMANY BPA, Bute BGA Bernd Stein, FGH, Mannheim, WEST . , 0, Box 3621 Dr. Akihiro Ametani, Prof., Doshieha Univ., Kyoto, JAPAN — a Russell Brierley, Ontario Hydro, Toronto, CANADA © Bete 4404 Dr. Bob Lasseter, prof., Univ. of Wisconsin, Madison Dr. Daniel Yan Donmelen, Prof., KUL, Heverlee, BELGIUM | BPA, EOGA —-- Dr. Tsu-huei Liu (library cop; BPA, BOHC —-- Bob Hasibar & Alvin Legate Subject : December 1961 trip to Montreal, New York, Edina, Duluth, & Minneapolis WSM is now relaxing in Minneapolis, on annual leave (vacation), following a trip of considerable EWTP significance. Sitting in the nearly-deserted University of Minnesota library, I begin this account of recent EMTP accomplishments between chapters of a murder mystery ("Maigret Hésite," par Georges Simenon) which must remain in the building. Included are talks about possible coordinated EMTP development (Sect. I), testing of an "M31." Burroughs EMTP (Sect. II), our first ENTP look at a microcomputer (Sect. III), the setup and testing of an "N31." Prime EMTP (Sect. IV), and the setup and testing of an "N31." CDC ENTP (Sect. V). © MEETING WITH IREQ AND ONTARIO HYDRO CONCERNING POSSIBLE COORDINATED EMTP WORK The trip in question would not have been made, had it not been for the one day of MIP discussions which were held in Montreal (actually at IREQ, near Varennes, which is perhaps fifteen miles from Longueuil at the end of the metro) on Friday, December 1th. John V (Dr. John Vithayathil, Chief Technical Engineer - Network) led the BPA delegation of two, with WSM present just as a technical adviser, to ensure that there was no misunderstanding regarding EMTP details. Representing Ontario Hydro was Dr. Praba Kundur (Senior Engineer, System Controls and Transients, and Vladimir's immediate supervisor), and Viadinir himself (Dr. Vladimir Brandwajn). The IREQ delegation was larger, naturally, due to location of the meeting. Although sone of the titles shown may be slightly dated, they nonetheless give an indication of the level of the discussions: Dr. Lionel Boulet, Director of IREQ Dr. Raymond Pronovost, Director, Systen Engineering and Electronics Dr. Chandra Krishnayya, Program Manager of HVDC Transmission and Power System ControlDie 2c Dr. Moneilo Gavrilovic, Program Manager of Simulation Studies for AC Power Systens Dr. Yvan Robichaud, Progran Manager of Power Systen Analysis Methods The subject of this meeting is itself not at all confidential: how those organizations having ENTP interest can most effectively coordinate their activities so.as to “finish ETP development” within a reasonable time. As for results, however, it would be premature for me to make any comment at all. @® "M31." BURROUGHS EMTP TESTING WITH SJM3 IN NEW YORK CITY WSM took the overnight train from Montreal to New York City, and arrived at Penn Station early Saturday morning, December 12th. Stoney (Mr. Stonewall Jackson MoMurray, III; otherwise known to the Ebasco computer operators by the moniker “SI3") met me in the lobby of Two World Trade Center shortly thereafter, to begin three hard days of further work on the Burroughs ETP. It is assumed that anyone reading further into this section has access to my account of ten months ago (vol. X, 14 February 1981, pagination ECWB) when we first struggled together for one week, working to make the EMTP Burroughs-compatible. If the battle of last February proved basic Burroughs EMTP feasibility, this time we were preoccupied with details, using a program version ("M31.” vintage) which was thoroughly tested in Portland, anu which will be retained indefinitely for purposes of comparison, and will be further refined. Indeed, there must be some additional refinement of the UTPF, since several very subtle Burroughs MTP complications vere observed. I personally examined the "M31." Burroughs EMTP solution of forty BENCHMARK DC-?? and DCNEW-?? test cases, and can certify that 32 looked perfect. But eight reveal complications of varying degrees, and will require further study and thought back in Portland. Stoney was well prepared for me, having previously forced the "M31." Burroughs NTP FORTRAN through the compiler, and reconciled obvious problens with Tsu-huei vie telephone. Indeed, this was going on even before I left Portland, and the Burroughs compiler can be credited with identifying a number of small problens: SPi. There were several new FORMAT problems, including both Hollerith undercounts (S.N. 91 of "DCEIGR", with UTPF ident "M29.4486"; S.N. 286 of "SUBR47", with UTPP ident "N31.6755") and one VAX-11 free-format usage (UTPF ident "M31 .6368" of “GUTS44"). VAX has the enbarrassing habit of passing over uninterpretable FORMAT items without complaint. Yor example, the "SUBR47" difficulty involved the character string “24H THUS, THE CABLE BECOMES,” ---- with the terminating "S" being character number 25. I am convinced that such explicit character counting would be a valuable addition to our special UTPF editor which is now evolving slowly, so that such errors would end once and for all, and so that the programmer himself vould be freed of the counting. Ms. Sandra Raposo, an engineering technician of our Section (Mike McCoy's “EOGB") has been working on what I started (“EDIT" of "EMTPSPY"; see page IEEO~11, Point J, 17 July 1981) during my absence. SP2. The FORTRAN COMPLEX of "CABLE CONSTANTS” fell below ANSI 66 standards again, following Aki and Naoto's vork of last sumer. Actually, Burroughs only generated varning wessages, so we recommended that Stoney not make any changes himself. But Tsu-huei has massaged the UTPF code in Portland (corrections will have "52." UTPF idents), producing sixteen new records in "BIGCR4" and one new line in “TRANSP". The definition of COMPLEX variables using REAL right hand sides seems to be the repeated infraction, I believe.OTTM-3 SP3. The "MARTI SETUP" code of overlay 40 involved isolated usage of LOGICAL variables, mostly down in little supporting subprograms which I had failed to scrutinize closely. I do now recall seeing this usage, and apparently I failed to tell Jose to remove it (in accord with general UTPF policy, which does not allow any such usage). Well, the Burroughs compiler fortunately recognized a patently-illegal mixture of INTEGER and LOGICAL variables somewhere in overlay 40, and this prompted Tou-huei's careful consideration of all LOGICAL variable usage, and its conversion ‘to INTEGER variables. Modules "FSHFTA", "FUNPA", "FNKA", and "SUBR40" of overlay 40 are involved. I believe Tsu-huei concluded that VAX execution was correct as Jose left the code vith us, but that results by other computer systems (those not sharing VAX's unusual choice of minus one for TRUE) might not be. In all, there will be nine new "N52." UTPF records reflecting Tsu-huei's changes (which Stoney also made). It was at this point that WSM entered the picture, looking at Burroughs ENTP output, and advising Stoney about changes (all of which he made through terminals using CANDE, which I do not pretend to understand). In the order that problems were identified, my notes indicate the following observations: OBI. The card-reading module "CIMAGE" suffered from some superficial deficiencies, following WSM's last-minute update of it before the Burroughs translation. Specifically, the two declarations DIMENSION BUFF10(14) and EQUIVALENCE (ABUFF, BUFFi0) tad to be added, so that comment cards would be interpreted properly in the EMTP printout. Earlier (while WSM was still in Portland), Stoney had pointed out a couple of duplicate statement numbers ---- the result of adding new comment-card code without deleting the old code. Nothing very sophisticated or difficult about these errors, anyway. 0B2. Test case DCPR-1 terminated with a subscript error in overlay two, which was readily traced (thanks to our nice new column 73-80 CANDE serialization, which greatly simplifies Stoney's tracebacks) to a DIAGNOSTIC printout involving undefined subscript IBRi. This is UTPF record "M31. 384" just below S.N. 6621, which was legalized by the addition of IBRi = 0 in overlay one immediately folloving the existing IBR initialization (UTPF ident" 5493"). 0B3. I had coded a Burroughs "PACKCH" module in FORTRAN, using ENCODE/DECODE (actually, READ/WRITZ involving memory). But this failed miserably, for ve discovered that no subscript can be specified when giving the menory address. That is, it must be cell one of any vector where any character packing/unpacking operation begins. After some unsuccessful modifications, ve abandoned my new module, and fell back on the "N28.+" one which used the system utility CONCAT (see Vol. 10, 14 February 1981, page ECWB-10, Bug 7). We may just grit our teeth, concentrate hard, and repair that old module (vhich does not work for both 4 and 6-character input words, as I recall Stoney's earlier warning). OB4. In both “OVERIO" and “OVERIi", it was discovered that the conditional WRITE or READ involving LUNIT2 had subscripting trouble. This follows the REWIND LUNIT2 statements which bear UIPF serialization "M19. 896" and "M20.2260". Well, the implied D0-loop can not begin at IOFGND or IOFBND for Burroughs, since these offsets are zero, and the program would then be attempting to access one vord off the end of the COMMON block which stores the vector. For VAX, we were just transfering one extra, undefined (garbage) word; for Burroughs, an operating systen error stop is the result! Apparently this trouble was not spotted last February because control only passes to the offending statement if there is need for the injected~current calculation (either for S.M. initialization, or for phasor printout).Oy elie = 0B5. In “OVERIO", the phasor steady-state solution code uses subscript IM as an index of NORDER before it is checked for being positive: 9890 4550 IN = NORDER(TM) 9891 IL = NORDER(J) 9892 IF (IM .BQ. 0) IN = IL hia led to an error termination by the Burroughs operating system, for some test case. lacking any fundamental understanding, we simply made the execution of the problem statement conditional on IM being positive. BG. The overlay-31 "PRINTER PLOT" displays were initially erroneous. On the ADDS terminal, such plots were blank, while printed copies were filled with question marks. While I was explaining to Stoney that this was not possible, that the logic of "LINPLI" was simple and proven, he asked whether we called the SUBROUTINE more than once! This was indeed the problem (Burroughs methodically destroys the values of local variables between SUBROUTINE calls). It is local vector KUT(131) which caused the problen ---- to be remedied by the addition of a DATA statement involving the symbol KUT. More about this later, after specific observations are complete. OB7. The Burroughs EMTP had isolated trouble with our REAL translation of ALPHANUMERIC. I say “isolated” because DC-3 through DC-17 were successfully solved without a hint of difficulty. Then data case D0-18 stopped with KILL = 139 and ISTAT(19) = 126 in “TACSIA" “? overlay one. Trouble was clearly in the D0 125 loop, and Stoney gets the credit for correctly appreciating the problem, as we both studied the code along with some special diagnostic printout which we had produced. Iwas claiming that what happened was impossible, vhen suddenly Stoney suggested that a minus sign ("-" as read from a TACS data card) might indeed test as being equal to a blank (variable BLANK of /BLANK/)! TI do not profess to understand this though it sounds suspiciously like that Univac problem of many years ago, which I described in great detail (see Vol. II, 5 February 1975, pagination PCAS). When I reminded Stoney of my original desire to translate ALPHANUMERIC as INTEGER, he reiterated that this would be risky, raising a whole different set of problems. Stoney's correction now appears as follows: M14. 694 126 DO 125 T=1,5 c IF ( ALPH( I) .NE. BLANK ) GO TO 12601 (BURROUGHS FAILURE) IF ( .NOT. (ALPH(I) .IS. BLANK) ) GO 70 12601 Don't ask me what's going on here (if Stoney can find the time to put an explanation down in writing, I will publish it)! Further, for the future good of all, vhat might best be done about the problen? 0B. Those built-in random numbers of the D0-24 "STATISTICS" test case vere not giving the same ansvers as our VAX-11/780, which led to several discoveries. I believe that Vladimir may have made such a complaint (about OH Univac solution of "29." vintage?) recently, though I can recall no resolution or even detailed investigation at the time. Anyway, we verified that XMAINX was negative as required for calling “SANDNK", but that index "L" was not being preserved between calls (the same problen as 086). Adding DATAL/O/ within "SANDNA” changed the answer, but there still was not agreement in the switch closing times between Burroughs and VAX. Turning on the DIAGNOSTIC printout in overlay 12 showed that the WRITE vhich is built into "“SANDNK" was never executed ---- because, Stoney observed, blank COMMON was missing from the Burroughs “RANDNK" module. We added this, only then to find an operating systen termination in "SANDY" because of a subscripting error (i=0). Yes, yes, yes, Viadimir! For KT = 1, index l= 0, and ve are accessing sone non-existent memory location which precedes the hundred standard random nunbers Which are built into the module. Oh well, maybe for "M31." versions thie vill finally be fixed.DT. 0B9. Another problem with a non-preserved local variable occured while solving test case DC-31 ---- which originally stopped with KILL = 169 and LSTAT(19) = 8050 in overlay two. The error message itself was quite irrelevant (pertaining to “MODIFY DELTAT"!), but that was a cosmetic complication. Tsu-huei rapidly identified variable IPSEM as being the culpret, after Stoney had read her a list of all local variables of the module over the phone. After adding a statement DATA IPSEN / 0 / at the top of “DISTR2", the Burroughs EMTP then produced a correct solution. B10. Rotating machinery test cases generally had problems, for reasons which are not yet understood. Only test case DO-34 (Hian’s three-phase synchronous machine) appeared perfect, through step number 60 at which point the solution was stopped by us. The companion three-phase induction motor simulation of DC-35 was very close (typically accurate to about three decimal digits on the final step), though differences are unexplained. The Brandwajn S.M. simulation of test case De-26 also had small differences, including minor structural ones (e.g., one fewer output columns). Finally, the SCE S.M. simulation of test case DO-25 was quite erroneous at tine zero for “Part B" of the dual ("Part A" initialisation printout looked perfect). OBI1. The "MARTI SETUP" fitting of test case DONEW-3 differed immediately for mode one of Zc, on the very first iteration. Nothing more is mown at this time. On the other hand, the associated simulation (the John Day to Lower Monumental fault s’ ulation of DCNEW-4) showed exact agreement at step number 2000 for all variables. If Jose is to be sent this code shortly, at least his problems will be localized (confined to overlay 40)! OBI2. To rapidly terminate, let me list those test cases which vere apparently solved perfectly: DC-5 through 7, 9-11, 13-24, 27-34, 36-39, and DONBW-4. The CPU Stolle Road simulation of DC-8 was close (3-4 digits of agreement on the final step), but different. ‘the step-sero values of D0-12 are drastically different, so this phasor solution must be further investigated. Case DC-17 was also very close (J-digit agreenent), but different. So where does the "M51." Burroughs EMTP stand? It certainly is in better shape than the preceding "N28.+" code, which should now be discarded. But some problens renain. In light of the above-documented identification and correction of unpreserved local variables, this vould seem to be the most promising avenue of investigation. Since ANSI standards never have guaranteed the integrity of such values after a RETURN is made, it is the UTPF, rather than the Burroughs compiler, which would seem to be lacking. Burroughs just happens to be the first computer systen which we have tested that methodically destroys such values. Now that all subseripting problems appear to be resolved, this is the one remaining general problem. By use of the seguented VAX EMTP (see page IEE0-2, 17 July 1981), we can insure that such local variables are not preserved once overlay boundaries are crossed. This will be a big help, allowing us to work on each overlay separately. With DIAGNOSTIC printout better localizing the point of first differences, we can then methodically zero all local variables of modules as each is entered. Tsu-huei learned from Walter that such variables are marked on a VAX FORTRAN compilation listing, so there is no theoretical problem. Within a few weeks, ve should know more, provided Stoney can send us the appropriate Burroughs [MTP DIAGNOSTIC printout, and provided THL and WSM are not forced to launch into new ENTP development before these old problems are cleaned up. My recommendation is that only “corrections” (not "additions" or “alterations") be made, as long as we can profitably remove "N31." errors, while we update the ENTP Rule Book and ready it for another printing.DTTM-6 @) APOLLO : INITIAL EMTP EXPERIMENTATION WITH A MICROCOMPUTER A. Introductory Impressions of Apollo Hardware and Software secretory _inpressions of Apollo Hardyare end Software WSM spent two days in Edina, Minnesota (a southwestern suburb of Minneapolia) working with Messrs. Ton Varilek and Jim Weaver of Minnesota Power on an Apollo microcomputer system. Although we did not succeed in setting up a complete working ENTP within the limited tine which was allowed by advance scheduling, we did learn enough about the system (and we did get enough of the front end into execution) to predict that Apollo and similar microcomputers represent a new force to be reckoned with by ENTP planners --~- particularly those who are short of cash! It does now appear that $5000 would purchase a complete computer system which would be capable of running all non-"STATISTICS” EMTP simulations of a large power company. The remainder of this section is devoted to a detailed account of our findings which lead me to this conclusion. Work began at 09:00 AM on Wednesday, December 16th, when WSM showed up at the Edina office of Apollo Computer, Inc. (7600 France Avenue South, Suite 105; Bdina, Minnesota 55435; phone: [612] 835-0580). Tom and Jim were already there, having just driven the 150 miles down from Duluth that morning. John Gross, the Apollo hardvare and software specialist, vas having coffee with then in the adjoining conference room. On the end wall in this location was a table supporting two key doards and display tubes, with the associated computer processor cabinets smoothly xtending the table top at each end. Immediately, my concern about noise was answered: Apollo vould fit into an office environment with minimal intrusion. As Bob Newell said about PERQ (page SSIA-20), one can carry on a normal conversation and not be avare of the air which is forced out the back. Power requirements must be low, as Tom observed, for the air was not very varm, either! In terms of both noise and heat, Apollo reminds me of a kitchen refrigerator. Before we actually did any computer work, John projected a number of slides which summarized Apollo concepts. Most interesting and novel to me is the ring network which is used to interconnect two or more Apollo nodes. Recall (see page SSIA~17 of the preceding meno) that each keyboard and screen has a dedicated supporting processor, but perhaps no additional system hardware (e.g., disk, magnetic tape, line printer). The ring provides high-speed access to any such remote devices, and is continuously circulating a "token" (bit pattern "011111100") in the absence of any user communication. When one node wants to send data to another node in the ring, it grabs the token as it passes, converts it into a destination address, and follows this by some control characters and up to 1024 bytes of data, which then zip along at 12 megabits/second. ‘There are redundancy checks and an acknowledgement that the message vas successfully received, of course. Since eight bits make up a byte, data circulates around the ring at 1.5 Mbyte/sec, which is precisely the speed of our own VAX UNIBUS (to which the printer, tape drive, and all terminals are connected)! ‘There thus is nothing “micro” about Apollo internode communication speed, in spite of the inexpensive medium (thin coarial cable, costing something like a penny an inch) vhich is presently being used. Probably the most visible difference between Apollo and any other computer systen which I have ever seen before is the display systen. About eight inches wide and ten inches high, the screen provides a high-resolution (approximately 100 dots/inch) display for either graphics or varying character displays. But more important than the high resolution itself is the speed with which displays can be altered: at 32 million bits per second! Since the screen has just under a million dots, this suggests that "movies" are clearly feasible - at 32 frames per second! A demonstration which drove the screen from the floppy disk included an air plane which pulled an Apollo banner across the screen, thereby illustrating the potential.ee The application to interactive EMTP execution was immediately obvious (for a ROLLing PLOT, with points added on the right edge only, to simulate a strip chart record in which paper movement was to the left). For character communication, the high speed display is even more startling. We in Portland drive all of our VAX CRT terminals at 960 characters/sec (VAX-11 9600 baud, not to be confused with Prime 9600 baud as nin Duluth), which is fast by mainframe standards. But Apollo speed makes this look as if it were standing still! The visual'effect is truly astounding, almost an optical illusion, it is so fast. With Jim at the keyboard, controlling the display according to his own inclinations, Jin himself may not have had trouble adjusting to changes in the screen display. But my eyes did, so fast was the modification. If our own DEC VI100 displays roll rapidly from bottom to top, Apollo display changes seen more like those of a slide projector. A few words might be said about the Apollo central processor, and its relation to Motorola microprocessors. In the Apollo diagram shown below, the CPU block is built around two Motorola 68000 chips, with one used for the computation, and the other reserved for virtual memory considerations (page faults). The basic Apollo computational board is standard size (about sixteen inches square?), with the two Motorola chipe appearing off on one edge ~~-- a very amall part, physically, of the complete computer systen. That "DISPLAY MEMORY" box consists of one eighth of a megabyte of dedicated storage, used only to refresh the screen via the "BITMOVER" box. The "MEMORY" box is for computer central memory, which is physically isolated on separate boards (256K bytes per board at present, just like our VAX). Although some call the Motorola 66000 chip a "16-bit microprocessor", it in fact has 32-bit registers, allowing 24-bit virtual addresses and 22-bit physical addresses. Hence it should not in any way be confused with 16-bit minicomputers, most of which have inadequate address space for the voluminous EMTP code (and to a lesser extent, ENTP data). That 24-bit virtual address provides 16 megabytes of process address space, which equals the long-famous IBM limit, as well as our own present VAX operational limit (the VAX default limit is between 4 and 5 MB). There is nothing small about Apollo's menory, either! Figure: Apollo DOMAIN Node OrganizationDTTM-8 First, consider Apollo compilation speed. Because the Edina office of Apollo does not presently have a tape drive, a reel of "N31." Apollo EWTP FORTRAN had earlier been mailed from Portland to Boston, where it was put on floppies. The first of these contained all code through the end of overlay 2 (exclusive of separate INCLUDE files) ---- 9431 cards of the UIPF. Our first compilation required 17 minutes and 24 seconds (4:50:02 - 4:52:38 = 17:24), though there vere a few FORTRAN errors. A subsequent non-optimized, corrected compilation took 19:44 (5:53:15 - 5:33:31). As for the discrepancy, I am unsure (we may have represented significant interference working [playing?] in parallel, through another window). Anyway, averaging these two times and extrapolating to the full 70000-card program gives the estimated total compilation time of about 138 minutes. While this is not quite up to current VAX standards (about 55 minutes are required), this is in fact substantially faster than the original VAX compiler with which we coexisted for a year and a half! Pound for pound, or dollar for dollar, Apollo need make no apologies to anyone about compiler speed! B. Small Apollo System Timing Tests Second, consider Apollo binding (linkage-editing; loading) speed. For the seme code as the compilation test (just through overlay 2), it took slightly over two minutes (3:41:24 - 3:39:20 = 2:04) to create an executable image. This is to be compared with 27 seconds for our BPA VAX (using $LINK/NODEBUG on the corresponding "M31." VAX ENTP overlay object files). While less impressive (relatively) than the compilation speed, I again would observe that no apologies are required! The Apollo binder (1inkage-editor) deserves special mention because of a unique feature which we did not have time to verify: the binder output has the same form as the binder input. That is, one can pass code through the binder more than once. Provided the second pass is much speedier than the first pass (because nearly all references would have been previously satisfied), this vould provide an easy way of honoring user-supplied EMTP FORTRAN as part of an EMTP deta case. | Yet I emphasize that we have no experimental confirmation of such a hope. Third, consider the speed of data transfer between the 1 MB floppy disk and the 33.MB Winchester disk. If one did not buy a magnetic tape drive, this vould be important, since floppies would then represent the only way of communicating with the non-Apollo world. Well, the eighth and final Apollo EMTP piece was on a partially-filled diskette which took 49 seconds (8:33:59 - 8: 0) to copy to the Winchester. Since this file of overlays 53, 54, and 55 contained 3249 card images, the transfer rate would seem to be about 66 cards/sec, or 5.3 Keytes/sec. For any EMTP communication which I can imagine, this should be more than adequate. A more serious question about the floppy would seen to be compatibility (or rather possible incompatibility) with other computers (e.g., who knows enough about both VAX-11 and Apollo so that the tvo systems could be made to communicate via floppy disk?). Fourth, consider FORTRAN I/0 speed, as recently discussed by Tom in the last issue of the Newsletter (Vol. 2, No. 2, page 30). As usual, we dumped a megabyte from central menory onto disk, ‘using the following cod REAL*4 —A( 1000) OPEN (UNIT=7, RECL=4000, STATUS='NEW', .... ) DO 1372 Jmt, 250 1372 WRITE (7) A STOP END This required 52 seconds (9:28:12 - 9:27:20), which is quite respectable compared with 21 seconds for BPA's VAX-i1/780, and about 51 seconds for Minnesota Fover's PRIME 750. The only EMTP concern, then, is with that OPEN statement. First, one is indeed obliged to declare any such I/O channel usage, apparently, as vith many otherDit. computers (but unlike the VAX). Second, the maximum record length must be declared (RECL = 4000 implies 4K bytes, which is the size of array A). If not so explicitly declared, the Apollo default is 256, and all I/O will be so truncated! When Jim and I first ran this test, elapsed time vas phenomenally short, and the resulting disk file was observed to be sized at only 250256 = 64K bytes. After we added the “RECL*4000" qualifier, the system confirmed that our newly-created file was indeed a megabyte (“blocks used" = 983; “current length” = 1001052). What the ETP ramifications of this added complication might be, I really have not thought much about, and I would welcome the discussion of it by any informed readers who might be concerned. Since Apollo EMTP FORTRAN uses KBURRO= 1 (to exploit extra virtual storage for node renumbering and the steady-state solution), there is no ENTP table dumping or restoration during a conventional, single, self-contained simulation. Finally, we get to Apollo arithmetic speed, which is perhaps the area of greatest performance difference when compared with a real number-crunching mini like our VAX-11/780. We started with just 10000 double-precision multiply-adds, using the following problem: REALS A, B,C, D A= 1.0 B= 2.0 © = 3.0 DO 1732 Jet, 10000 DeA+BEC 1732 CONTINUE STOP END When first compiled with no optimization ("-NOPT"), and with a cross reference, execution took six seconds (10:10:35 - 10:10:27). Repeating the compilation with no cross reference resulted in faster execution, for some unknown reason (10:16:25 - 10:16:21 = 4 sec). Using this second figure gives a rate of about 2500 REALS multiply-adds per second (compared with about 91000 for our VAK-11/780). To teat single-precision speed, we used “REAL*4" and "J=i, 50000", which then executed in eleven seconds (10:20:30 - 10:20:19). Finally, removing the arithmetic statement “D = A + BYC" produced execution in one second (1 24 - 10:22:23), which is just the time for Apollo to loop 50000 times. Subtracting this second from the previous eleven gives ten for the actual arithnetic, or about 5000 REAI®4 multiply-adds per jecond (compared with about 160000 for our VAX-11/780). Apollo double precision is about half the speed of Apollo single precision for matrix manipulations, then, we conclude. For the record, with the arithmetic removed, our VAX-11/780 will loop about 400000 times in a second; or, including the single-precision arithmetic, this is about 160000 tines/sec. While mentioning Apollo arithmetic, I might observe that word structure seems to be modeled after that of PRIME, which I consider to be ideal for most engineering purposes. Single precision is like that of VAX, allowing a maximum exponent of approximately 10**38. But while VAX, IBM, and most other computers do not allow any added range for double precision (all 32 extra bits contribute to the coefficient), PRIME and Apollo do. the double-precision exponent uses 11 bite (rather than the & of single precision), allowing a maximum exponent of approximately 10**308. ©. Experience with "M31." Apollo EMTP FORTRAN The set up of the "N31." Apollo EMTP began slowly, with Jim at the keyboard, and vith the rest of us offering advice over his shoulder. John provided most of the initial direction, as Jim adapted to the Apollo editor and operating systen. We started by processing the file of EMIP decks first, and then the variable- dimensioning program "VARDIM", as a learning experience.OTT. 10 There were numerous small errors in the translator and Apollo installation- dependent modules which we stumbled through initially. For the record, I list thos which T noted: SE1. My special marker cards which flagged the beginning of each EMTP deck (apollo "INCLUDE" file) were generally two lines too early (somehow my counting vas erroneous in the Apollo E/T). SE2. “VARDIM" compiled without errors, but required the addition of file OPENing and CLOSEing statements, as well as an LUNIT change. My recollection is ‘that I/O unit 7 normally goes to the screen, which was new to me. Also, "VARDIN" utput modules were generally missing IMPLICIT statements (except for the Apollo “TAPSAV" module); and "TAPSAV" had the record following "SINCLUDE" concatinated to this card. SE3. The INCLUDE file “BIKCOM" was illegal due to conflicting REAI"8 and CHARACTER*8 declarations pertaining to vector ABUFF. ‘The Apollo E/T correctly removed ABUFF(20) from /BLANK/, and established a separate COMMON block and CHARACTER declaration; but I had forgotten to destroy the REAL*8 declaration which resulted from the translation of the ALPHANUMERIC declaration. SH4. The installation-dependent Apollo "CIMAGE” module erroneously used explicitly-counted Hollerith (e.g., “GHATTACH") on the right hand side of equal signs. Also, there were some duplicate statement numbers (as Stoney had earlier discovered in New York City). SES. Apollo does not support double-precision COMPLEX, so the COMPLEX*I6 declarations had to be modified to COMPLEX*8. Module "CFUNL1" was one place. Since we never made it to overlays 46 and 47 where Aki's COMPLEX computation is concentrated, only a very few isolated declarations were involved. SE6. The UTPF (VAX) LOGICAL"1 usage for character packing (modules "PACKCH" and "PACKAi") was not accepted by Apollo. like PRIME, Apollo does not provide any one-byte variables, it would seem. So Tom called the local PRIME office, and learned how to pack characters using the new ANSI 77 “I:J" subscript of CHARACTER variables. Such changes were made, though I am not sure that we ever actually verified correct execution (e.g., we never got into batch-mode ENTP plotting, which uses such packing). SE7. The Apollo "DATE44" never had a connection with its SUBROUTINE arguments, resulting ina string of "@"-signs in the EMTP heading. Yet, since all I had was fixed, hard-wired date anyway (I had not seen a list of Apollo library routines at the time the coding was done), the correction was less than fully satisfying. Two problems were discovered with the Apollo FORTRAN compiler. First, it seemed to choke on the numerous WRITE and/or FORMAT statements in the EMTP error overlays. Both “OVERS!” and “OVER53" compilations aborted vith a message such as: "Fatal Error on Line 1196: internal error - instruction displacement