MMED-1 Date: 20 September 1981 Dr. Hermann Doumel, Prof., Univ. of B.C., Vancouver, CANADA Equardo Bueno Guimaraes, FURNAS, Rio de Janeiro, BRAZIL Dr. Arun Phadke, AEP Service Corp., New York, N.Y. To + listed addressees Mette maven Mannheim, WEST GERMANY HPA, goute Doak Bernd Stein, FOH, P. 0. Box 3621 Dr. Akihiro Ametani, Prot., Doshisha Univ., Kyoto, JAPAN Portland, Oregon 97208 use Brierley, Ontario Hydro, Toronto, CANADA Phone: (503) 234-3361 7 Ext. 4404 Dr. Bob Lasseter, prof., Univ. of Wisconsin, Madison Dr, Daniel Van Dommelen, Prof., KUL, Heverlee, BELGIUM BPA, EOGA ---~ Dr. Tsu-hued Liu (library copy) BPA, BOGE ---- Alvin legate / Herbert Konkel TRANSIENTS PROGRAM MEMORANDUM Subject : More miscellaneous EMTP development and commentary. © GENERALIZED EXTREMA SEARCH AT SUGGESTION OF JAPANESE EMTP COMMITTEE During Aki's final evening in Portland (the 28th of August, I believe), we found the time to consider a list of questions and problems which he was conveying on behalf of the Japanese EMTP Comittee. I have no information as to which member submitted the valuable suggestion which follows, so the Committee as a whole shall receive my appreciation. Is it possible, Aki asked, for the EMTP to compute output variable extrema just for particular user-prescribed time intervals? "30." and earlier EMIP versions allowed only a time delay before the search for extrema would begin (via the "BEGIN PEAK VALUE SEARCH" request of the EMIP Rule Book, Sect. 1.0e11, page Ye-1). Even this limited capability must be credited to outside sources, I might add: the idea was contained in a letter dated 30 January 1979 from Mr. Rino Curti of CESP in Brazil (Companhia Energetica de Sao Paulo). Why I did not think of the logical extension from a scalar to a vector at that time is difficult to appreciate at this late date. So, we now ("'M31." and later non-VAX versions) offer Aki and his friends the following generalization. The EMTP user is allowed to define a sequence of time intervals (T1, T2), (T3, Ta), ..-. ete. over which the search for extrema shall be limited. Here the "Ti" are monotone increasing times, with the first giving the beginning time and the second and ending time, for each computation interval. For ‘example: (,005, .015), (4150, .200), (1.E30, 727?) There really are only two finite intervals here, note. ‘The third, beginning at near infinite time 1.£30, will never be begun (so the ending time is immaterial).MMED-2 Programming for this extension was simple. The /BLANK/ scalar BEGMAK has been made a vector BEGMAX(6), and the meaning of misc. data parameter MAXOUT has been altered. With a sequence of intervals (limited to two active ones, temporarily), we needed a companion INTEGER pointer in /BLANK/, so I seized upon MAXOUT. The original contents of MAXOUT (0, 1, or 2 as requests for extrema) have been moved to BEGMAX(1), so the Ist pair of times are stored in BEGMAX(2) and BEGMAX(3), ete. for later ones. The "BEGIN PEAK VALUE SEARCH" request is still used for simplicity, with a special value "-1.0" read from cols. 33-l0 indicating that an extra data card is to follow. This new additional card is to be punched with BEGMAX(2) through BEGMAX(6),. which are read using the familiar 10E8.0 FORMAT. So, my thanks to some unknown individual in Japan for initiating the question which led to this very clean (no new COMMON variables) and useful generalization. If the physical problem requiring such generalization could be summarized in a page or less by that individual, and if he would mail such material to me in Portlend, I would include it (with appropriate acknowledgement as to the source, of course) in a future EMTP Memorandum. @) BURROUGHS REVISITED : SJM3 AND WSM IMPROVE THE EMTP PROCEDURES Readers of Volume X EMTP Memoranda (14 February 1981, pagination ECWB) will recall that Burroughs computers have already forced a number of adjustments to what we thought were universal procedures! My stop at Ebasco Services (in New York City) last February proved that the EMTP really was compatible with Burroughs --- provided we changed certain preconceived ideas, exercised some new cautions in our universal language programming, made certain minor translator. modifications, and finally, corrected bugs which were found in installation-dependent EMTP modules. Stoney (Mr. Stonewall Jackson MeMurray, III, affectionately known to Ebasco computer operators by the moniker "SJM3") and I have been busy making what we hope to be these final adjustments, in preparation for a new "M31." Burroughs EMTP translation at the end of October. Meanwhile, an interim, prototype translation was just made last night (September 25th), to allow Jose to take current EMTP code back to Caracas with him (we now expect that he will leave Portland on Monday, September 28th). This present. section of the memo will serve to document my changes for Ebasco, and’also clarify ‘the tape contents for Jose and others (in Germany and Columbia) who will be out of convenient telephone contact. A. Changes to the UIPF to Ensure EMIP Compatibility with Burroughs ———— Although my records are far from complete, let me summarize where the UTPF now stands vis-a-vis Burroughs. Most of this work was done during late February and March, before I realized that other priorities (interactive EMTP execution; my trip to Montreal) would force a long suspension. First, we have made a conscious attempt to remove all conflicts between vectors and scalars in arguments of SUBROUTINE and FUNCTION calls (Problem B, page ECWB-l1). Stoney provided us with reels of the H-P CRT hardcopy showing CANDE searches for all offending character strings, and we have done some searches here as well. If some incompatibilities remain, they will most likely be isolated new ones rather than methodically-repeated old ones. Further, correction of any such new ones should be routine, not requiring any structural changes (like the new module "FREONE” which Stoney and I devised last February). Speaking of "FREONE", I might just mention ‘that the listing on page ECWB-4 4s quite erroneous; I must have done the typing while Iwas half asleep. For the record, I include a corrected listing here:MMED-3 M29. 935 SUBROUTINE FREONE ( D1 ) M29. 936C © SCALAR VERSION OF "FREFLD" WHICH ENTERS THE UTPF WITH M29. 937¢ "M29." VINTAGE, TO SATISFY BURROUGHS (SEE PROBLEM B, M29. 938C SECTION II, PAGE ECWB-4, VOL. X EMTP MEMO OF 14 FEB 1981. M29. 939 DIMENSION ARRAY(1) M29. 940 CALL FREFLD ( ARRAY(1) ) M29. 941 D1 = ARRAY(1) M29. 942 RETURN M29. 943 END There may still be problems with CalComp plotting (confined to "SUBR31" of overlay 31), which has numerous CALLs to the plot SUBROUTINEs that we have no control over. Also, I make no pretentions or assumptions about overlays 48 and 49 (Dr. John Hauer has sole responsibility for this "HAUER SETUP" code), Stoney did just recently mention the desirability of commenting out the LOCINT usage which is.never executed by a Burroughs ENTP because of protective bypasses of the form "IF ( KBURRO .EQ. 1) GO TO 2272". He explicitely mentioned the UTPF ident 22.3590, which I found in "OVERI2" : 22.3590 IF ( KBURRO .EQ. 1.) GO TO 4093 22.3591 N1_= LOCINT( FKPOS1(1) ) =~ LOCINT( IRANDN(1) ) M22, 3592 CALL MOVEO (TRANDN(1), 1) Frankly, I do not understand how this could cause trouble; and further, I see no clean and easy way to omit it. Precisely what is the problem here? Stoney worried about the Burroughs binder being confused, I remember that much. Concerning those smaller problems which begin at the bottom of page ECWB-5, let me rapidly confirm the following UTPF modifications: 1. "LABLO2" is now the name of our local overlay 2 "deck" (Problem E). 2, "LINE CONSTANTS" has been smoothed (Problems G, H). 3. Overlay 13 was segmented; "LAST13" now exists (Problem I). 4, "SPACE2" “changes to renumbering and steady state solution. ‘The final point above is not minor, and it deserves substantial clarification. At issue is the indexing of overlays 7 through 11, with emphasis on node renumbering ("OVER7"). Recall that Stoney and I had considerable trouble with out-of-bounds subscripts when I was in New York City (refer to page ECWB-8, Bug 4; ECWB-9, Bug 5; ECWB-10, Bug 9). Well, it is with great pleasure that I can report the successful elimination of all illegal subscripting in "OVER7"! This is a pleasant surprise, for I had earlier predicted that the symptoms might merely be suppressed without the underlying problem being cured (see bottom of page ECWB-9). But not so! Thanks to one strenuous evening of work here in Portland, and a good share of luck, we have apparently eliminated all illegal subscripting. ‘The procedure was simple: wherever John Walker used a subscript, I would check it by means of a CALL to the following specially-designed routine: VAX. 570 ‘SUBROUTINE SUBSCR ( J, LIMIT, ISTAT, N1 ) VAX. 571C MODULE USED TO CHECK OUT-OF-BOUNDS SUBSCRIPTS FOR "OVER7" VAX. 572C SPECIAL N1=99 CASE IS FOR SUBSCRIPTS WHICH ARE USED ONLY VAX. 573C° IF POSITIVE (WSM CHANGES TO WALKER'S CODE). VAX. 574 IF (J GE. 1 AND. Wax. 575 01 J.s«LE. LIMIT ) GO 0 9000 vax. 576 IF (J «LE. 0 AND. NI «EQ. 99) GO TO 9000 VAX. 577 WRITE (6, 1487) J, LIMIT, ISTAT, N1 VAX. 578 1487 FORMAT (" 26H OUT-OF-BOUNDS SUBSCRIPT =, 6, VAX. 5791 12H. LIMIT =, 16, vax. 5802 15H . BELOW S.N., "16, VAK. 5813 20H "WITH SEQUENCE NO., 12, 2H. ) VAX. 582 9000 IF ( IPRSUP .GE. 99 ) VAX. 583 1 WRITE (6, 9006) J, LIMIT, ISTAT, N1 VAX. 58 Q006 FORMAT ( 20H TRACE. J. LIMIT. ISTAT.. N12... uTa )VAX. 585 RETURN M M ED WAX. 586 END ‘The hundreds of CALLs really do not require any explanation, though I pass along a very stall example from the middle of "OVER7" as an illustration: 8430 290 IB = IST VAX. 377 CALL SUBSCR ( JST, LSIZ23, 290, 1 ) 16.119 ISUBS1 = TOFKOLWST M16.1150 J = KOLUM(ISUBS1) VAX. 378 CALL SUBSCR (J, LBUS, 290, 2 ) 8432 JB = LOC(J) 8433 ICON = 1 8434 JBS = 0 8435300 IF (JB .EQ. 0) GO TO 200 ‘The third argument refers to the statement number immediately above ("290" here), and the fourth provides counting to differentiate between two or more references below any one statement number. Well, with this monitor in place, DC-8 (the old GPU Stolle Road problem) was solved, and of course numerous (perhaps 100) subscript exceptions were found. But to my surprise, they only involved zero subscripting. That is, there were no subscripts too big, and there were no negative subscripts. Clearly, this was hopeful. Looking further, I made quite an unexpected discovery: The zero subscripts occurred at only six locations within "OVER7", and further, they only appeared on the left hand side of equal signs! That is, data was being stored out of bounds, but was never being recovered from there.’ It thus appeared to me that such statements could simply be bypassed without affecting the answers. We still CALL SUBSCR for these six instances, though with fourth argument equal to "99", so that "SUBSCR" will not wave the flag if subscript value is zero. For the record, I document these six most important modifications to the "OVER7" logic: 8332 ICHI(I) = K vax. 347, CALL SUBSCR ( I, LBUS, 155, 2 ) VAX. 348 IF(K GT. 0) ICH2(K) = 1 va. 349) CALL SUBSCR ( K, LBUS, 155, 99 ) 8367 NDEX(NCN+1) = J VAX. 358 JSUB = NON + 1 VAX. 359 CALL SUBSCR ( JSUB, LBUS, 222, 2 ) ‘VAX. 360 IF (J GT, 0) IcHa(J) = 0 VAX. 361 CALL SUBSCR ( J, LBUS, 222, 99 ) 8564 K = ICHI(J) vax. 4g2 CALL SUBSCR ( J, LBUS, 840, 1 ) VAX, 493 CALL SUBSCR ( K, LBUS, 840, 99 ) VAX. 494 CALL SUBSCR ( L, LBUS, 840, 3 ) 8565 ICHI(L) = K VAX. 495 IF (K .GT. 0) IcHa(K) =L 8569 850 K = ICHI(J) VAX, 96 CALL SUBSCR ( J, LBUS, 850, 1 ) VAX. 497 CALL SUBSCR ( K, LBUS, 850, 99 ) ‘VAX. 498 IF(K .GT. 0) ICH&(K) = 0 8577 TcH1(J) = K VAX. 504 CALL SUBSCR ( K, BUS, 860, 99 ) VAX, 505 IF (K GT. 0) IcHa(k) = J The second of the six (in order of occurrance) could not thusly be displayed using current code, since it was a deletion. Below S.N. 190, there was obviously-zero indexing which was simply deleted. For reference purposes, I here display that now-deceased offending code: M06. 23 190 NCN = 0 Mob. 24 INDEX(NCN) = 0.° MMED-5 0 M06. 25 ICH1(NCN) M06. 26 ‘ICH2(NCN) 8348 NELIM = 1 So, that is the end of the story for now. Module "SUBSCR" and all the CALLs to it remain in place for the time being, as insurance. Should anyone notice messages about illegal subscripts in the weeks ahead, we will look further. Otherwise, at some point not too far in the future, all "SUBSCR" reference will be deleted, and we will all (including Burroughs users) live happily ever after! Special mention might be made of that final bug which gave SJM3 and WSM so much trouble (page ECWB-10, Bug 9). This is the one exception to my previous statement. that the only out-of-bounds subscripting was zero: had we not especially protected the code below S.N. 200, there would have been thousands of too large subscripts. For the record, I document that this temporary Burroughs patch has since been made a permanent pert of the UTPF: 8349 200 CONTINUE M29. 1518 IF (NCN GE. LBUS) GO TO 220 WAX. 352 JSUB = NCN + 1 VAX. 353 CALL SUBSCR ( JSUB, LBUS, 200, 1 ) Although Burroughs is not at all affected by it, I might also mention that our Univec friends (Vladimir, Russ, and Ray in Toronto) have paid dearly for that "M29." UTPF modification to "NDEX" usage (see Bug 4 on pages ECWB-8 and 9). Tt seems that Rey can only ensure COMMON block ordering for Univac (no longer necessary, if he were to resort to the Burroughs/Prime resolution) if he does some special collection of the blocks. Well, he was keying on special characters in the block name, as I recall, and "NDEX" wound up in overlay 29 (LABL29)! The particular construct of "WARDIM" “in the UTPF which led to this trouble appears as follows: M22. N61 MODULE ( OVER29, 29 ) Mee. 62 ‘DECLARATION DECK29 N22. 463 COMMON / KARRAY, 0 ) N22. Nel = COMMON. / BUS. } 1.) _ ALPHANUMERIC << Ete. for other COMON of overlay 29 >> 475 DECLARATION” SPACE1 309 EQUIVALENCE / YKM(1), 23 / TP(1), TIMI(1), TIM2(1), @ 1 AP(1), A1P(1), ra) : b 7 DECLARATION SBaCI ts Como 7 wen 1) —e—— Problem M22. 479 EQUIVALENCE / KK(1) 1, / KODE(1) . << Ete. for original content of SPACE2 > > Well, Ray could have corrected his Univae translator, though this will no longer be necessary. Because no subscripting of "OVER7" ig out of bounds any longer, and because NDEX is not used anywhere else in the program, NDEX can again be made local. As in years past, NDEX is again EQUIVALENCEd to E, only now without any offset: 8298 «OVERLAY ( OVER?, 7) 8299 INSERT DECK BLKCOM 8300 INSERT DECK LABCOM 8301 INSERT DECK EQUIVA M22.3210 INSERT DECK SPACE2 VAX. 340 DIMENSION LORDER(1), NDEX(1) vax. 31 EQUIVALENCE ( ICH2(1), LORDER(1) ), ( E(1), NDEX(1) ) So, Ontario Hydro, too, has also contributed to Burroughs EMTP development -- albeit @ little involuntarily (sorry for the inconvenience, Ray)! B, Changes to the Burroughs Editor/Translator (E/T) The first Burroughs E/T modification provides for movement of the UTPF idents from colums 73-80 (the familiar FORTRAN comment field) to colums 65-72, with a preceding percent sign punched in column 64. This was suggested by Stoney (see pageMMED-6 ECWB=12, Point CH6), who noticed that about 90% of ENTP records had colums 61~72 blank anyway. By moving the UTPF ident, columns 73-80 were freed for proper CANDE serialization (more about this later) that would insure immediate and unambiguous identification of an offending statement in case of an operating systen interrupt (e.g., for division by zero). For those 10% or so of cards which have no such room, the UTPF ident was placed on a preceding comment card. For simplicity, such ident moving was made a post-processing operation, to be executed after the translation per se is complete, It was buried in the existing, seldom-used loop which provided a console (unit 6) listing of the Burroughs EMTP, so miscellaneous data parameter TPRINT (columns 1-8) must be positive for this to be executed. On the other hand, users must now limit IPRINT according to their paper budget and/or console speed (it is now used as a line limit on the printed output)! If the user selects IPRINT = 10 as I did for Jose's translation, there will be a long (maybe 10 minute?) pause after the Listing of the 10th record, as the ident-moving proceeds. When complete, there will be a message summarizing the process: NUMBER OF SPECIAL UTPF-IDENT COMMENT CARDS = 6695 The modified output is on unit 25 rather than unit 7 (we copy from LUNIT7 to LUNT25 as part of the processing). Note that Stoney was very close with his guess of ten percent (the UTPF currently stands at 69175 cards, and 6695/69175 = 9.68%)! Because most comment cards represent such exceptions, and because comments are ignored by ‘the compiler anyway, I would be tempted to further reduce this extra overhead by discarding the UTPF idents of those comment cards having nonblenk columns 64~72. It would be easy, and could be made another option of the miscellaneous data card. Burroughs translation of the universal "INSERT DECK DEKNAM" has been modified from the simple "$ INCLUDE 'DEXNAM’" to a more sophisticated structure based on CANDE serialization. This was not one of the two aspects of Point CH1 on page ECWB-11 which I had previously documented, though Stoney did talk about it at the time, and documented details in a hand-written Ebasco "Speed Letter" to me dated April 20th. The idea is to unify all 26 INCLUDE files into a single disk file for simplicity of manipulation (e.g., restoration from tape to disk, should EMTP FORTRAN be a casualty of that Ebasco automatic file purger). A CANDE serialization range then follows the deck name on the "$ INCLUDE” card, to specify which portion of the new unified file is desired. For example, consider our miniature test file MMUTPF at the beginning of "SUBR10" SUBROUTINE SUBR10 INSERT DECK BLKCOM INSERT DECK LABCOM INSERT DECK EQUIVA 3001 CALL OVERLAY ( OVER1, 1 ) ‘The new Burroughs E/T will translate this portion of universal language code so as ‘ appear in the following form: SUBROUTINE SUBR10 * 10010100 IMPLICIT REAL*Y (AH, 0-2) , 10010200 1 INTEGER*4 (1-N) 10010300 $ INCLUDE ‘COMDECK' 00100000 = 00199999 % (DECK "BLKCOM") 10010400 $ INCLUDE 'COMDECK' 00400000 - 00899999 % (DECK "LABCOM") 10010500 $ INCLUDE 'COMDECK' 00200000 - 00299999 % (DECK "EQUIVA") 10010600 3001 CALL OVER1 10010700 Tne CANDE serialization of deck records (within file "COMDECK") is very simple, and it allows plenty of room for future EMTP expansion. The eight decimal digits can be denoted by: CANDE serialization of "COMDECK" card = 0 JD1 JD2 JR1 JR2 JR3 0 0 where the deck number (in order of E/T definition) JD = 104JD1 + JD2, and record number within each UTPF deck is JR = 100*JR1 + 10"JR2 + JR3. In the above example, BLKCOM is UTPF deck number one, LABCOM is deck number two, and EQUIVA is deck number four. The $ INCLUDE will pick up any lines in the range zero through 999 of such a UTPF deck, which is all inclusive (no UTPF deck will ever approach one thousand records). It is guaranteed to work, PROVIDED the E/T correctly serializes columnsMMED-7 73-80 of the "COMDECK" file. Note that this is the Achilles heel of the procedure, since the FORTRAN compiler will go wild if serialization should be in error. As an illustration of the "COMDECK" CANDE serialization which is produced by the Burroughs E/T, I reproduce a portion of the file which now comes out unit MUNIT3 =" 14 (again using MMUTPF for compactness) : c FLAG-1. BEGIN CLASS~1 /BLANK/ VARIABLES 00100100 << Ete. for interior of "BLKCOM" > > COMMON ICAT, NUMNVO, IFLAT, NENERG, ISW, ITEST 00101300 EQUIVALENCE ( X(1), INTEGX(1) ) 00200100 COMPLEX C1, C2, COMDUM 00200200 COMMON /COMY7/ A(10,10), B(10), C 00300100 COMPLEX A, B, C 00300200 € ‘BEGIN WITH THE LIST-3 VARIABLES (R-L-C VALUES). 00400100 COMMON / COBOO1 / XxX rh) 004100200 << Ete. for interior of "LABCOM" > > COMMON / COBOI1y BUS ( 1) 004101700 REAL BUS 00401800 COMMON / C2QB01 / KARRAY(1) 00500100 COMMON / C29B02/ BUS (1) 00500200 COMMON / C29B03 / BUSS2 (1) 00500300 COMPLEX BUSS2 00500400 << Etc. for the remaining UTPF decks > > We here observe the deck numbering of one through five for BLKCOM, EQUIVA, DECKU7, LABCOM, and. LABL29. All initial users of this new feature should carefully check that such serialization is correct. To simplify the recognition of deck boundaries, it. might be reasonable for the first card of each UTPF deck to be a comment bearing the deck name. Or maybe the Burroughs E/T could generate such a record more easily itself, automatically. We will think about it. After all, not all users are able to recognize deck boundaries by inspection the way I do. I might mention that the "/NOLIST" option which I had promised to implement (see very top of page ECWB-12) is now hidden within "COMDECK" if it is used. The miscellaneous data card of the Burroughs translator now has a new parameter "LISTOF" in colums 57-64; if left blank or punched with a zero, Stoney will continue to see all of his COMMON blocks (his preferance, not mine); if a "1" is punched in column 64, all COMMON blocks will disappear from the compilation listing. The translator accomplishes this latter feat by inserting $ RESET LIST in front of each UTPF deck, and $ POP LIST at the end. Simple and effective (I prefer this Burroughs scheme to ‘the more common "/NOLIST" of the VAX and other computers, since the distinction is made in the INCLUDE file itself, rather than in the EMTP FORTRAN). For now (for Jose and Stoney), the LISTOF field is being left blank, however, and all COMMON blocks will appear in compilation listings. I have already mentioned more than one output file of the Burroughs translator. In fact, there now are three. The EMTP FORTRAN will be found on unit LUNT25 = 25, with leading CANDE serialization digit equal to one: IMPLICIT REAL*S (A-H, 0-2) , 10000100 1 INTEGER*4 (1-N) 10000200 $ INCLUDE 'COMDECK' _00100000 - 00199999 (DECK "BLKCOM") 10000300 c IDENT OF NEXT CARD : 315. 20310000400 C) HOE aaa aaa aaaEnnnEnio Leena a iano aaa Ha N aa NEA aEEEAETEENII | OOOOLIOO c IDENT OF NEXT CARD : $415. 20410000500 >) #0000500 c IDENT OF NEXT CARD : #415. 20510000600 C)— meennennmnnnnns ELECTROMAGNETIC TRANSIENTS PROGRAM —---------—- #1000600 Ete. This example of the beginning also illustrates the unsightly nature of those extra comment cards which just carry UTPF idents of the following comment.cards.. Tt seemsMMED-8 to me that readability is badly obscured, and that we should dispense with the UIPF identification in such cases (who cares, anyway, about comment cards?). As for the second, I have earlier illustrated "COMBECK", which is sent to unit MUNIT3 = 14. Finally, on unit LCANDE = 24 we have the variable-dimensioning progran "VARDIM", which uses leading CANDE serialization digit equal to two: DIMENSION CBLOCK(300), NCBARR(300), CBLSER(300), JBLTYP(300) 20000100 DIMENSION LSTNEW(99), LSTDEF(49), TYPE(4,3), KEXTRA(29) 20000200 DIMENSION ABUFF(14), CHAR(6), MULVAR(4), BUS1(1) 20000300 DATA CBLOCK( 1) / 6HX 4; NCBARR( 1) / 3/ 20000400 DATA CBLSER( 1) / 6HCOBOO1 /, JBLTYP( 1) /°0 7 — 20000500 DATA CBLOCK( 2) / 6HYKM /, NCBARR( 2) / 5 / 20000600 DATA CBLSER( 2) / 6HCOBO02 /, JBLTYP( 2) /:0 / 20000700 DATA CBLOCK( 3) / 6HKM = /, NCBARR( 3) / 5 / — 20000800 Ete. Other than this new serialization, the only change to "VARDIM" is associated with the production of EMTP table-dumping routine "TAPSAV". Since /LABEL/ is involved, a %§ INCLUDE” is required, and this was indeed erroneous before (see page ECWB-10, Bug 6). I found that apostrophes were previously missing. These have since been added, along with the more complicated reference using CANDE numbers. I have executed the Burroughs "VARDIM" here on our VAX, to be sure that everything was in order. Only very superficial changes were required: an IMPLICIT REAL*8 (A-H, 0-Z) was added, ABUFF(14) became ABUFF(10), (1346, A2) became 10A8, the REAbs from memory were switched to DECODES, and error termination calls ("LOCK 2" and "CALL ERTRAN") were omitted. The unit 2 output (FORO02 for our VAX) then appeared as follows, in the vicinity of "TAPSAV" : SUBROUTINE TAPSAV ( NARRAY, N1, N2, N3 ) $ INCLUDE 'COMDECK’ 01700000 ~"01799999 TF (3 .EQ. 2) GO TO 5891 WRITE (N1) (KCL), 500 ) WRITE (N1) (YKM- (L), Le1, 2500 ) Since LABCOM is the seventeenth UTPF deck in a production translation (the first variably-dimensioned deck, following the sixteen fixed-dimension decks at the front of the UTPF), this looks fine. From what has just been said, the sequence of operations for a Burroughs EMTP setup should be clear. Jose should first pick on the "COMDECK” file (VAX disk file BURRODECK.FOR), feeding it into CANDE so that it will be ready for "TAPSAV" as just illustrated. “Then he should compile "VARDIM" (VAX disk file BURROVAR.FOR), bind it (the Burroughs equivalent of linkage-editing), and execute it. Three blank data cards can be supplied to unit 5 (to give default EMTP List Sizes), about half a page of printout will appear on unit 6, and the EMTP table-sizing modules should appear on unit 2. It is this unit 2 output which should be legal FORTRAN, and hence can be immediately compiled to confirm the point. If this is a success, the resulting object code can be saved for later binding with the EMTP proper (recall that this is the way ETP tables are sized). Only after this has all been completed is Jose advised to turn to the EMTP proper (VAX disk file BURRO30.FOR), and even then it is probably wise to initially just deal with the front end, perhaps through overlay 5 (where EMTP source cards are read, and at the end of which DIAGNOSTIC printout will dump EMTP tables). Only after successful setup and execution of this "EMIP front end" is it recommended that one progress to the full EMTP. Most of the installation dependent EMTP modules are positioned in the initial three overlays, so possible errors and incompatibilities in these can most economically and simply be discovered by such truncated testing. Compiling and binding is faster and cheaper, the listing is much smaller, etc. Special mention mst be made of a 4th file, the Ebasco Algol coding of memory location FUNCTION LOCF (VAX disk file BURROLOCF.FOR). This must be fed into the Burroughs Algol compiler before the EMTP is bound. of course. and EMTP binding isthen @ mixed FORTRAN and Algol operation. Although I do not remember any details of this, I comment that Burroughs is remarkably flexible this way. For the record, I document the non-comment portion of the Burroughs "LOCF” : ‘$SET LIST INTEGER PROCEDURE LOCF(A); ARRAY AC]; BEGIN ‘LOCF:=DELTA(POINTER(A) ,POINTER(A[O])) DIV 6; END LOCF; INTEGER PROCEDURE LOCINT(A); ARRAY AL#]; BEGIN LOCINT: =DELTA(POINTER(A) ,POINTER(ACO])) DIV 6; END LOCINT. Because of this Algol segment, the file of Burroughs installation dependent EMTP modules now contains requests for the removal of these universal modules: REMMOD LOCF REMMOD LOCINT Another change in translator usage is the destruction of variable-dimensioning modules as they are encountered in the UTPF by the Burroughs translator. Burroughs could either add or substitute for such modules before binding, and why Stoney and I originally decided to substitute is no longer clear to me. Anyway, retaining those dummy modules leads to some compiler trouble (because of that unusual global memory, as documented in "Problem D" on page ECWB-5). Well, destruction of the "VARDIM" modules was trivial, since either option had been built into the Burroughs E/T logic (I had forgotten this detail when I wrote page ECWB-5). All that I had to do was add a "1"-punch in column 40 of the miscellaneous. data card of the translator (data field KDISC), and the unwanted modules disappeared! At least I think they did (I should be informed if one or more is ever encountered). For completeness I mention the very minor bug CH3 near the top of page ECWB-12. There was a missing END statement, though not belonging to "VARDIM" as I earlier reported. After reporting to Stoney that "VARDIM" looked all right, Stoney told me to look at the LUNIT2 = 2 output after execution of "VARDIM", the EMTP modules of variable dimensioning. Lo and behold, Stoney was right, the final record of LUNIT2 should have been END (belonging to "DIMENS"), but it was missing. Yet the WRITE to generate such a card was found in the translator, so I deduced that I merely had counting trouble. The DO 8258 loop of "VARDIM" used to transfer NREC3 records to the final output position on LUNIT2; now it continues until an end-of-file mark is reached (using the "END=" qualifier for the READ). With this change, the ising END has reappeared! As to why I had so much trouble spotting this, apparently V. interactive computation does not complain about such a minor detail. C. Changes to Installation-Dependent EMIP Modules for Burroughs — If the previous two Sections (concerning the UTPF and E/T) are believed to be nearly in their final states, not so for this one. I simply have not yet found the ‘time to methodically rework the installation-dependent EMTP modules for Burroughs. Jose has been warned of this shortcoming. Yet Stoney and I did make a valiant last-minute effort Friday afternoon (September 25th), as Stoney was reading me key portions of some of his current Burroughs code over the telephone. The following corrections are believed to have been made (though I lack all hard copy verification from New York):MMED-10 First, there was correction of "Problem A" on page ECWB-3. Recall that much of Stoney's early compilation trouble was related to the unintentional processing of VAX installation-dependent FORTRAN. By means of REMMOD requests to the translator, three unwanted modules are now being discarded: REMMOD SETTYM REMMOD MAYDAY REMMOD LOOKTE Actually, "MAYDAY" is disappearing from the UTPF, anyway (as $-card interactivity is being dismantled), so the Burroughs SUBROUTINE CIMAGE now need never be so massively enhanced. I probably should remember to send Stoney a copy of my memo explaining ‘the segmented EMTP, and get his reaction vis-a-vis Burroughs. The VAX "PACKCH” should no longer be a problem, now that the missing SUBMOD precedes it: SUBMOD SUBROUTINE PACKCH ( FROM, TO, KHOR6, NCHBEG, NWORD ) Module "MIDOV1" has not yet been enhanced, but at least now a dummy version should exist on the Burroughs EMTP tape: SUBMOD ‘SUBROUTINE MIDOV1 RETURN END Concerning "DLIBRF", it is no longer just Burroughs which experienced trouble, I might mention. Mr. J. Verbinnen, the SEL computer expert of LABORELEC in Belgium, has instructed me in a letter dated August 18th that" .... the calculated return address from this entry point is wrong. This results in damage to our operating system. Enclosed (attachment 1) you will find an assembler routine DLIBRF." So, Stoney's problems were mild in comparison, and readily solved at the FORTRAN level: ‘SUBMOD SUBROUTINE DLIBRF(X, Y) DOUBLE PRECISION X, ¥ RETURN ENTRY DEXPZ ( X, ¥ ) Y = DEXP(X) Ete. Precisely the same problem and solution were applicable to "RFUNL1" and other EMIP Ubrary-funetion modules, of which I only document the beginning of this one module: FUNCTION RFUNL1(X) © —_INSTALLATION-DEPENDENT EMTP MODULE WRITTEN FOR BURROUGHS. ENTRY ABSZ(X) RFUNL1 = ABS(X) Ete. Finally, we have "LOCF" (near the top of page ECWB-l}), which is being handled as a separate file as per the previous Section II-B mention. No special construct has been applied to COMPLEX FUNCTIONs (see "Problem C” on page ECWB-5). I assume that SJM3 silence on this point is consent to my inertia and procrastination. Bug 1 on page ECWB-7 has been corrected (Stoney read me his revised coding for "PACKA1" over the phone). I corrected Bug 3 on page ECWB-8 myself, without benefit of the answer from New York. The new code now reads as follows (is it ok, Stoney?): SUBMOD ‘SUBROUTINE TIMEWY ( A ) ALPHANUMERIC A DIMENSION (2) INTEGER TIME D1. = TIME(1) ee are7 MMED-11 The final line shown used to be "D1 = D1 * 60", which was obviously not the correct way to get from sixtieths of a second to seconds! Not unlike my previous reform of "PACKA1", module "PACKCH” has been corrected (Bug 7, page ECWB-10). Yet I might pass along another SJM3 admonition about this code: it will work for the packing of six characters, but not four. As I refuse to study the "CONCAT” usage now, we will have to take his word for it. But over the telephone on Friday, I confidently assured Stoney that this was an inconsequential detail since the EMTP never did any 4-character packing anway. Well, not quite! A search of "SUBR31" reveals four-character usage in several places, which I here list for completeness: M29. 2694 CALL PACKCH ( BUSVEC(3), HEADL(1), MMi, M13, MMT ) M28.675154224 CALL PACKCH ( DATE1(1), DAYTIM(1), MMU, M1, MM2 ) 29.2697 CALL PACKCH ( BLANKA(1), DAYTIM(1), MM, MM9, MMT) 28.6753 CALL PACKCH ( TCLOCK(1), DAYTIM(1), MMU, M11, M2.) 29.2700 CALL PACKCH ( BLANKA(1), AUPPER(1), MMi, LONG1, MM1 ) So, if Stoney says that the present Burroughs *PACKCH” will not work for such cases with MMi = 4, then I would ask him to please make the generalization and forward me some photocopy of what he wants. As for Jose, he can expect some labeling on his batch-mode EMIP plots to be erroneous, I guess (sorry)! My own inclination would be to discard all existing CONCAT usage, and resort to the simpler, higher-level ENCODE (Burroughs WRITE to memory)! The EMTP does so little character packing anway that differences of efficiency are not worth even considering (Stoney did say that CONCAT is an efficient way). The correction to "RUNTYM" (Bug 8, page ECWB-10) has been made independently, without confirmation from Stoney. But it is trivial: ‘SUBMOD SUBROUTINE RUNTYM ( D1, D2 ) Di = TIME(2) / 60. D2 = TIME(3) / 60. RETURN END Before we had "#60." rather than "/60.", which was hardly the proper conversion from sixtieths of a second to seconds. A final change to Burroughs modules was suggested by Stoney late Friday. Although I have not yet taken the time to understand why, Stoney assures me that the dimensioning of TEXTB should be increased from three to eight. As proof that I did this correctly, I reproduce the following: ALPHANUMERIC —TEXT1(1), BLANK, TEXTA(30), TEXTB(8) G@) SEGMENTED EMTP FOR PRIME 2 NEW IBM "VS FORTRAN" 7 Telephone conversations earlier today (September 28th) with our EMIP contacts Bob Newell (of Basin Electric in Bismarck, North Dakota) and Art Jahnke (of SandC Electric in Chicago, Illinois) have provided us with more invaluable information about other computer systems which is certainly of interest to others. A. Bob Newell's Progress Toward a Segmented EMTP Version for PRIME Bob called this morning to give me a verbal progress report on his feasibility study of EMTP segmentation for PRIME. Recall that Bob saw my demonstration of the VAX EMTP simulator when he was in Portland for the IEEE PES Summer Meeting, and he had most cooperatively promised to see if a comparable package were possible for hisMMeD-1e own PRIME 750 computer system (see the top of page IEEO-36, 17 July 1981). But he is very busy with manegerial responsibilities, and could not be sure when he would find the time to put anything down on paper. So, I am composing my understanding of our telephone conversation (which took about 45 minutes) for the benefit of others, to serve as a starting point. If Bob feels that this is in any way incomplete or erroneous, he is encouraged to correct it (I will pass any hard copy from him along ‘to EMTP memo readers at the earliest opportunity). First, let me mention that I was very pleasantly surprised by Bob's summary evaluation, which is that "there is no real technical problem" in producing a PRIME EMTP simulator. He had hoped to have the segmented PRIME EMTP running before he called me, Bob said, but that his time to work on the EMTP is severely limited by other obligations. Excellent news, anyway! Yet Bob emphasized that there are differences between what he is doing with PRIME and what I did using VAX/VMS, beginning with what happens when the computer crashes. Unless he took special precautions (which he can and will), it would be impossible for him to recover an EMTP simulation following a system crash. As Bob explained, the EMTP and its tables reside in the system paging pool, and this is reinitialized when PRIME is booted. No such complication exists for the VAX (at least not explicitely; more about this later), which pages directly from the user's area. The VAX has nothing equivalent to PRIME's front-end effort of loading the paging pool before EMTP execution can begin (Vol. IX EMTP Memoranda, 10 June 1979, middle of page USEC-8; Vol. X, 3 July 1980, page MSDO-12, Point NP3). If the PRIME EMTPSPY program were to send the EMIP out of the time-step loop (overlay 16) and into overlay 20 following a "SLEEP" command, some special table flushing should be easy. Control waits in installation-dependent module "KATALG" of overlay 20 anyway, soa little special table flushing should be no problem. Bob assures me that he does know which pages belong to the ENTP, and that such "saving of the EMIP paging pool" poses no ‘problem. Yet it remains an extra operation which we have not yet considered for the VAX EMIP simulator. But, if we users of the VAX EMIP simulator do not explicitely dump EMTP tables the way Bob's PRIME EMIP simulator will, a very real question arises as to whether our tables are in fact being saved! 0h, there is no problem with integrity of the data base if the user logs off the computer, or perhaps even if he just terminates execution of the EMTP (with a FORTRAN STOP). If the data base has any integrity at all, such normal terminations of EMIP execution must flush memory-resident pages, writing them out to the disk. My interpretation of the delay in exiting a program ("STOP" is not instantaneous; the VAX/VMS dollar sign does not appear immediately after "FORTRAN STOP" is written to the screen) is that such system wrapup is being accomplished. But what if execution is never terminated? The disk copy of the data base could not possibly always be current, for if it were, the segmented VAX EMTP would of necessity be writing to disk every time a FORTRAN variable was redefined. Clearly this is not happening (execution would be frightfully slow). So, I reason that there is a potential problem with VAX/VMS as well (we might have to be careful to especially flush memory pages onto disk, if we want to ensure the integrity of a check point against system crashes). But rather than being a serious problem, this business of page flushing is just a fine point which should not be forgotten by VAX EMIP simulator users. I asked Bob about event flags (the VAX EMIP simulator uses three, as I recall), which are convenient for synchronizing the solution and observation processes. For example, in the ROLLing mode, interactive plotting of EMTPSPY will put itself to sleep until the EMTP outputs another solution point (signaled for the VAX simulator using SYS$SETEF in "PLIFIL" in overlay 16, where event flag number 80 is set, as shown on page IEEO-31). Well, Bob said that older versions of the operating system were somewhat limited with respect to event flags, but that current ones are just fine. Very good. Although a seemingly minor point, such capability is crucial to ‘the interprocess synchronization of ROLLing plotting, nonterminal "SLEEP", etc.MMED-13 ‘The vehicle which Bob is exploiting to produce the effect of our VAX/VMS shared COMMON is "shared segments", in PRIME terminology. As I crudely understand it, PRIME allows the clever systems programmer to manually specify absolute addresses of COMMON blocks at link-editing time. Except that the "absolute addresses" must be in ‘the page pool (leading to the previously-discussed volatility), this sounds fully equivalent to what we do using VAX/VMS. ENTPSPY and each segment of the EMTP are simply linked with COMMON which is pinned down to the same location, thereby giving ‘the interprogram communication. This ensures a fully-endowed PRIME EMTP simulator. If Bob is sure about "shared segments", is sure that EMTP tables can be easily and efficiently transferred to and from the paging pool, and finally is sure that event flags are possible, then I agree with him that "there is no real technical problem". Whether Bob has actually completed all the work at this point appears to be nothing more than a detail (Bob's advice about system-level computer details is accepted here almost as gospel; I have never known him to be wrong about such things). Although I persist in using the term "segmented" EMIP, Bob seems to feel that "overlaying" is preferable ("after all, that is really what you are doing,” he said). Perhaps his perspective is a little different, being tied dow to the fixed addresses of his PRIME page pool (which must be overlaid). Anyway, I take note of his semantic observation. Perhaps after all feasibility studies are complete, we will take a vote of the different system experts, in an attempt to standardize the terminology. Regarding PRIME overlaying, Bob says that it is tricky ("not trivial” were his words), and is dependent on details of the operating system. The procedure which he is now exploiting works for both Rev. 17 (last year's software) and Rev. 18 (this year's), but he emphasizes that it is impossible to be sure that it will work for future PRIME releases. This would seem to be a point of continuing very mild anxiety, then, if not one of serious present concern. Anyone intending. to exploit the PRIME EMTP’ simulator should not forget this point, however (and maybe he could pass word of this concern along to the factory, perhaps via a user organization). Bob pointed out one important fringe benefit of EMTP segmentation for PRIME, namely a decrease in the burden on the system paging pool. Recall that as EMTP code expands (without any obvious upper limit this side of infinity), execution becomes an increasing system burden for PRIME. The same is apparently true for IBM if the program setup is not overlayed (this is why both GPU and AEP have overlayed, as carefully documented by Steve Seematter in Vol. IX, 10 June 1979, page USEC~7). Remember Tsu-huei's two minute delay in Taiwan while demonstrating the EMTP using a PRIME 550 last summer (Vol. X, 3 July 1980, page MSDO-12, Point NP3), as everyone waited for the EMIP to be copied into the page pool! Well, serious PRIME EMTP users avoid that front-end delay by maintaining the EMTP in the paging pool, so that the operational delay has been largely eliminated. But the EMTP remains a big load_on the page pool —- and this is a permanent burden, rather than a transient one! Even overlays of the program which most companies might never use (e.g., the "WEIGHTING" code of overlay 3) are part of this continuing burden in the case of an unsegnented PRIME EMTP. But not so with segmentation, Bob points out! If each UTPF overlay becomes a separate program (as with our VAX setup), then the PRIME page pool would only be burdened with one EMIP overlay at a time. Then overlays which would never be used will never be paid for (which is the happy situation for VAX/WMS always, segmented or not). Viewed from this perspective, I quite agree that "overlaying" is ‘the more appropriate term for PRIME. Indeed, ‘as each new PRIME EMTP overlay is called, the page pool would be filled with the EMTP code of that new overlay much as would be done for any non-virtual computer system (e.g., CDC) which overlays in the classic sense. As a result, the EMTP burden on the PRIME page pool can be dramatically reduced, though it is not clear whether it is desirable to segment as finely as along each UTPF overlay boundary. The only apparent disadvantage of the general idea of segmentation would seem to be that the paging pool can no longer be filled ahead of time (the burden will occur at execution time, spread throughout the Simulation as segment boundaries are traversed).MMED-14 I want to take this opportunity to thank Bob for his excellent work, and stress to others the importance of it. As the number two computer system within the power industry (second only to IBM), PRIME simply can not be ignored when it comes to EMTP Planning. Had Bob told us that a PRIME EMTP simulator would be impossible using existing system software, we at BPA probably would have stalled our exploitation of ‘the segmented architecture. Oh, the segmented VAX EMTP will exist and be used no matter what problems all other systems might have. But this is not equivalent at all to my speculation about "fully exploiting the possibilities of segmentation,” which implies that priorities and capabilities of the UTPF will be adjusted in favor of those aiming toward EMTP simulators. If this is unclear to the reader, I would have him re-read page IEEO-2 (Vol. XI, 17 July 1981). With a PRIME EMTP ‘simulator apparently assured, emphasis is clearly going to be given to segmentation. I never did hold out much hope for the mainframes, and they are not considered to be a very important factor in our decision anyway (though I do welcome any information on the subject for systems like IBM, Univac, Burroughs, etc.). The only remaining system which might dampen our enthusiasm for the exploitation of segmentation is SEL, as used at IREQ (Montreal) and LABORELEC (Belgium). I expect to hear from Mr. J. Verbinnen (LABORELEC'S SEL computer expert) on the subject in the near future. If his evaluation is as positive as Bob's, EMTP development will be irrevocably altered for the years ahead. B. Art Jahnke's Report of the Long-Awaited New IBM Compiler ("VS FORTRAN") SandC Electric in Chicago has long been our contact with the world of IBM DOS (little used by the American power industry, which prefers the bigger OS machines). Art Jahnke most competently sets up and maintains the IBM EMTP in this environment, ‘though a switch to DEC SYSTEM20 usage via’ a service bureau is now underway. If and when the transition is complete, Art will become our principal EMIP contact for DEC word machines (PDP-10, SYSTEN20). Meanwhile, he continues to be a useful source of information about IBM. Of importance to all IBM EMIP users is this long-awaited new FORTRAN compiler. According to Art's verbal description, this is called "VS FORTRAN" by IBM, and it appears to be the only FORTRAN software to be supported by the factory in the years ahead. Art confirms that OPEN/CLOSE statements for files are present, and this is a most important detail if ‘the IBM EMIP is ever to be fully developed in the installation-dependent sense (features like "REPLOT", "POSTPROCESS PLOT FILE"). Also present is the Burroughs equivalent of ENCODE/DECODE (which is the READ/WRITE construct of ANSI 77), which will permit us to avoid the present "BACKSPACE LUNITS” and "READ (LUNIT5, ...." construct. While such BACKSPACEing may involve no loss of execution efficiency (Mr. Frank Luizer, the GPU IBM systems-level whiz, assured. us that HASP merely backed up a pointer to a buffer), it has since run afoul of the "BLANK " construct of "CIMAGE". Mike Price discovered this the hard way during his "M28.+" IBM EMTP setup. Well, no more such trouble with the new IBM compiler. But. how many users will have it, and when? Is the DOS version which SandC now possesses identical to the OS version? More information is clearly needed. Art is merely the first IBM user to pass along details to us after confirming that he had possession of the new product. We welcome communication with other IBM users about what to do with the new software! C. Bob Newell's Universal Data Link for Communication among Different Machines Bob Newell has just reminded me of his important work on a communication link for small files (letters, EMTP data files, short listings) anong computer systems of different manufacture. We need something better than the mailing of magnetic tapes, which is particularly hazardous when national borders (even the Canadian/American one) are crossed. We also want instantaneous commmication, to be used in parallel PSR gp pm ga gm a hee elas tht ee ater agerMMED-14a without any obvious simple solution. Now Bob offers some hope, and it is perhaps appropriate to review the whole topic. I had hoped to pass Bob's information along as a short announcement for the Newsletter, but the October deadline has just been missed. Hence the present memo discussion will have to suffice. Magnetic tape continues to be the prefered medium for communicating significant volumes of computer information, and no one is seriously considering a replacement in the case of exchanges of the program itself (e.g., the 69000-card UTPF). Such massive communications are typically infrequent, and one simply tolerates the delay of the mail. No change here. But the exchange of EMIP data, or program modifications (using the universal UTPF-update corrections format), or electronic mail, are quite a different matter. ‘The transfer rate is typically unimportant, with 300 baud (30 characters/sec, which is conmon for acoustical couplers) being quite satisfactory. But how can we get ‘the BPA VAX and the Basin Electric PRIME computers to talk to each other reliably at that rate? This is the problem. When we first acquired our VAX (February, 1979), and I saw that DEC distributed all revisions to system software on flexible (floppy) disks, I had for a short time held the delusion that a convenient compromise might be at hand. But Ihave since been told by several sources (including Ray Boale of Ontario Hydro) that physical integrity of floppy disks which are mailed can only be insured if they are wrapped 30 as to be nearly as bulky and inconvenient as a reel of tape. That is, a floppy might well sneak past Customs if it were just dropped in an envelope, but it might arrive hopeless bent, as well! There also is a problem in that floppy disk drives are not yet that common among the computers which we deal with. So, I have since abandoned such thoughts. Without doubt, a simple, reliable (with error checking) telephone connection between the two computers of interest would be best. In the past, however, this was a little bit like the weather (lots of talk and no action). Well, Bob Newell has reminded me of his work on just such a link which concerns PRIME and VAX. The PRIME end of this project is in Bismarck, where I understand the work "is about 90% done." The VAX end is in Denver at the Tri-State Generation and Transmission Association, with whom Basin has contact. It is my understanding that such software will be made available to others when it is completed. If and when we EMTP developers have it available, it should be substantially easier to work together, particularly across the Canadian/American border. This would be an important contribution to future EMTP development, and our hopes to work more closely with others. I might just note another interesting aspect of this story. Bob tells me that the Tri-State VAX is indeed a PTI PSS/E installation -—-- the first which I have heard of in North America (we did kmow about HIDRONOR in Argentina). In the past, compatibility with one's PSS/E neighbors (all of whom used PRIME) seemed to be the dominant consideration for anew PSS/E customer. But just how important is such uniformity, anyway, once a VAX-PRIME link exists? It will be interesting to see. Even the PTI preoccupation with minicomputers may be ending, as Tom Varilek tells me of recent PII considerations aimed toward IBM. The available hardward options are multiplying rapidly, and only a quality universal telephone connection will be able to link everyone conveniently together. I applaud this timely project of Basin Electric, which is most relevant to EMIP development. VLADIMIR'S ERROR ANALYSIS OF EMTP OSCILLATIO! AMPING RESISTORS Reader's of the EMTP Newsletter will recall that Hermann recently mentioned the idea of possibly adding resistors in parallel with inductors so as to damp spurious mathematical oscillations. This was on page one of vol. 2. No. 1. Well. althoughMMED-15 Hermann mentioned Fernando's name, it is Vladimir who has volunteered a complete error analysis, which I pass along to memo readers in the remainder of this memo. As of September 28th, neither Hermann nor I had heard from Fernando. Vladimir: oS < norandumTo DR. P. KUNDUR Date September 16, 1981 Senior Engineer ' System Controls and Transients vationorDept HB F19 File 91-21 DE Subject. Damping of Numerical Noise in_the EMTP Solution Introduction It has been known for some time that changes in the network model (eg, breaker opening) can introduce noise (time-step frequency oscillations) into the EMTP solution. In the majority of cases, this noise damps out quickly and does not cause any real problems. Occasionally, however, the oscillations persist and corrupt the solution. ‘This report describes a way of alleviating such problems and provides an analysis of errors introduced by the proposed remedy. General The network model is subjected to a number of changes during any realistic simulation. These changes result from: (a) switching action (opening or closing of breakers); and (b) variations in the operating point of nonlinear elements. Any. change in the structure of the EMTP network model should be followed by: (1) an appropriate modification of the nodal admittance matrix; and (2) recalculation of initial conditions for the next time step. Presently, however, only the admittance matrix is being updated in the program. The initial conditions are not being modified primarily due to the complexity of the required calculations. Consequently, the EMTP solution (more precisely some parts of it) can contain numerical noise. Normally, the resulting noise is damped out quickly and a valid solution is obtained. Occasionally, however, the oscillations persist and corrupt the solution. Such is the case with the calculation of voltage drop across a lumped inductor following an interruption of current flow through it (opening of an adjacent breaker).Calculation of ferivatives with the trapezoidal rule of 16 integration [2,3] can also generate numerical noise. This excellent integration technique is not well suited for the rather poorly conditioned numerical differentiation. The calculation of the voltage drop across an inductor is an example of the numerical evaluation of a derivative: VeL di a dat In some cases, the generated noise is being amplified by models of some other network elements, which eventually leads to numerical instability of the solution. This happened, for example, in a few cases involving Type 59 synchronous machines, as reported by some program users (Swedish State Power Board, Manitoba Hydro and Laborelec). Some noise can also be caused by the nonzero switch current at the instant of opening (a switeh opens when the current through it is within certain margins). 1] Proposed Remedy The search for a simple and an effective cure to the numerical noise problem has been on for some time. Different users came up with different solutions to their particular problems, but none of these solutions was of a general nature. Finally, a discussion during the recent EMTP Workshop led to the idea of adding resistance in parallel wjgh inductances to damp out the numerical oscillations (noise). [4] To evaluate the proposed remedy, consider first its physical meaning. An addition of a resistance in parallel with an inductance is equivalent to replacing a constant lossless element by a lossy frequency dependent one, shown schematically in Figure 1 : L@) 2,@) => —Ww— L Figure 1: Schematic Representation of a Parallel RL Connection. The resistive and the imaginary (reactive) part of the equivalent element are described by the following equations: wt? Rw) = 5 2 2 Rot+woL Ey and 2, xy(w) = wt (2b) R’ a?It is clear that the frequency response of the new element will \T differ from that of a pure inductance. The error will increase with frequency and decrease with an increasing value of the parallel resistance R. On one hand, it would, therefore, appear desirable to use as large a parallel resistor as possible to reduce the response error. On the other hand, however, the damping effect (measured by the Ri(w)/Ly(w) ratio) decreases with an increase in the size of the resistor R. Error Analysis As explained above, the choice of the size of the damping resistor R has to be based upon the following two criteria: (a) introduced error in the frequency response; and (b) effectiveness of the damping of the numerical noise. A strict analysis of errors in the ENTP representation of lumped inductances* (with and without the paralleling resistor) and of lumped capacitances is performed in this section. The choice of the time step t for a particular study is based upon the frequency range of phenomena under investigation. Consider, for example, an ENTP study with a time step of 100°. ‘Theoretically, the maximum frequency reproduceable in this study is: Z fnax * 2a = 5000 Hz (3) Practically, however, the fequency must be even lower to be reproduced correctly: fp < 2000 az . (3a) ie, there is a need for at least five samples per cycle. Consequently, the error analysis will be performed only for the limited, practical frequency range. The obtained results are, however, general in their nature. The nature of the EMTP models of lumped L and C elements is not generally well understood. Consider first the time step loop representation of a lumped inductance L. An analysis performed in {5] has shown that the discretization of the appropriate differential equation results in a frequency dependent inductance model. The frequency characteristic of this element is given by the following expression: 2y(w) = iwi 2. tan (ARE) “) * Deviation from ideal inductance and capacitance models.MMED-18 The inductance model described by Equation (4) introduces only a magnitude error and no phase error. The EMTP equivalent of a parallel RL connection, on the other hand, does introduce both a magnitude and a phase error. The input impedance of the new element is described by the following expression: Zap (w) = Rap (w) + 3 Xpy(w) (5) where: Ray (W) = ie (6a) Ro4aE : and Hp, Xpy(¥) = wa? (6b) Consequently, the introduced phase error is equal to: R (7) L 7 TT é = 3 - arctg ( and its variation with frequency is shown in Figure 2. A comparison of errors in the magnitudes of impedances defined by Equations (4) and (5) is shown in Figure 3, BLO 1SL/O4 PHASE ERROR (9) ve 1000 2000 FREQUENCY CHZ) Figure 2: Variation of Phase Error with PrequencyERROR (%) eo v 1000 2000 FREQUENCY CHZ) Figure 3: Magnitude Errors in the Time Step Loop Analysis of Figures 2 and 3 leads to the following observations: (a) the phase error decreases with an increase in the size of the resistor R; and (b) the magnitude error increases with an increase in the size of the resistor R. In the limit (R= ), the error reaches that of the EMTP lumped inductance model (Equation 4). The presence of the parallel resistor R introduces also an error into the steady state (phasor) solution which uses an exact inductance representation. The resulting phase error is only slightly smaller than that shown in Figure 2. The magnitude error, on the other hand, is signficantly smaller (approximately 10 times at 2000 Hz) than that shown in Figure 3. At low frequencies, the time step loop and the phasor solution representations exhibit practically identical phase and magnitude errors. Another important aspect of network modelling considered in this section is the resonant frequency of a simple LC circuit shown in Figure 4. Lb Figure 4: Test System Diagram The inductance L remains constant while the capacitance C is being varied to change the resonant frequency from 0 Hz to p HZ.The resonant frequency of the EMTP model of the test system c O from Figure 4 is determined by both the inductance and the capacitance representation. It can be shown that a lumped, constant capacitance C is represented in the EMTP as a frequency dependent capacitance with following frequency characteristics. Tglw) = she. PAE. ctg ety (8) From Equations (4) and (8), it follows that an EMTP model of an LC circuit resonating at a frequency f1: fla TS (9) will resonate at a different frequency fgg defined by the following equation: fag 7 ar arctg (W£,,At) (ao) The addition of a resistor R in parallel with the EMTP inductance model changes the nature of the system's response which is described by the following equation: | 2 eee fe ee pr Bp = ONES” a2? Rb qa) we - &? (12) 2 wAt nce ae tg city (13) Equation (11) describes a damped resonant circuit, while Equations (8) and (10) describe undamped ones. The resonant frequency defined by Equation (11) is equal to: (14) while the damping ratio 3 ,[6] introduced into the system, is described by the following equation: =x My, E ow |. j- wy Aer? (Tf ae) as)The comparison of the resonant frequencies from Equations (10) 21 and (14) with the actual frequency defined by Equation (9) is shown in Pigure 5 and the damping ratio is shown in Pigure 6. ERROR (4) o “1000 2u90 RESONANT FREQUENCY CHZ) Figure 5: Resonant Frequency Error in the Time-Step Loop ~ BL/At 16L/At DAMPING RATIO S B 0 1000 zo00 RESONANT FREQUENCY CHZ) Figure 6: Frequency Dependence of the Damping Ratio Analysis of Figures 2 through 6 leads to the following observation: The introduction of the paralleling resistor R has both beneficial and detrimental effects on the EMTP solution. The beneficial effects of:MMED-22 (a) reduction of magnitude and resonant frequency errors; and (b) damping of numerical noise (high frequency spurious oscillations) are achieved at the expense of a phase error and a parasitic damping. Choice of the Resistor R The choice of the appropriate value of the paralleling resistor R is based upon the consideration of the effectiveness of noise damping and the amount of error introduced into the solution. While it was possible to perform the error analysis theoretically, the evaluation of the effectiveness of noise damping had to be based upon experimental results. A number of test cases had shown that no effective damping of noise caused by switching (network model modifications) is provided when: 72° (16) ‘max where: fmax is the maximum frequency defined in (3). It is worthwhile mentioning that an effective damping of noise caused by the evaluation of derivatives is provided with values of R larger than that defined above. From equation (16), it follows that the paralleling resistance R should not be larger than: * oT: Rnax 7 6 * 20 *£,2,.°L (7) Substitution of Equation (3) into (17) yields the desired formula: T RL6+ EL (18) ‘The minimum size of the resistor can be determined, for example, from the phase error introduced into the steady-state solution. From Equations (2a) and (2b), it follows that the phase error is defined by the following expression: T B= 7 - arctg aae qs) ‘Ss’ where: Wgg is the steady-state frequency in rad/sec.Pe eas Equation (19) leads to the desired formula for the minimum size of the resistor R: ie R2 tg (B-A) « wech (20) Equations (18) and (20) define the practical range of values of the resistor R to be used with any time step t. The following limits will, for example, exist for a time step of 100 sec and a phase error of .2° at 60 Hz. 108000.L¢ R <188500.L (21) Application of Damping Resistors to Coupled Circuits The analysis, presented above, has been performed for a single inductor L only. The developed relationships are, however, directly applicable to coupled inductances (transformers, circuits) as long as every inductive branch is paralleled by an appropriate resistor. The R/L ratio has to be maintained constant for all branches in any coupled circuit. Every inductance is then subjected to an identical modification whose effects have been discussed in the previous section. A few words of caution about possible problems related to the use of damping resistors with the nearly singular impedance matrix representation of transformers are called for. First of all, the normal field width used in the EMTP for resistance specification is not adequate. It is, therefore, advisable to use either the "free format" option or the alternate high precision format[1] when specifying the damping resistors for coupled inductive elements. Even then, some additional problems can be caused by the precision of inversion of the resistive damping matrix. It may, therefore, be wise to use the double precision version of the program when applying the damping resistors across the impedance matrix representation of transformers. Conclusions A systematic error analysis of EMTP's models of lumped inductances and capacitances has been presented. The same error analysis has been extended to the evaluation of the proposed remedy for numerical noise problems in the time step loop. The results of the error analysis were used to establish guidelines for the choice of the damping resistor. . References [1] EMTP Rule Book, Bonneville Power Administration, Portland, Oregon, Sep. 1980. [21 C.W. Gear, 'The Automatic Integration of Stiff Ordinary Differential Equations’, Proceedings IFIPS Conference, Edinburgh, 1968.MMED-24 [3] H.W. Dommel, "Digital Computer Solutions of Electromagnetic Transients in Single and Multiphase Networks', IEEE Trans. Power App. and Syst., vol. PAS-88, April 1969, pp. 388-399. [4] A note from the editor, EMTP Newsletter, vol. 2, No. S, dune 1981, p. 16. [5] V. Brandwajn, 'Synchronous Generator Models for the Analysis of Electromagnetic Transients', Ph.D. Thesis written at the University of B.C., Vancouver, B.C., 1977, PP. 30-36. [6] J.L. Melsa and D.G. Schultz, ‘Linear Control Systems', McGraw-Hill, New York, 1969, pp, 153-154. C rcondl Dr. V. Brandwajn System Design ans System Controls and Transients ENTP NEWS HEADLINES TO FILL OUT THIS FINAL PAGE \H1, As the above article continues to demonstrate, Vladimir has been highly .cooperative in documenting his EMTP progress, and passing it along to Bonneville and the rest of the EMTP user community. I would encourage others to do likewise. Both ‘the EMTP Newsletter and EMTP Memoranda are available forums for the dissemination of EMTP-related information. H2. Jose left Portland on September 29th, after completing Phase I of his three-phase contract with us (page MSPR-3, 5 August 1981). The new Marti frequency dependent transmission line modeling may not yet be done, but it is available for production use. Tsu-huei has authored a page and a half description for the next Newsletter, and a detailed illustration will follow in a forthcoming Memorandum. Jose will be treating theoretical aspects in a later Newsletter article. H3. Dr. John Vithayathil of BPA has been instrumental in arranging a $125000, 3-4 ‘year contract with Hermann for the development of an "EMTP Theory Book", plus extended research into a rigorous EMIP representation for cables. We should be able to prevail on either John V or Hermann to summarize this most important development for the next (January?) issue of the Newsletter. H4. Daniel (Prof. Daniel Van Donmelen of Katholieke Universiteit Leuven, in Heverlee, Belgium) has scheduled a superb all-European EMIP meeting at LABORELEC (outside of Bruxelles) on October 23rd. We will show more later, and I encourage Daniel to submit his own minutes of the meeting for Memorandum and/or Newsletter publication. A model for EMIP educational activity is unfolding on the continent! W. ded Meyer DD QToebherv 1994