IONM -1 Date: 3 October 1981 Dr. Hermann Dommel, Prof., Univ. of B.C., Vancouver, CANADA Bauardo Bueno Guimaraes, FURNAS, Rio de Janeiro, BRAZIL Jo : Listed addressees Dr. Arun Phadke, AEP Service Corp., New York, N om: W. Scott Meyer ST GERMANY BPA, Boute EDGA Bernd Stein, FGH, Mannheim, WE: P, 0. Box 3621 Dr. Akihiro Ametani, Prof., Doshieha Univ., Kyoto, JAPAN Portland, Oregon 97208 3 i muctatp (sos) est. sen) Ruseell Brierley, Ontario Hydro, Toronto, CANADA Ext. 4404 Dr. Bob Iasseter, prof., Univ. of Wisconsin, Madison Dr, Daniel Van Dommelen, Prof., KUL, Heverlee, BELGIUM BPA, EOGA —--- Dr, Teu-hued Idu (1ibrary copy) BPA, BOGB -~-- Alvin legate / Herbert Konkel TRANSIENTS -ROGRAM MEMORAN DUM Subject : Illustration of New Marti Frequency-Dependent Line Modeling, ——— for Alternative Simulation to 00-kV Portuguese Field Test MARTI ALTERNATIVE TO SEMLYEN MODELING FOR PORTUGUESE PROBLEM A, History of Marti Modeling, and Portuguese EMIP Usage Aone and a half page article by Tsu-huei in the latest EMTP Newsletter (about to be published; volume 2, No. 2) announces the availability of new EMIP frequency dependent modeling for untransposed overhead lines. This is "Marti modeling", named after Professor Jose Marti of the Central University of Venezuela, who has just completed 4 years of graduate study under Hermann in Vancouver. Well, this highly relevant UBC doctoral research has already been applied to the ENTP, and it is in production use here in Portland. It will be available to outsiders with "M31." and later EMTP versions, beginning near the end of October. The present memo represents a detailed illustration of how simple it is to use Marti modeling, with one of the Portuguese 400-KV field tests (see same Newsletter issue) taken as the demonstration vehicle. Without going into any Marti theory or the philosophy of its development (Jose is expected to do this for the following issue of the Newsletter), I might however summarize the dominant difference between the EDP and BPA similations. Since the Portuguese used "SEMLYEN SETUP", modeling of both the propagation function and the characteristic admittance was limited to 2 real exponentials. Considering this low (second) order, one might wonder whether significant accuracy could not be gained by raising the order of the model ———- which is done automatically in the BPA (Marti) similations. Actually, it will be seen that the BPA and EDP similations are very similar, which should satisfy everyone! This provides an independent check on both models as well, since the Semlyen and Marti codes are separated in the ENIP.IONM-e Before considering the illustration, a few words of explanation about the test problem are probably in order. We in Portland first learned of excellent Portuguese field tests and corroborative EMIP simulations on August 18th, when we received a letter dated 28 July 1981 from Mr. J. Allen Lima of Electricidade de Portugal (EDP). Attached was the 23-page paper which is now being published in the Newsletter -—— proof that the knowledgeable and clever EMIP user can make quality simulations using Semlyen recursive convolution modeling with just two real exponentials (i.e., use of "SEMLYEN SETUP"). Well, with our own development of Marti modeling just beginning, the extensive Portuguese experience appeared to provide an ideal starting point for comparative studies. Mr. Lima offered to send us additional information, which we immediately requested (by return letter dated August 19th). Next, a heavy package arrived on the 5th of October -- far more help than we had expected! We gratefully acknowledge a most thorough two-volume (inch and a half thick) Portuguese-language description of the field tests and the EMTP simulations, plus six sets of EMIP data cases on punched cards, plus a beautifully annotated listing of the cards. Tsu-huei has since been carefully processing these established EMIP data cases, replacing the Semlyen modeling with Marti modeling; and it is two of these which are now being passed along to EMTP memo readers. A complete set of all results (EMTP printout on Microfiche; photocopy of CalComp EMTP plots) is going to be sent to EDP for this consideration, and Wwe encourage Mr. Lima to respond with observations which can be passed along to others in a future EMTP Memorandum or Newsletter. Let me also add a few words of explanation regarding the history of EMTP usage at EDP. It may surprise memo readers to learn that among the best EMIP usage is to de found at the bottom of the Iberian Peninsula, away from what popular perception considers to be the "crossroads of computer technology"! Our "Portugal" file shows that we first learned of EDP thanks to a general inquiry of Dr. Edward W. Kimbark by Mr. J. Nascimento Baptista, who is Head of the Power System Analysis Group at EDP. Prof. Francesco Iliceto is mentioned as a source of reference, and I believe this implies contact with Rome (a senior colleague of Professor Alfonso Capasso at the University of Rome). That first EDP letter was dated 9 November 1976, and in a subsequent exchange, it was learned that Univac was the computer system of interest. By January of 1977, EDP and Onatrio Hydro were put in touch, and it is Russ Brierley who deserves credit for handling all Univac complications, as well as helping EDP with any tricky points of Semlyen modeling. Yet it took some time to acquire the actual computer code (our "cc" of Russ's letter of 8 September 1978 to EDP mentions that the Univac tape had just been successfully read). But once operation began, great things have been accomplished. In a letter to us dated 30 November 1978, Mr. Baptista passed the responsibility for EMTP correspondence to Mr. Lima, who now seems to be the EMTP expert in Portugal (and among the best in Europe, if not THE best). With unprecedented rapidity, EDP was creatively using frequency-dependent representations (both the Ametani and Semlyen options were tried) for transmission lines, "STATISTICS", TACS, ete. --- and providing us with FORTRAN corrections in Several cases of misoperation! Clearly, these people knew what they were doing, and it was a pleasure corresponding with them. I believe that Mr. Lima attended’ the Madison short course as well, during its second season, when I was not present (June of 1969), and Mr. Baptista is scheduled to meke an EMIP presentation in Bruxelles later this month (at Daniel's European EMTP Meeting; see Section II-C). In light of this history of intelligent EMIP usage, the most recent excellent results are really not surprising. We at BPA both salute the obvious EMTP competence of the Portuguese, and thank them for being so cooperative in providing us with a perfect ‘test case for our ongoing Marti frequency-dependence work. Just as we at BPA leave the mathematical subtleties of Marti modeling to Jose, so we leave the expert electrical interpretation of our results to the Portuguese. The simulation to be shown below was air mailed to EDP yesterday (October 10th), and ‘the remainder of the simulations should follow within a week or so. , There is only one remaining item of background information which I want to pass along. In his letter of July 28th, Mr. Lima attributes his success at correlating EMIP results and field tests to the following:TONM-3 "I can tell you the secret of such a good agreement: it is mainly the capability of running and watching the transients ona CRT screen. This procedure permits doing some minor adjustments on the equivalents connected at the boundary of the detailed network used, and running again. This emphasizes the benefits we would get if the program had full interactive capability." What can I say, other than "Amen!". Of all the people in the world to whom I could have showed our VAX EMTP simulator, I have a feeling that Mr. Lima might have been among the most appreciative! Along with my August 19th letter of response, a copy of the similator memo (Vol. XI, 17 July 1981, pagination IEEO) was provided. B, Illustrative Usage of "MARTI SETUP" for Portuguese 400-kV Line On to the illustrative example, which commences with the use of "MARTI SETUP" for generation of the frequency-dependent EMIP branch cards. Consider first the EMIP data cards which are applicable to the 400-kV overhead line between "Rio Maior” and "Cedillo" : BEGIN NEW DATA CASE MARTI SETUP BRANCH CEDILORIO MOCEDIL8RIO MBCEDILURIO M4 LINE CONSTANTS 10.231 0.0840 4 1.25 -39.4 70.97 32.25 15.8 0.0 2 20.231 0.0840 4 1.25 (0.0 32.25 15.8 0.0 2 30.231 0.0840 4 1.25 39.4 32.25 15.8 0.0 2 0.5 0.58 4 +575 ~25.76 76.12 00.5 0.58 4 =575 25.76 76.12 BLANK CARD ENDING CONDUCTOR CARDS 250.0 5000.0 1 3 250.0 50.0 1 3 250.0 1.0 1 720 3 BLANK CARD ENDING FREQUENCY CARDS BLANK CARD ENDING "LINE CONSTANTS" DATA CASES DEFAULT BLANK CARD ENDING "MARTI SETUP" DATA CASES BEGIN NEW DATA CASE BLANK Unlike the original EDP data which used the "METRIC" option of "LINE CONSTANTS", ‘Tsu-huei is here using the default "ENGLISH" units. Within a week or two, the "METRIC" option should be usable; but at the moment, the program linkage between "LINE CONSTANTS" and "MARTI SETUP" only works for "ENGLISH" units. It is seen that the line is 85.75 miles long, corresponding to the original EDP length of 138.7 Kilometers. The line documented above will be energized in a subsequent simulation, so it is of primary interest. Note the simplicity of this "MARTI SETUP" data case, which consists of the following elements: 1. "BEGIN NEW DATA CASE" ——= the civilized way to start! 2. "MARTI SETUP" card to request Jose's data generator, followed by a "BRANCH" card to supply 6-character node names for the EMTP branch cards which are to be punched on LUNIT7. This structure is the sane as with "SEMLYEN SETUP" , 3. A complete "LINE CONSTANTS" data case corresponding to the line of interest. Structure of the frequency cards has been kept identical to "SEMLYEN SETUP" for simplicity of user retraining. There is an extra punch of the number of phases in column number 70, however (as with K. C. Lee modeling). The first card gives the diagonalization frequency (5000 Hz), the second gives the1ONM-4 phasor steady-state frequency (actually not used by Jose), while ‘the third provides for logarithmic looping over all frequencies (8 decades, 20 points/decade, beginning at 1.0 Hz). 4, "DEFAULT" ~~ all the user understanding that is needed! Jose internally sets all error tolerances and other control parameters. "Not to worry!" 5. Blank cards to shut off "MARTI SETUP" and the EMIP itself. So mich for the input data, which is simple enough. If this is rum using our latest prototype "M30.+" VAX EMTP, the following line printer output is produced: ao BLAME CARD BOING MARTE SETUP" {ELAR CARD BODG "ANTE SETUPY DATA CASES Ek Seip aver the printout of DAP table slzes (actual and Limiting) >> ‘TIMING FIGURES (DECDIAL) CHARACTERIZING CASE SOLITION SPEED, ——————_ ep < Seip the start of the next data case (blank card to stut off BP). >> The LUNIT7 punch file will contain the EMIP branch cards which represent Marti frequency dependence. They appear as follows: © PUNCHED CARD OUTPUT OF "MARTI SETUP" WHICH BEGAN AT 15.43.13 10/13/81 0.0 C 10.231 0.0840 4 1.25 -39.4 70.97 32,25 15.8 << Ete. for rest of "LINE CONSTANTS" data (on comment cards) > > = ICEDILORTO MO 23 14 0.41338447351401747909E+03 0.975279727733334937E+03 0. 73649696275807 1888E+03 0.531464948940473062E+04 0..898792823890878731E+0H 0. 152082064328666181E+04 0. 925236767827463177E+04 0,301018915498155860E+06 0. 128151320029142013E+07 0. 189659037162658601E+07 0. 666738338256433292E+07 0. 158358915527896674E+08 0. 1629616247 16U52260E+08 0,389157981187294777E+08 0, 109327861675 1062H0E+09 0. 133241059354305043E+02 0. 177778457864839878E+02 0.705048459227648365E+02 0. 942383652247002068E+02 0.117466662U57994962E+03 0.306079919708891666E+03 0.916510557143750157E+04 0.783203073877983588E+05 0. 130315542599139650E+06 0.153824036666563792E+06 0. 1134833272026U9400E+07 0.279443582398536877E+07 0,668443411356654624E+07 0. 148229997758599299E+08 sa 0.5011215705940N52030E-03 0.227735999789212068E+01 0.81933962330699401HE+02 0.24887 1544365811570E+03 0.4522175585U301875UE+03 0.853761987280847620E+03 0, 122006632626207960E+04 0.2225 12222145 1N2318E+05 0.671674847687895250E+06 -0.823879475393039800E+06LYININTS 0. 135077821553298061E+06 0. 798354480 1UNBO9429E+08 0.998412216540935198E+02 0.205257885751743481E+0% 0.4980808561235 18254E +04 - 0.762605357901953960E+08 0. 101695058642803017E+05 0. 134060196310142646E+05 0.231952555633408128E+05 0.515674261633336746E+05 0.59065123660209N978E+05 0.9915876727202H0116E+05 0.2416U6143090132977E+06 ~2CEDILERIO MB 23 3 0. 3243757700721376409 1E+03 0, 33051807529539950E+04 0.317068267100677666E+03 0.2608121229587 16927E+08 0. 116979809896304678E+02 0. 124324468338854162E+03 0. 40894402025554084 1E+07 8 0, 46423541692017425674E-03 << Ete. for rest of second mode Al, then 3rd branch and mode. > > 0.58948639 ~0.70710678 -0.41264747 0.55220595 0.00000000 0.81203753 0,58948639 0.70710678 0.126747 The general ordering of information here is quite similar to what is used by Semlyen modeling. Note that "LINE CONSTANTS" data is documented on coment cards, so that details of the geometry will not be lost. The transformation matrix (3 by 3 in this case) follows at the very end. In between, there are the familiar branch cards, followed by Ze and A1 exponentials belonging to the associated mode (see subsequent, EMIP simulation for further details). One special feature is the leading comment. card which shows the date and time of day at which the EMTP run began. As with EMTP plots, this will allow the user to unambiguously associate LUNIT7 punched cards with the line printer output of the derivation at any later time. We expect to put more special information on such comment cards (e.g., the modal travel times, the maximum errors, ete.) before work is done. C. Illustration of Marti Simulation Using Portuguese Line Energization Next consider a sample Marti simulation itself, For this purpose, we choose the simplest of the Portuguese EMTP studies, that corresponding to Figures 8-11 of the Newsletter article (Figures 62-65 of the Portuguese language report). Deleting the frequency-dependent parameter values (but retaining the branch cards per se) so as to more concisely show the network structure, one arrives at the following EMTP documentation for the problem as supplied by EDP: BEGIN NEW DATA CASE 1.56-5 0.080 50.0 50.0 1.-9 1.-9 10 2 1 1 <1 7: 100 100 51BL1 GIBL 1.0 20.00 52BL2 G2BL ‘5 26.00 53BL3G3BL 51aM1 G1AM 1.0 20.00 Seam2 G2an 0.5 26.00 53aM3 G3AM BLI 150. 8.345 BL2 150. 8.345 BL3 150. 8.345 aM 150. 8.355 AM2- 150. 8.345 a3 150. 8.355 mM St 1.57 RM S2 1:57 M53 157 “1CEDILORIO Mo 3 ' =2CEDILBRIO MB 3 Marti 3CEDILURIO Mi 3 “IBL1 GERIt 3 branches “2BL2 GER22 3ITONM-6 -3BL3 GER33 23 : Tawi GERT 23 peti -2aM2 GER22 23 “aan _GER33 23 branches ‘TRANSFORMER 4.18 ST4.OTR1 RM 3.145 0.772 0. M43 8 0.573 11.04 0.66643 9999 1GER11 +200 1.0 2RM SI 62 70. 1.617 RM T2 0500 2.52 .1773 TRANSFORMER TR1 RM ‘TR2 RM 1GER22 2RM S2 3m TERM 73 ‘TRANSFORMER TR1 RM TR3 RM 1GER33 RM S3 3m 73 BLANK CARD ENDING BRANCH CARDS RM =S1RIO MO 0 ee RM S2RIO M8 20026 «1. RM S3RIO M4 .00293 «1. BLANK CARD ENDING SWITCH CARDS: 14G1BL 194.1243, 50.0 187.60 -1. 14G3BL_ 194.1243 50.0 67.60 1 14G2BL 194.1243, 50.0 52.40 1. 14G1AM 194.1243 50.0 183.60 1. 14G3AM 194.1243 50.0 63.60 -1. 14G2AM 194.1243 50.0 56.40 1 BLANK CARD ENDING SOURCE CARDS RIO MORIO MBRIO Mi BLANK CARD ENDING NODE. VOLTAGE OUTPUTS BLANK CARD ENDING PLOT CARDS BEGIN NEW DATA CASE BLANK All of this is very conventional, so will not be explained further. It is only the Marti, frequency-dependence which requires illustration: The first mode of that Tanke frequency-dependent Line from "Cedille" to "Rio Maior" is interpreted by the _ ENTP as follows: MARTI. TRANSMISSION MODE 1 PARAMETERS BEGIN. 4-1CEDILORIO MO 1 ZC BEGINS. ORDER, ZC( INFINITY) 11 0,469E403 1 0. 46907632848801 RESIDUALS 1- 3. 0.282E+0U 0.816E+04 0.415E+04 7 0.281919133289483773E+04 0. RESIDUALS U- 6. 0,466E+04 O.471E405 0.583E+06 1 0465894056 195483233E+04 0. RESIDUALS 7-9. 0.208407 0. 127E+0B 0. 139E+08 | 0, 199807050334149116E+07 0. RESIDUALS 10-11. 0.559E+08 0. 158E+09 1 0.558564100408186363E+08 0. POLES 1-3. O-2155E+02 O.S7H7E+02 0.7835E+02 1 0.215460025882208579E+02 0. POLES 4-6, O-16H2E+03 0.2701E+04 0.3385E+05 1 0. 164243118300700019E+03 0. POLES 7-9, O-1218E+06 0.7923E+06 0.2117E+0T 1 0.121796990875796455E+06 0. POLES 10-11. 0.B482E+07 0.2742E4+08 4 0.8481538113692H7967E+07__O- A1 BEGINS. ORDER, TAU(SEC) 14 0.48225E-03 1 W 0.482247 16152588 RESIDUALS 1- 3." 0.518400 0.4O3E+01 0.908E+02 1 0.551999325002U97126E+00 0. RESIDUALS — 6. 0.208E+03 0.3UNE+03 0.705E+03 1 0.207984550445878739E+03 0. RESIDUALS 7-9. 0.116E+0% 0. 166E+0% 0.232E+08 | (0.1160615912912721MBE+04 0. RESIDUALS 10-12. 0.166805 0. 1H0E+06 -0.641E+06 1 0.166441713559736913E+05 0. RESIDUALS 13-14. 0.495E+06 -0.175E+05 4 0.1195131385713195436E+06 ~0. POLES 1-3. O-48QME+02 0.3504E+03 0.3339E+04 1 0.48938922647502947 1E+02 0. POLES = 6, 0.6511E+0H 0.9H11E+08 0. 1226E+05 1 0,651071656186U36451E+04 0.POLES 7-9. POLES 10-12, POLES 13-14, LONM- / 0. 1654E+05 0.2059E+05 0.2475E+05 1 0.165435531226168746E+05 0. 0.3188E+05 0.689HE+05 0. 123HE+06 1 0.318751600027932018E+05 0. 0.1518E+06 0.3657E+06 1 0.151820745208072371E+06 0. MARTI TRANSMISSION MODE 2 PARAMETERS BEGIN. 1-2CEDIL8RIO M8 The steady-state printout is not very interesting either, so we shall skip right to the time-step loop, which provides the following printout and plots. Readers are encouraged to compare the Marti graphs shown below with those of the Newsletter: STEP TIME RIO MO RIO MB. RIO MA RIO MO erry RM 1 SWITCH "RIO MO’ TO 'RM 1? CLOSED AFTER 0.00000E+00 SEC. 0 0.000000 0.000000E+00 0.000000E+00 0.000000E+00 0.000000E+00 10 0.000156~-0.550630E+05~0. 112656E+05-0.682264E+04 0. 14570UE+03 20 000312-0.888172E+05-0. 188043E+05. 106240. 13Y541E+06~0..292870E+05- 1560-0 . 38349 1E+06-0 .556493E+05- 16917E+05 0.232701E+03 85880E+05 0.34909 1E+03 24214 7E405 0.397 101E+03 SWITCH 'RIO M8" TO 'RM S2* CLOSED AFTER 0.26052E-02 SEC. SWITCH "RIO M4t TO "RM $3 CLOSED AFTER 0.29328E-02 SEC. 0,003120-0. 378489E+06 0.901069E+05-0.515008E+04-0.376322E+03 6240 0.11894KE+06 0.271669E+06-0.455662E+06 0. 159597E+03 19360 0.412415E+06-0. 343486E+04-0. 128590E+06-0.221327E+03 1.012480 0. 144739E+06-0. 11125855406 0. 164524E+05 0.699578E+02 800 1000 0.015600 0.206330E+05-0.216947E+06 0.273749E+06 0.288801E+03 1200 0.018720-0.288915E+06 0. 19475YE+05 0. 355604E+06~0.451213E+02 1400 0.021840-0.328116E+06 0.257863E+06- +7 182U5E+05~0 . 294042401 1600 0.024960 0.571212E+04 0.316188E+06-0.229754E+06-0. 15174 1E+03 1800 0.028080 0.239668E+06 0.624103E+05~-0.310860E+06~0. 1HU985E+03 2000 0.031200 0.31628 1E+06-0.270280E+06-0.947155E+05 0.678749E+02 2200 0.034320 0. 102888E+06-0.302135E+06 0.255937E+06 0. 135569E+03 2400 0.0374H0~0.214219E+06~0.1219B4E+06 0.31252YE+06 0. 125626E+03 2564 0.039998-0.329605E+06 0. 148585E+06 0.195610E+06 0.291910E+02 MAXIMA AND MINIMA WHICH OCCURRED DURING THE SIMULATION FOLLOW. VARIABLE TIMES OF TIMES OF MINI (0.N64329E+06 0.55U285E+06 0.355643E+06 0.480771E+03 (0.992160E-02 0.496080E-02 0.187356E-01 0. 107640E-02 VARIABLE MINIMA : ~0. UB9BMME-+06-0.419602E+06~0 .462901E+06-0. 50U526E+03 MA: 0.213720E-02 0.127296E-01 0.647400E-02 0.385320E-02 NAMES :RIO Me 10/13/81 15.51.15 -| TYPE 4 YRIN, YMAX, DY/IN = -@.120@E+07 @.1200E+07 0.3000E+06 THIN, TMAX, DT/IN = @.0000@E+00 @.48000E-01 0.40000F-~0210713781 15 RIO M4 $1.1 9.50 NAMES 3RM Si RIO Me YMIN, YMAX, DY/ZIN = -@.10@0E+04 0.1000E+04 9.2500E+03 Finally, I might just document the Sumary statistics for the solution, as run here Portland on our new (second) VAX=11/780 ‘TIMING FIGURES (DECTHAL.) CP SEC I/O SEC SUM SEC TIME IN TIME-STEP err 164.580 0,000 164.580IONM-4 SOME SMALL ITEMS AFFECTING EMTP DEVELOPMENT Confusion Concerning Random Number Initialization in overlay 12 Over the years, random numbers have proven to be a pain for EMIP developers. In theory, only trivial details are involved; in practice, it seems like endless trial and error has been needed for fine tuning the universal code. The fundamental problem is associated with initialization (when to do it, what seed to use, how to save the seed, etc.). Well, as Vladimir, Russ and Ray (who have recently tried an "30." Univac EMTP version) correctly observed, we in Portland changed the rules on them since "™28.", creating problems for them. Toronto reports that now all their reference angles are equal, rather than being randomly distributed! Well, it is believed that their problem can be readily cured by creative linkage-editing (forcing "RANDNM" and "SANDNM" into the "MAINOO" overlay so as to be permanently in memory), though the "M31." UTPF will be restored to the "M28." structure anyway. Some documentation of the reason behind this final adjustment would seem to be warranted, beginning with a Listing of the 30." code which caused trouble: M13.1459 409 IF (NENERG .LT. 0) GO TO 188 M29. 170i IF (KNT .GT. 1) GO TO 1409 M4. 1421 CALL TIMEW4(ATIM(1)) 10660 CALL RUNTYM (D1,D2) 10661 SEED = SEEDY(ATIM(1)) + 1000.*(D1+D2) 10662 SEED = 2.0*SEED Mog. 12 IF ( JSEEDR .GE, NENERG ) SEED = SEEDR 22.3600 D8 = RANDNM(SEED) M10. 215 IF ( IPRSUP_ .GE. 1) M17. 614 1 WRITE (LUNIT6, 646) KNT, KSWICH, JSEEDR, NENERG, ITEST, IDIST, M22.3601 2 SEED, D8 M10. 218 646 FORMAT ( /, 48H IN =OVER12= JUST AFTER 1ST USE OF =RANDNM= . , M10. 219° 1/, 1X, UH —-KNT _KSWICH JSEEDR NENERG ITEST IDIST, M22.3602 2 16K, HHSEED, 18X, 2HD8 ,/, 1X, 618, 2620.10 ) M29.1705 1409 SECFRQ = (1.0/STATFR)/360. Here the second record (note "M29." ident) causes this initialization logic to be , Skipped for energizations 2, 3, etc., so that the random number generator is being initialized only once per EMTP data case. Well, the Univac linkage-editor was smart gnough to know that "RANDNM" is only called by "OVER12", so it made the random number generator a part of the overlay (in spite of the UIPF appearance in a higher overlay). So, the history term was apparently lost for Univac (each energization begins with overlay 12 being restored to memory from disk). Segmented EMIP users will have exactly the same problem, if each overlay is a separate program which is re-entered. : ‘Thus we are prepared to delete "M29.1704" (it will be missing in the 31." UTPF). But why was "M29.1704" record added in the first place? Neither Tsu-huei nor I remember precisely, though both of us think that it was in response to trouble in some other program version. We do recall PRIME complaints (Jack Sawada of B.C. Hydro; Tom Varilek of Minnesota Power), and suspect that somehow we were hoping to in this way solve the PRIME EMTP problem. So, let everyone be warned that the 29." reform is being taken back. If PRIME requires the avoidance of more than one initialization (it could be, for we know nothing about the random number generator which Tom uses), then extra logic must simply be added to "RANDNM". The same KNT which was used in "OVER12" can also be used within "RANDNM" if UTPF deck BLKCOM is added (use "INSERT DECK BLKCOM"). B. More "Burroing" (refining the Burroughs Editor/Translator) Most (211?) translators generate EMIP FORTRAN which has blank UTPF idents for those records which were actually generated internally (as opposed to being passedIONM-10 ‘through unprocessed). Well, as Stoney observed, this is inconvenient if one wants to later recover any manual program modifications. When Stoney wants to know which records have been added or manually modified in the Burroughs EMTP, he wants to be able to search for blank UTPF idents ---- exactly the same as our VAX minor-update software here in Portland. Of course we VAX-11 users do not have Stoney's problem because we program in the UTPF language (where every record has a UIPF ident), not FORTRAN. Anyway, Stoney gets credit for making the most valuable suggestion that idents be placed on every record which the Burroughs E/T outputs. Both the date and the Vintage number are used as a replacement for formerly-blank ident fields, such as “OCTBIM30" . ‘The first of the three major files produced by the Burroughs Editor/Translator (E/T) program is the variable-dimensioning program "VARDIM" (see page MMED-8 of the preceding memo dated 20 September 1981). I chose to only add our new ident to those records which now have cols. 64-72 blank): DIMENSION CBLOCK(250), NCBARR(250), CBLSER(250), JBLTYP(250) 20000100 DIMENSION LSTNEW(99), LSTDEF(49), TYPE(#,3), KEXTRA(29) 20000200 DIMENSION ABUFF(14), CHAR(6), MULVAR(4), BUS1(1) #0CTB1M3120000300 DATA CBLOCK( 1) / 6HK 4, NCBARR( 1) / 3/ — 20000400 As for the deck file “"COMDECK", it now appears as follows (a modification to page "MMED-7"), There is the added embellishment of having the compilation listing suppressed with $-cards, note (more about this later): $ RESET LIST % BEGIN EMTP DECK "BLKCOM". 00100000 C —-FLAG-1. BEGIN CLASS-1 /BLANK/ VARIABLES 40CT81M3100100100 C THE FIRST VARIABLES OF /BLANK/ ARE ALPHANUMERIC 40CT81M3100100200 REAL DATE1, TCLOCK, VSTACS, ABUFF #0CT81M3100100300 REAL BUS1, BUS2, BUS3, BUSH, BUSS 40CT81N3100100400 COMMON DATE1(2), TCLOCK(2), VSTACS(100), ABUFF(20) 00100500 << Ete. for interior of "BLKCOM" > > COMMON CAT, NUMNVO, IFLAT, NENERG, ISW, ITEST #0CT81M3100101300 $ POP LIST 4 END EMTP DECK 00199990 $ RESET LIST % BEGIN EMTP DECK : 00200000 EQUIVALENCE ( X(1), INTEGX(1) ) #0CT81M3100200100 << Ete. for remainder of file >> ‘The third file is the Burroughs EMIP itself, which now begins as follows (see the bottom of page MMED-7 for comparison) : IMPLICIT REAL*Y (A-H, O-Z) , #0CT81M3110000100 dl INTEGER* (I-N) 40CT81M31 10000200 $ INCLUDE 'COMDECK' 00100000 - 00199999 _% (DECK "BLKCOM") Z0CT81M3110000300 Cc IDENT OF NEXT CARD : 4415. 20310000H00 C) Hi SSS SE EEE SEH A EEE ASSES O ISH AEAA NAHE 0000500 The miscellaneous data card of the Burroughs E/T now contains the following information. This is the first data card read from unit 5 by the E/T (it precedes the Burroughs installation-dependent EMTP modules): IPRINT ---- The number of records of Burroughs EMTP FORTRAN to (1-8) be listed after the translation is complete. This must be positive to accomplish the UTPF-ident moving. IPRSUP ———- Control of diagnostic printout for the translation. (9-16) Normal production runs will have this zero. Number of bytes for the REAL"? specification of ‘the IMPLICIT statement which begins each EMTP FORTRAN module. We use "4" for single-precision.TONM-11 NBYTEI ---- Like NBYTER, only for INTEGER variables. Again, (25-32) a value of "4" gives 48-bit integers. KDISC ---- Flag to discard (or not discard) the EMTP variable- (33-40) dimensioning modules of the UTPF as they are encountered. We now run with unity, meaning such modules are discarded (middle page MMED-9). LIMCOM ——-- Set to "999" without asking why! This is just any big 18) number larger than the number of COMMON blocks in the EMIP. IUSERL ---- Flag to possibly suppress the input listing of Burroughs (49-56) installation-dependent EMTP modules. We normally use zero (no Listing); "1" would list all such records. LISTOF ---- Flag for the possible suppression of INCLUDE files (57-64) in compilation listings. Blank or zero will not suppress anything, while unity will (see above illustration of § RESET LIST and $ POP LIST), KOMSUP Flag for the possible suppression of UTPF ident (65-72) moving (bottom of page MMED-7). Blank or zero leaves the operation as described on page MMED-7, "qm will omit the extra identifying card in case the card of interest is a comment card, and "2" will suppress the generation of all such extra cards. MWHAT ———- 3-character vintage identification (e.g., "M30") which (78-80) becomes the final three characters of the 8-character manufactured ident (e.g., "OCT81N30") mentioned above. Another minor change to Burroughs E/T logic provides for recognition of the "COMPLEX FUNCTION" construct. Recall that in the previous memo I ignored this (see page MMED-10, toward the bottom). Well, Stoney was no longer silent on this point; he thought that it would be best to use the more complicated construction, In terms of installation-dependent modules for Burroughs, two are affected. As evidence that ‘they really have been changed, I copy into this text the two key declarative lines: ‘COMPLEX FUNCTION CFUNL1(X) COMPLEX FUNCTION CMPLXZ(X,Y) C. Agenda for First All-European EMTP Users Group Meeting in Bruxelles, Belgium At the end of the last meno (page MMED-2, Point H4), I appended a four-line mention of the upcoming European EMTP Users Group Meeting.’ Now that Deniel (Prof. Daniel Van Dommelen, the Chairman of the European EMIP User's Group) has finalized the agenda, I pass a retyped version along to memo readers: EMTP USERS GROUP MEETING ‘At LABORELEC (Belgium) 23 OCTOBRE 1981 (Convener: D. VAN DOMMELEN) AGENDA TIME SLOT ACTIVITY OR SUBJECT 9.00-9.45, Introduction : Goal and Means9.45=10.00 10,00-10.45 10.45 =11.15, 11.15=12,00 12,00-12.15 12.15=13.00 13.00-14.15 4. 15=15.00 15.00-15.15 15.15-16.00 16.00-16.15 16.15=17.00 17-00-17.30 17.30-19.00 19.00 IONM-1e Documentation : Memoranda X, and first memo of XI Current Versions (SEL, IBM) Discussion and break Belgian Experience: (coordinator: D. Van Donmelen) * Shock waves upon a transformer: simulation and tests * Shaft torques and Short-Circuit currents simulated and compared with field tests at RODENHUIZE * Effect of certain implemented corrections to the IBM M21 Discussion and break with coffee Experience from the NETHERLANDS (coordinator: M. J. G. Janssen) Discussion and break Experience from FRANCE (coordinator: J. Roguin) Lunch Experience from GERMANY (coordinator: B, Stein) Discussion and break Experience from PORTUGAL (coordinator: J. Do Nascimento Baptista) Discussion and break Report about a meeting in Portland about future development and availability of EMTP. News about the Madison course. Discussion and break with coffee Hands-on demonstration of the problems and solutions for the case Doel (Oscillations and divergence) Closing (guests will be dropped off at their hotels by arrangement with the Belgian participants.) For further information or suggestions, please contact: Prof. D. Van Donmelen K. U. L. ~ Departm. E Kard. Mercierlaan 94 3030 Heverlee-Leuven BELGIUM Telephone: International 32-16-220931 National 016-220931 Telex: elekul b 25941 There also was a cover letter to potentially-interested parties, which is perhaps of less interest. I pass along only the final paragraph, as well as Daniel's quaint little maps (how would you like to drive a taxi in downtown Bruxelles?!): "For our colleagues who will need overnight lodgings, an hotel in the heart of Bruxxels has been suggested by LABORELEC: HOTEL D'ARENBERG, rue d’assaut 15, 1000 BRUSSELS, tel.: (02)5110770. No special arrangements have been made, so feel free to make your own choice. But in any case, a pick-up will be arranged byIONM-13 LABORELEC at 8.00 a.m. from this hotel to bring you to LABORELEC. Please find enclosed a sketch of the hotel's situation near Brussels’ CENTRAL STATION, as well as a sketch of where LABORELEC is.” cance, B00 mm LecaTion oF “Rue D’AssnuT” wien xeseren 70 "ceuraae starion” anvastis, Perit Awa, 19 km BSPINETTE CEMTRALE LOCATION OF ‘“Lavonetee” warenLUINI IT IT It is my hope that Daniel's first all-European EMTP meeting (only his second meeting overall; the first one was restricted to Belgians) will be the beginning of closer cooperation between Europeans and North Americans. Assuming that this might thus be an historic occasion, I could not resist the temptation to pass along some official words of welcome and approval (contained in a letter dated October 4th): “We in Portland are most pleased by the apparent purpose, scope, and content of this first all-European EMTP Users Group Meeting which is now beginning. ‘The concept of regular meetings by serious EMIP users, for the exchange of information and the discussion of problems, is believed to be very important. Indeed, it is almost necessary, considering the continuing evolutionary growth in size and sophistication of the program. We wish all of you a successful and satisfying dey, one which will later be referred to by EMTP historians as "the beginning of cooperative European EMIP activity.” We also want to publicly commend your Chairman and organizer (Prof. Daniel Van Donmelen), who is held in high esteem by both us and Prof. Dommel. We at BPA do accept the responsibility for encouraging Daniel to expand from limited Belgian attendance to an all-European audience, and we hope that you will have the good fortune of retaining his obvious talent at the helm of this bigger EMIP users’ ship in the years ahead. As the strength and scope of your possible European EMTP cooperation might increase, we at the center of program development would do our best to proportionately strengthen this tie across the North Atlantic. Closer EMTP cooperation should be mutually beneficial to both North Americans and Europeans alike, though perhaps it would be premature to say much more at this time. For now, we terminate with thanks to all of you for answering Daniel's call to this enlarged session. We hope that you have a productive meeting --- the first of many!" D. ‘Type-96 EMTP Hysteresis Modeling : North Dakota State University While receiving a last-minute Newsletter contribution from Bob Newell (Basin Electric; Bismarck, North Dakota) yesterday (October 9th), I learned indirectly of some EMTP research in Fargo. It seems that Basin Electric allows the University there (NDSU) to use the EMTP on its PRIME 750 via a dial-up port, and that Masters Degree research has been going on using EMTP hysteresis modeling. Bob says that he has encouraged the principals involved to write something for the Newsletter or an EMTP Memorandum, and I heartily concur. I also approve of the way Basin and NDSU cooperate on EMTP-related matters. Because of program size and complexity, the EMTP is difficult for most U.S. universities to deal with. For some time I have called on universities to join forces with cooperating power companies, with the latter maintaining the program on their computer system and providing free access to the academicians (Vol. VIII, 19 November 1978, middle of page ABBO-13). I see this as a growing need, and NDSU is lucky to have Basin Electric and Bob nearby. E, * $50000 Computer System for Support of the EMTP ? The closer we look, the more exciting that intelligence from Tom Varilek (of Minnesota Power) appears! Glossy photos and price schedules would seem to confirm ‘that as little as $50000 would purchase a powerful, flexible desk-top computer which could handle all EMIP studies of a large power company. We are now gathering more information, and would EMTP benchmark at the first chance! In terms of historical importance, this development could rival or surpass the EMTP move to minicomputers! Anyone ready to commit EMTP dollars is strongly advised to take a very close look at how microcomputers are growing up to challenge low-end minis for the support of large scientific programs. More later, as our information firms. 14 Odeon 1981 W, Mee WeyerDate: 18 October 1981 Dr. Hermann Donmel, Prof., Univ. of B.C., Vancouver, CANADA ‘Bduardo Bueno Guimaraes, FURNAS, Rio de Janeiro, BRAZIT. To : Listed addressees Dr. Arun Phadke, AEP Service Corp., New York, N.Y. .2om: W. Scott Meyer Mannhe IST GERMANY MSN’ BPA, Route BOGA Bernd Stein, PGH, eim, WE: 2. 0. Box 3621 Dr. Akihiro ametani, Prof., Doshisha Univ., Kyoto, JAPAN Portland, Oregon 97208 Russell Brier Ontari a: 1% Phone: (503) 234-3361 ee erheys a eee Ext. 4404 ‘Dr. Bob lasseter, prof., Univ. of Wisconsin, Madison ‘Dr, Daniel Van Dommelen, Prof., KUL, Heverlee, BELGIUM BPA, BOGA —--- Dr. Teu-huei Liu (library copy) BPA, EOGB ---~ Alvin legate / Herbert Konkel TRANSIENTS f ROGRAM MEMORANDUM Subject : Several small items affecting EMIP usage and development ® EMTP CONTACT WITH OTHERS A. Information from Rio de Janeiro about FURNAS ETP Coordination ——r—E—E—E—E—E—E— It was in the middle of the last paragraph on page MSPR-5 of a recent EMTP memo that I mentioned Brazil in an off-hand manner ("Second was the Brazilian EMIP coordination of FURNAS, about which I have only very limited and indirect information."), Well, I now have proof that EMTP Memoranda are carefully read by Mr. Guimaraes (our principal EMIP contact for Brazil), since he inmediately responded with the following in a letter to me dated 5 October 1981: 3, The following organizations are EMIP users and receive information from us: . Electrical utilities in Brazil ELETROPAULO, CEMIG, ELETROSUL, ELETROBRAS, LIGHT, CESP, CHESF, COPEL, FURNAS, CEEE, CELESC, ELETRONORTE. + Consultant Companies HIDROSERVICE, MONASA, THEMAG, PTEL, PROMON. + University and Research Centers ItajubA University, Federal University of Rio de Janeiro, Catholic University of Rio de Janeiro, CEPEL (Research Center). Electrical Utilities in South America S S J A -2 AGUA ¥ ENERGIA ELECTRICA - Argentina We are in the process of sending our IBM version to Electrical utilities in Chile, Colombia and Paraguai. A preceding paragraph politely apologized for not keeping us informed of such activities, though I am personally as guilty as anyone, since I can not remember ever having explicitely asked! This might be a good opportunity to make a formal request of all Memo readers for such information. In the past, I have suggested that a column which kept track of names and activities might be appropriate for the ENTP Newsletter (see Vol. X, 15 April 1980, top of page TPIM~17). Well, I have not heard that Hermann's Suggestion Box has been deluged with support, or that he personally liked the idea. Maybe I should not attempt to have Hermann do my work, anyway! The question of style or literary level is not an issue with Memoranda as it is with the Newsletter, since I as Editor in Chief profess to having none! I continue to believe that the subject is important, and recently devoted three pages to Daniel's European EMIP activities (see pages IONM-11 through 14 of the preceding Memo) in this spirit. I encourage others to write me what they are doing that might be of interest to others, so that it can be passed along as Mr. Guimaraes's information above was. B, Bob Newell's Help in Finding Uninitialized Variables of "TEKPLT" Although I have yet to see our copy, issue No. 2 (Vol. 2) of the EMIP Newsletter should by now be published. In'it there should be a short piece by Bob Newell of Basin Electric (Bismarck, North Dakota), who has had trouble with lack of variable initialization within SUBROUTINE TEKPLT of the Prime version of interactive CRT plotting. The basic code was written here in Portland for our VAX (see Vol. IX, 11 May 1979, pagination PIEP) which uses the unfortunate practice of zeroing ali variables which are not otherwise defined by the user. Actually, this is fortunate and very civilized —-—- until one tries to carry such code to other less-cooperative computer systems. Bob indicates in his article that there have been such intermitten problems with the PRIME version of interactive plotting (EMIPLT), as system software changes (and the nature of garbage changes). If PRIME EMIP users have this problem, Bob's article points to a guaranteed cure: the forced initialization of all variables. Missing, however, was an explicit list which was deemed to be too long and error prone for dictation by telephone (Bob's was a last-minute contribution vis telephone, with intermediate stop in Portland): _BUS1, D1, D2, D3, D4, D5, D6, D7, D8, FSCALE, I, I¥TMP, ICCHR, IDX, IDY, IREFP, IX, IY, J, K, LXAX, LYAX,'M, N1, N2, N3, N35, NY, NU2, N5, N6, N7, NX, NXVERT, NY, SX, ‘SY, VSPAN, 'XMIN.’ This’ list I’have retyped from’hard copy which was recently received from Bob. Well, as I told Bob, this is a loose end which I am willing to fix, now that he had done the difficult part of pointing out a list of potentially-offending variables (I would not know how to get that information from our VAX software, though presumably it is possible). So, to find which of the aforementioned variables is actually uninitialized, I prepared my own interactive garbage generator at the top of "TEKPLI™ : COMMON BUS1,D1 ,D2,D3,D4,D5,D6,D7, D8, FSCALE, SX, SY, VSPAN, XMIN COMMON I, IWIMP, ICCHR, IDX, IDY, IREFP, 1X, TY, J,K,LXAX,LYAX,M,N1 COMMON N2,N3,N35,N4,NA2,N5,NON7, NX, NAVERT MY DIMENSION "KLOBER(1), FLOBER(1) EQUIVALENCE (I, KLOBER(1)), (BUS1, FLOBER(1)) 3485 WRITE (6, 3487) 3487 FORMAT ( ' SEND K, KLOBER(K) :', $ ) READ (5, *) ID1, FD2 * IF ( 1D1 .EQ. 0) GO TO 3689 IF (mp1 ©) _KLOBER(ID1S oes 0) FLOBER(-ID1) = FD2 S S TA-3 3689 START OF EXECUTABLE CODE (PRODUCE THE PLOT). But I found nothing, while executing on our VAX with 4014 plotting of a little standard test file. In one test all floating point mumbers (subscripts ~1 through =14) were assigned values in the neighborhood of 1.E20; in two other tests, integers (subscripts +1 through +25) were assigned values around 900000. But nothing abnormal was observed. What is happening? C. LABORELEC Evaluation of SEL EMTP Segmentation Possibilities On page MMED-14 of a recent Memo (20 September 1981), I had indicated that LABORELEC had been given the problem of evaluating the potential for EMIP segmentation. Messrs. J. Verbinnen and A. Van Audenhove have most cooperatively and promptly provided the written analysis which follows (extracted from their letter dated 1M October 1981): More about a segmented EMTP for SEL now. We have read your 38 page TEEQ~1 memorandum + 12 page TOVK-6 appendix where VAX EMIP segmentation is explained. We think to have understood most of the ideas which are of some concern to us and we are convinced that any practical realisation will be different from one system to another. We will try to explain the possibilities that exist with SEL. As an introduction we will describe shortly the memory restrictions which should be taken into account when any SEL program implementation is considered under MPX. Under MPX the logical address space for one program is limited to IMB. Half of it (512 kB) can be used for code and/or data. The other half must be accessed in extended mode and only data can be stored in this second part. Because the operating system itself is included in the logical address space of a particular program and because the operating system must be integrated in the non-extended memory, the memory that remains for the code andfor non-extended data eventually, is limited to 512 kB minus space taken by the system. Actually our MPX operating system takes 192 kB so only 512 - 192 = 320 kB remain. Memory is allocated in segments of 32 kB thus each program size, the operating system included, will be a multiple of 32 kB. Our situation is as outlined in the figure : Operating system ) Code + (eventuall; non-extended data)| see Extended data Program's logical address space 1024 kB When keeping this in mind an evident solution would be to store the shared common area (data base) in extended memory (limitation 512 kB) so the size limit for each program accessing this common area would be 320 kB what seems to be rea~ sonable. Unfortunately the extended memory can not be shared by different programs. Several solutions can be considered :SSIA-4 ~ It is possible to place the shared common area in the non-extended part. We think that we may forget this solution immediately because it is not possible to store in 320 kB the shared common area plus the program segments that want to retrieve information form this area (you mst remember that no code can be stored in extended memory). = Another possibility would be to keep the common area in extended memory and to foresee a special shared buffer zone in non-extended memory. Each time that a Program segment wants to access the data base the information exchange should necessarily pass through this small shared global common buffer zone. The ‘buffer zone should be kept small enough to allow space (320 kB ~ buffer zone) for the execution of the program segment. It is difficult to estimate the amount of work it may ask to come to a practical realisation in this case but we guess that ib must be considerable. ~ Finally we arrive at the vital question whether EMTP segmentation is really feasible with SEL ? At this moment we think that any practical implementation should be based on extended memory usage. The standard system does not allow sharing of this memory between different programs however it may be possible that this limita~ tion may be circumvented by a system tiodification or maybe, by the time, SEL will provide for this adaptation. Anyhow we think that for future SEL EMIP development two stages should be considered : 1) Common data should be stored in extended memory to: liberate more space for EMTP code in non-extended memory. The overlay structure of the program remains the same and no segmentation will be performed. This modification can be worked out with a minimum of additional effort and only standard - SEL features will be used. 2) The possibility to share extended memory between programs should be considered carefully. The actual realisation may not be possible or difficult to realize. Presently we do not possess all the elements to give a final conclusion. So, as I read this, a segmented SEL EMIP would be simple if only the necessary memory sharing were possible in the extended-data region (rather than just in the non-extended region)! Or, if the EMIP were half its actual size! I am inclined to simply wait and hope that the factory might solve the problem for us in a future software release. To my way of thinking, the important thing is that only a Somewhat artificial limit seems to prohibit EMIP segmentation. The SEL FORTRAN and operating system apparently provide the needed features, only not in sufficient quantity (presently limited to half a megabyte). Well, with the astounding progress in integrated circuits, with desk-top computers which can now provide 16 megabytes of virtual address space, the disappearance of such half-megabyte limits seems inevitable. LABORELEC appears inclined to wait (Point 2), and I heartily concur. Systems are generally upward compatible, so one would not expect SEL to take away a Powerful feature like interprogram communication when address limits are improved. Not having “any background in systems programming, I refuse to even contemplate the Prospect of special operating system modification (though if LABORELEC, IREQ, or Some other serious SEL ENTP user considers it to be worth investigation, more pover ‘to then! ). Thus I am somewhat disappointed, though far from disillusioned. Segmented EMTP development will proceed in any case, so implementation for SEL should be routine once (if and when) the extra address space is gained. In any case, I thank Messrs. Verbinnen and Van Audenhove (the latter of whom I have never before heard from or about) for their competent analysis and well-written summary. I wish thatSSTA-S we had comparable cooperation and computer competence on the part of EMIP contacts for all other computer systems of EMIP interest. SEL EMTP support is among the strongest, in spite of our separation by the North Atlantic. Many thanks, gentlemen. D, VAX Penetration of the Electric Power Industry As I have observed in the past, PRIME obtained such a head start on VAX within the North American power industry (thanks to adoption by Power Technologies in the early to mid-70s for support of its PSS/E planning programs) that it was not clear whether the DEC VAX-11 system would ever gain a significant foothold. Well, BPA was first, I believe, and our sister agency WAPA (Western Area Power Administration in Denver Colorado) was not far behind. At about that time there was ECNSW of fustralia, and about a year ago we learned of HIDRONOR in Argentina. But they were isolated anyway (no neighboring PRIME computers to worry about compatibility with), and perhaps had an above-average sensitivity to the importance of hardware compatible with BPA. What about all the others? There is no question but that VAX spread within the industry has been slower than merits of the system would suggest, and I attribute this to the enormous inertia of industry software and those who manage the acquisition of it. For even later entrants like Data General (see Vol. X, 5 March 1981, page TOVX-5, paragraph 2), the challenge should be yet more difficult, no matter how meritorious their systems. Well, just during the past three months, we have learned of several new VAX systems within the industry. That Tri-State machine in Denver (see page MMED-1la, 20 September 1981) was an excellent omen, and apparently another VAX has been sitting in Calgara (at the former Calgary Power, whatever the new name is) for some time. We learned this latter item from Mr. D. J. Mader of Nova Scotia, which is currently looking very hard at VAX, Finally, Aki informed us that two members of his Japanese EMTP Committee now have (or have ordered) VAXs, with one of them being the manufacturing giant Mitsubishi (see page IEEO-37, paragraph 2). Consultants and/or manufacturers were among the first to switch to VAX --~- G.E. in Schenectady, CESI in Milan Italy, Shawinigan in Montreal, SCI in Palo Alto, and ESCA in Seattle. This latter outfit promises to have an enormous impact on the energy control center field, having just won a large contract with a bid which envisioned three VAX-11/780s at the central site and some five of the weaker VAX-11/750s at remote locations! There are universities as well, with Professor Robert Harrington at George Washington (in D.C.) having just sent usa tape, and Fernando in Madison making a similar request in a letter dated October 13th ("We also expect a VAX in the College of Engineering within weeks, so would you please also send a VAX version as well?"), The Plasma Physics Laboratory at Princeton was our first university VAX EMTP user, I believe, and most recently, Purdue University (Profs. Carroll and Ong) has shown VAX EMTP interest. We fully expect Ned to switch from CDC to VAX at the University of Minnesota, too, as part of an ambitious upgrading of laboratory facilities to include load flow and transient stability use. After a slow start, VAX penetation of the industry seems to be picking up speed, all right. For EMTP usage, VAX has already displaced PRIME for the mumber two position, trailing only ‘TBM in terms of number of computers on which the EMTP is running. E. EMIP Information from Nissin Electric (Japan) In a letter dated October 21st, our EMIP contact at Nissin Electric (Kyoto, Japan), Mr. Yoshiya Ogihara, provided several items of general information. Yoshiya sent further analytical details of his analysis which confirms that our Joint study here in Portland last December did indeed involve self-excitation of the generator whose load was being rejected. A detailed summary by Yoshiya is expectedSSIA-6 to appear in the next issue of the Newsletter (in three months or so, since one has just been published). The delay is all my fault, due to an exercise of editorial Prerogative. Yoshiya is the first IBM EMTP user who is known to have gone beyond the primitive installation-dependent restrictions of the past. The problem is with OPEN and CLOSE statements, which are missing in IBM FORTRAN of Level G or H. The automatic saving of the LUNITY disk file of plot data points (miscellaneous data parameter ICAT positive), the later plotting of these results ("REPLOT"), the saving of EMIP tables (miscellaneous data parameter MEMSAV = 1), the later continuation of such a solution ("START AGAIN"), etc. ----- all such sophisticated usage requires the OPENing and CLOSEing of files within FORTRAN to be handled easily. Because IBM did not have this capability, such features were inoperative in IBM EMIP versions of the past. Yet these features are very valuable, so it pays to go to some little extra effort in the case of IBM. Following an explanation of the essential logistics by me, Yoshiya has done this, and apparently the current Nissin IBM EMTP version now has the important features illustrated above: "We confirmed that the "START AGAIN’ request with CalComp plotting was made possible by your information and some cut and tries by us. .... You will find evidence of our success in the enclosed output lists. I hope you will be satisfied with the enclosures, including the example of 'REPLOT' usage.” We are, Yoshiya, and as with all similar progress of the past, one can only ask why it was not done before (life would have been substantially easier for many, many IBM EMTP users)! Thanks, Yoshiya. Yoshiya confirms Art's information that "VS FORTRAN" is the new IBM compiler (see page MMED-14, Point B), but he indicates that Nissin is not overly anxious to convert in the case of the EMIP, due to reliability considerations. A letter from Fernando (Madison) dated October 13th seems to indicate that this is only pre-release software, anyway ("As far as IBM, .... no ‘official’ Fortran '77 exists, at least not till January or so. But there are unsupported compilers.”). 1 have asked the Europeans (via Daniel) and Brazilians (via Mr. Guimaraes of FURNAS) ‘to report IBM compiler status in their areas of the world. Until more positive news is received, no changes are contemplated for the IBM E/T or installation-dependent modules. When we talk about IBM, the reader should remember that we are talking about IBM software, not necessarily IBM hardware. In this country, Amdahl (as used by Hermann at UBC) is a big plug-compatible competitor, and apparently Japanese have their own such machines (in addition to their substantial minority ownership of Amdahl). Yoshiya is one of these plug-compatible users: "We used the IBM 3032 machine for the first set-up of M28+ this January and now are using HITAC 8680 under ‘TBM operating system. Japan Information Service, Ltd. is responsible for the management of the big machine system." We will see more of this in the months and years ahead, I am sure. If hardware differences lead to any EMTP complications (as with 360-vs.-370 differences), please let us and other readers know about it. That recent generalization of extrema search (see page MMED-1, 20 September 1981) was in response to Nissin question, if I am properly reading between the lines of Yoshiya's letter. He offers some summary physical justification for such modeling: "... we have noticed the significance of knowing voltage peaks, for example, both at the occurrence of gap discharge and at the reinsertion of a series capacitor bank in studying a series capacitor protection scheme. The extrema search could become a strong tool from the viewpoint as stated above, especially when many switches operate in different ways. We are now looking over all the subroutines where the scalar BEGMAX should be changed into a vector BEGMAX(6) in /BLANK/ COMMON, and thinking how the values are to be printed out without any confusion.” Well, this helps, since I now understand a little better the need. Further, I conclude that my generalization, while a useful extension in its own right, does not respond to the Nissin need. The simplicity of my modification lies in the fact that only one