illia civ quarterl 395 univ

8/12/2019 Illia Civ Quarterl 395 Univ

1/52


2/52

LIBRARY OF THEUNIVERSITY OF ILLINOISAT URBANA-CHAMPAICN

1JLUTOop.^.


3/52

The person charging this material is re-sponsible for its return to the library fromwhich it was withdrawn on or before theLatest Date stamped below.

Theft, mutilation, and underlining of booksare reasons for disciplinary action and mayresult in dismissal from the University.

UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGNOct ' wflSEP' 15^'

L161 O-1096


4/52

Digitized by the Internet Archivein 2013

http://archive.org/details/illiacivquarterl395univ


5/52

v> T )7l^jUci^ .Report No. 395 JUN 1 2 1970

ILLIAC IVQUARTERLY PROGRESS REPORT

January, February, and March 1970

Contract No.USAF 30(602) -kikkILLIAC IV Document No. 208

DEPARTMENT OF COMPUTER SCIENCEUNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN URBANA, ILLINOIS


6/52


7/52

ILLIAC IVQUARTERLY PROGRESS REPORT

January, February, and March 1970

Contract No.USAF 30(602) -4144

Department of Computer ScienceUniversity of Illinois at Urbana-Champaign

Urbana, Illinois61801

April 15, 1970

This work was supported in part by the Department of Computer Science,University of Illinois at Urbana-Champaign, Urbana, Illinois, and inpart by the Advanced Research Projects Agency as administered by theRome Air Development Center, under Contract No. USAF 30 (602) -klkk


8/52


9/52

TABLE OF CONTENTSPage

REPORT SUMMARY 11. HARDWARE 3

1.1 Logic Simulation and Diagnostics 31.1.1 Logic Simulation 31.1.1.1 PE Simulator 31.1.1.2 CU Simulator System 31.1.2 Card Test Generation 4

1.1.2.1 Card Test Generation System 41.1.2.2 Card Test Translation System 41.1.2.3 Generation of PE Card Tests 51.1.2.4 Generation of CU Card Tests 51.1.3 PE Diagnostics 61.1.3.1 Path Test Generation 61.1.3.2 Combinational Test Generation . . 61.1.3.3 Control Logic Test Generation 71.1.3.4 Functional Test Generation 71.1.4 PEX Control Computer and Supervisor System 8

2. SOFTWARE 92.1 Operating System 9

2.1.1 Operating System I 92.1.2 Operating System II 10

2.2 Compilers and Translators 102.2.1 GLYPNIR 102.2.2 FORTRAN 112.2.3 TRANQUIL 11

2.3 Assembler 122.4 Utilities 122.5 Interactive Communications and Graphics 132.6 B5500 Operation 14

3. APPLICATIONS 153.1 Numerical Analysis 15

3.1.1 Numerical Solution of Problems in Hydrodynamics. . . 153.1.2 Eigenvalues 16

3.1.2.1 Matrix Storage Methods 163.1.2.1.1 Matrix Storage for

Jacobi's Method 163.1.2.1.2 Matrix Storage for

QR-Algorithm 163.2 Linear Programming 193.3 Long Codes 193.4 Large-Scale Planning 213.5 Meteorology 22


10/52


11/52

Page3.6 Signal Processing 223.7 ILLIAC IV Education 2k

3.7-1 FOUKUM 2k3.7-2 Doclamentat ion 25

k. ADMINISTRATION 26k.l Administration and Services 26

REFERENCES AND DOCUMENTS 28


12/52


13/52

REPORT SUMMARY

The prototype processing element (PE) has been completelydebugged and as a result five circuit card types have been re-designedto operate properly. In addition, three circuit card types have beenre-designed in an attempt to increase the operating speed of the PE.Production diagnostics for printed circuit cards continue to be deliveredto Burroughs from the University of Illinois.

Production PE's are being held up because of quality controlproblems with externally manufactured printed circuit cards

The PEX Control Computer (PDP-9) was delivered and installedat Burroughs in February but has not been used due to the delays in theproduction PE ' s

As a result of the January 7 meeting (composed of Softwarepersonnel and future ILLIAC IV users) held in Chicago to study programminglanguages for ILLIAC IV, it was decided to shelve TRANQUIL and commencea study of FORTRAN extensions for ILLIAC IV. GLYPNIR and ASK continueto be refined.

The problem of providing utility programs in needed areas isreceiving considerable attention.

A simulation of the proposed Operating System II indicatedthat it would contribute to a more efficient use of system resourcesthan Operating System I.

Specifications for graphics equipment were written anddistributed to vendors. Data-communication hardware requirements wereinvestigated.

The ILLIAC IV Users Group, FOURUM, will become the main vehiclefor disseminating information to potential ILLIAC users.

Project expenditures through February 1970 are as followsBurroughs Corporation $21.8 millionUniversity of Illinois $ k.h million


14/52

There are currently 127 people on the ILLIAC IV Staff.The construction of the Center for Advanced Computation Building isprogressing according to schedule.

-2-


15/52

1. HARDWARE

1.1 Logic Simulation and Diagnostics

1.1.1 Logic Simulation

1.1.1.1 PE SimulatorThe PE Simulator was used heavily this period for verification

of functional tests (e.g., divide and multiply operations) and verifica-tion of the combinational tests.

Debugging of the PE was successfully completed, and theassistance of the PE Simulator contributed towards having error-freetests to run on the PE Exerciser.

A few minor errors, due to the logical design, were found andremoved from the PE Simulator.

1.1.1.2 CU Simulator SystemThe CU/PE Card Simulator Programs were modified to facilitate

the generation and compilation of the good and bad board simulatorsautomatically. In addition, several programs of the system were subjectedto various modifications to facilitate correct simulation of all the cardsgenerated to date.

Work on the CU Section Simulator continued. If a simulatorfor a section of the Control Unit is generated by simply combining theappropriate card simulators, its inefficiency is apparent because theconnections among the cards in a section are so complex that each cardmust be simulated many times. To avoid this inefficiency, it was decidedto reduce the complexity of the connections by partitioning each cardsimulator into two or three parts. Since three partitioning algorithmswere devised, the effectiveness of each was compared by applying it to

-3-


16/52

the TMU section [1]. According to the results, the simplest algorithmwas adopted and the programming of the section simulator generator hasbeen started.

Wherever necessary the card simulator generator programs havebeen rewritten to suit the requirements of the section simulator; thisparticularly applies to the programs which sort by signal names andpackage locations (WEDTR1 and WEDTR2). The WEDTR1 program accepts thebackplane wiring and produces an additional error listing file which canbe examined to correct for I/O connections. The WEDTR2 program takesinto account the partitioning of the cards

All the cards in the TMU section were partitioned (incorporat-ing corrections to the netlist wherever necessary) and trial runs weremade on the new section simulator generator.

1.1.2 Card Test Generation

1.1.2.1 Card Test Generation SystemDuring the quarter this system was fully debugged and some

features to enable more flexible use were added. It is presently beingused on a production basis to generate diagnostics for PE and CU cards.

1.1.2.2 Card Test Translation SystemThe test translation system consists of two programs which

translate failure and pattern input information into test dictionariesfor each CU and PE card. The test translation programs, calledCUFAIL/XREF and PEFAIL/XREF, produce a cross-reference listing for inputand output patterns and failure modes. For each test, the initial flip-flop settings are listed, the applied test pattern is given, the numberof clocks applied is indicated, and each output pin has associated withit the particular failures causing that output to differ from thecorrect value, that value being the output with no failures. A secondlisting is given of those tests which detect each failure mode. A third

h-


17/52

listing is given of the equivalent failures on each card. The majordifference between the two programs is that the formats of the CU carddictionary must be much more compact, due to a larger number of testsand failure modes

These dictionaries represent the primary tool of findingfailures on PE cards and CU cards , and in interpreting the results ofthe TI 561 System, which exercises the PE cards, and the PEX System,which will exercise the CU cards. Twelve dictionaries have successfullybeen run for CU cards and sixteen dictionaries for PE cards

The system for automatically generating code for the TI 561tester for PE cards has been improved and has been used on a productionbasis for sixteen PE card types . A program for automatic generation ofPEXTAP code for testing CU cards is under development, but is not yetoperational.

1.1.2.3 Generation of PE Card TestsAll but one of the thirty-eight PE board types have had

diagnostics completed or are presently waiting for Engineering ChangeNotes (ECN's) from Burroughs. The diagnostics detect all possible singlefailures on these boards. Sixteen boards have had code for the TI 561tester and test dictionaries generated and forwarded to Burroughs. Eightboards are waiting for ECN's and thirteen boards are waiting for TI 561code generation.

Of the seven MLU boards, six have had diagnostics completedand are awaiting TI 561 code generation. One board requires completionof diagnostics.

1.1.2.4 Generation of CU Card TestsTwelve CU boards have had diagnostics completed. These

diagnostics detect between 98 per cent and 100 per cent of potentialsingle failures on the board. On several of these boards the diagnosticsindicate probable areas of redundant logic design by Burroughs. Testdictionaries have been run on these cards and are being forwarded toBurroughs

-5-


18/52

1.1.3 PE Diagnostics

1.1.3.1 Path Test GenerationDetection and location phase path tests were released to

Burroughs at the beginning of this period. A demonstration of the failurelocation capability by temporary insertion of failures was successful.Evaluation of the usefulness of these tests for the PE off-line diagnosiswill be made during the PE production process.

1.1.3.2 Combinational Test GenerationCombinational test generation began in earnest this quarter.

The Combinational Test Generator (CTG) and PEXTAP Input Generator (PIG)programs were modified slightly to reflect changes elsewhere in thesystem. Several tests associated with the barrel switch (BSW) weregenerated and delivered to Burroughs. First attempts at other tests werehalted at the PEXTAP assembler due to the number of data patterns exceed-ing the length declared in assembler arrays , thus making it necessary tosplit tests into varying numbers of subtests.

At the present time, tests have been completed for the multiplierdecoder gates (MDG) and carry propagate adder (CPA) , in addition to thebarrel switch. Some subtests of the address adder (ADA) are complete.The remaining ADA tests and multiplicand select gates (MSG) tests are nearcompletion.

Source language and compiled versions of the circuit analysisprograms, ECAP and CIRCUS, were received. These are to be used as an aidin circuit failure analysis. Results from a sample circuit used as a teston CIRCUS did not compare closely with the results in the manual. Thesource language file requires a special program to transfer properly fromtape to disk.

-6-


19/52

1.1.3.3 Control Logic Test GenerationThe test generation for the PE control logic, consisting of

seven subsystem programs, has progressed in this quarter, emphasis beingplaced on the modification and completion of the last two programs.

The main functions of the equation transformation program, oneof the two programs, is finding conflicts, value assignment and sneakpath checking. It produces the test patterns for the control logic.There are 111 Boolean equations for the control logic. These 111 equa-tions are transformed into about 1800 arc descriptions by the equationtransformation program. These 1800 arc descriptions are divided up intofour groups of arc descriptions and fed into the PGM program in fourruns . The four outputs of PGM consist of h6h paths and are combined andrearranged. The rearranged PGM paths are fed into the test generationprogram to produce the test patterns for the control logic. The docu-mentation of the algorithm of conflict finding and sneak path checkingis under preparation.

1.1. 3.1* Functional Test GenerationUniversity of Illinois personnel verified Burroughs' functional

tests using the PE simulator. In the intermediate stage of verificationof the functional tests , simulation outputs were sent back to BurroughsUniversity of Illinois personnel also assisted in analyzing errors andevaluating the tests.

The University personnel received the final version of thefunctional tests from Burroughs in the middle of the quarter and hadverified about seventy per cent of them by the end of the quarter.

Further verification and evaluation will be continued duringthe next period.

7-


20/52

1.1.4 PEX Control Computer and Supervisor SystemThe PDP-9/L computer was installed in Paoli during February.

After several wiring mistakes in the PEX were corrected, tests and resultscould be transmitted between the PEX and the PDP-9- Several minor bugswere discovered: (l) the University had assumed that the Clear TestNumber signal would also clear the PE Error indicator; this was not true,and some minor PEX rewiring was necessary, (2) the PEX frequentlyacknowledged receipt of a signal when it had not actually begun to actupon it; the PDP-9 promptly removed the signal upon receiving theacknowledgment and the action was never carried out; (3) the PEX couldnot operate properly with the PDP-9 using the REPEAT/COMPARE/HALTinstructionafter an error halt it was impossible to start the nexttest without clearing the PEX, but that wculd destroy the comparison datashowing which bits had been in error before this data could be read intothe PDP-9 and printed. A minor bug in the supervisory system softwarewas also discovered and corrected.

This system was installed in PEX #1, since PEX #2 was beingused to debug the prototype PE. Due to the delays in completion of theproduction PE's, the system has not yet been used.

-8-


21/52

2. SOFTWARE

2.1 Operating System

2.1.1 Operating System IThe Creeper module tises execution lists generated by the Job

Parser to call system modules needed by the job. The Operator modulehandles SPO commands controlling job execution and performs system book-keeping for each job. These two modules have been coded and simulationof a system with dummy slave modules has been accomplished to debug thecontrolling functions of these two central modules. The Disk Manager,which handles queueing of disk allocation requests, has been coded anddebugged. The Data Processor, which effects transfer of files from theB65OO disk to the ILLIAC disk, has been coded, including preliminarydata conversion routines, and debugging is in progress. The Collectorand Loader, previously written and debugged, have been incorporated intothe system. The functions of the Execution Monitor have been specifiedin close connection with the Job Partner and Hardware Sub-System (HSS).Coding of this last module has begun.

Coding of the Job Partner has begun now that the HardwareSub-System intrinsics have been specified. Likewise, the macro assemblerhas made possible the preliminary specification of the OSU I/O andutility requests; OSl+ itself is nearing completion.

The HSS provides the means to initiate I/O and control theILLIAC IV quadrant. Three modules of one operating system use HSS in theperformance of their duties: the Execution Monitor, the Job Partner, andthe Data Processor. HSS consists of a set of intrinsics imbedded intothe B65OO MCP and some ALGOL code which must be compiled into the programsusing HSS.

The following parts of HSS have been coded: Generation of ILLIAC IV I/O descriptors; Allocation of BIOM space

-9-


22/52

Modifications to the ALGOL compiler to allowinvocation of the HSS intrinsics;

A procedure to handle ILLIAC IV interruptsThe following parts of HSS are being written:

Error analysis including Transient ErrorCounters

Operator communication using the SPO (insteadof DataCom as planned);

List I/O using the list feature of the CDC(the list feature has not been implementedinto hardware in the way it was described,thereby complicating its use);

Generation of the scan out command to initiatethe I/O.

2.1.2 Operating System IILess effort was spent last quarter on Operating System II (OSIl)

than in the previous quarter (two key personnel were diverted to otheractivities); however, activity continued in:

Further design and description of the exten-sions required in the FORTRAN language tosupport OSII;

Study of the B65OO FORTRAN and ALGOL compilersand the B65OO MCP in preparation for makingmodifications

Study of means to integrate OSI and OSII intoa composite whole.

2.2 Compilers and Translators

2.2.1 GLYPNIRGLYPNIR now allows simple vectors and generalized pointer index-

ing. Work is progressing on I/O statements and better routing constructs.The writing of a GLYPNIR users manual and macro generator is progressingsatisfactorily

-10-


23/52

2.2.2 FORTRANIn mid-February, a four man design team was formed to design

the syntax and ILLIAC IV code specification for an extended version ofFORTRAN. The design group is operating under two general premises inthis design. The resulting language should be:

as close to FORTRAN in syntax as possible,including standard FORTRAN IV (ASA) as asubset;

simple enough to produce predictably efficientILLIAC IV code.

Discussions were held with Burroughs about implementation ofthe design. Tentative arrangements for compiler implementation to beperformed by Burroughs personnel at Paoli have been made.

The syntax design and detailed code specification are expectedto be completed by the beginning of June. During the design phase usersphysically located at the University of Illinois will be consulted aboutthe desirability of the syntax and proposed implementation. It isproposed that during June as many as possible of all potential users begiven presentations on the language. The presentations will include handgeneration of FORTRAN code for user selected sections of their proposedapplications

2.2.3 TRANQUILEvaluation and review of the TRANQUIL language and compiler

continued during the first quarter of 1970. The cumulative evaluationof those within the project was presented to a group of nationallyrenowned software experts and future ILLIAC IV users on January 7th.The opinions of these experts were gathered both verbally at the reviewmeeting in Chicago and from letters received subsequent to the meeting.

The opinions of these experts , together with an overall reviewof the project's aims and directions, led project management to concludethat the goals of the project would be better served by abandoningthe TRANQUIL effort in favor of a fresh start on a FORTRAN language

-11-


24/52

especially extended for ILLIAC IV. Even though work on the TRANQUILproject ended on January 31, it is felt the experience gained by thepersonnel involved will prove invaluable on the FORTRAN effort.

2.3 AssemblerASK was extended this quarter to include macros and conditional

assembly features.The macros have two noteworthy features

1) They are text-substitution macros rather thanmacro instructions

2) The programmer structures the calling line inthe definition of the macro.

ExampleDEFINE TO &ADR; = -@@-l+@ADR; ##SKIP , TO LOOPSTART

The conditional features also deal with text and not statements,expressions, or any other syntactic entity.

Example&IF P &THEN ADRN &ELSE SBRN &FI *X(2);

2.U UtilitiesWork is continuing on the peripheral conversion programs . The

file security and machine use accounting systems are being studied anddefined. ILLIAC IV FORTRAN intrinsic routines are being drafted andtested. Considerable thought has been given to the debugging facilities,although they have not been defined; work has commenced on an arithmeticscratch pad which will be part of the debugging system. Graphic displaysoftware is being discussed with the graphics and data communicationgroup.

The instrumentation programs (to measure program performance)have been given a low priority due to the aforementioned projects.

-12-


25/52

2.5 Interactive Communications and GraphicsDuring the quarter, further investigations of commercial firms

who supply both computer output microfilm recording systems and inter-active graphics display terminal systems were conducted. On the basisof the investigations, formal bid specifications were written and thebids for the microfilm system were sent out. The bids for an interactivegraphics terminal system will be sent out in the next quarterin time toallow a final decision on both sets of equipment by the end of May.

Expected delivery is December 1, 1970 for microfilm andJanuary 1, 1971 for the interactive graphics terminal. The basic quali-fications of the microfilm recorder system are as follows:

Very high quality precision Cathode Ray Tube(CRT) system displaying points, vectors, andcharacters. Not less than one thousand(1,000) lines/inch resolution on CRT deviceand 96 characters in character generator;

Film transport system for both 16 and 35 mmfilms

Internal digital computer to allow highlyflexible design of recording system software.

There are two versions of the interactive graphics displayterminal in the bid proposals: l) a minimal capability system and2) an augmented capability system. The minimal version consists of:

High quality CRT display system with points,vectors and characters

Internal digital computer to allow highlyflexible design of graphics terminal software;

Various manual input devices such as keyboard,lightpen, data tablet; Directly generated display images from corememory data list.

The augmented capability display terminal consists of the same require-ments as the minimal display terminal system with the addition of:

An interpretive display image technique by whicha data structure contained in the terminalcomputer memory is interpreted during display,

-13-


26/52

thus allowing highly flexible arrangementbetween display data, the problem it isassociated with, and necessary interactivecapabilities required for the solution ofthe problem;

Two-dimensional images derived from three-dimensional data. Either true perspectiveor orthogonal projection will be the methodused (selected by the bidder).

In order to coordinate the development of graphics devices andutilities and interface them to the remainder of the system, a new servicegroup was formed during the quarter encompassing all data communicationsand graphics utilities. The data communications group will develop theproposed data communications network, interface the ILLIAC IV system tothe ARPA network, and develop and maintain the basic graphics utilitiessoftware packages to be developed.

2.6 B5500 OperationNo. of ProcessJobs PIours

2l+,233 203.8123,573 168.0625,061 197.52

JanuaryFebruaryMarch

Machine use has been heavy and steady. The system has beenoperating three shifts a day, seven days a week.

In February, one processor and two tape units were removed.Diagnostics has been somewhat hampered by the removal of the processor;the Diagnostics Group has been using a great deal of machine time andwill continue to use even more as ILLIAC IV nears completion.

Batch processing is receiving good turnaround time.

- k-


27/52

3. APPLICATIONS

3-1 Numerical Analysis

3.1.1 Numerical Solution of Problems in HydrodynamicsThe capabilities of the ILLIAC IV render it highly suitable for

the solution of hydrodynamic problems in three dimensional space. Ofparticular interest is the study of flows for both intermediate and largeReynolds numbers. The co-ordinate system in which the problem is formu-lated is greatly influenced by the geometric and physical boundaryconditions of the actual problem and by computational feasibility.

The set of quasi-linear partial differential equations govern-ing the flow can be solved by finite difference techniques with appropriateboundary constraints depending on the nature of the physical problem andits particular geometry. Of singular importance in the solution of theflow problem governed by the partial differential equation system is theutilization of finite difference representations which are both stableand converge to the true solution of the physical problem. With the aimof solving the Navier-Stokes equations for the flow over cylindrical andspherical bodies, the following finite difference schemes were analyzedwith regard to stability using the Von-Neumann analysis

Brailovskaya two step scheme; Cheng-Allen two step scheme; Dufort-Frankel and leap frog scheme.

These finite difference schemes, along with the Crank-Nicholson scheme,are undergoing numerical experimentation with Burger's equation

2du du _ _1_ (3 uat u ax = Re 3x2

Re = Reynolds number; u = flow velocity

to determine the most suitable scheme possessing the best propertiesof stability, rate of convergence, and tolerance to different initial

-15-


28/52

and boundary conditions. Modifications of these and other schemes willbe considered. The optimum scheme is to be chosen for use with the fullNavier-Stokes equations for the calculation of the flow over cylindricaland spherical bodies.

3.1.2 Eigenvalues

3-1.2.1 Matrix Storage Methods

3.1.2.1.1 Matrix Storage for Jacobi's MethodThe modified Jacobi Method for finding eigenvalues of a symmetric

matrix has been coded in assembly language, ASK, and is now being debugged.One change was made in the program described last quarter [2].

Instead of making the matrix diagonally dominant, the w/2 superdiagonalelements, A[2I, 21+1] 1=0, 1, 2, ..., N/2 - 1 (N order of matrix), aresubjected to the test:

|A[2I, 21 + 1] I < 10 m ;where m is a power of two. This test is made at the beginning of eachelimination process. If the test fails, elimination is completed, other-wise, skip to the 2nd row, 2nd column, shuffle, and test the A[2I, 21+1]again. After N - 2 shuffles, the factor, m, for the above equationbecomes 2 x m. The advantage of this test over the original test is thatthe largest A[2I, 21+1] are eliminated first, thus achieving a fasterconvergence toward the eigenvalues.

ft p pFor m > 8, the usual test for convergence (i.e., \ < 10 E /DQ ,p Pwhere | = E /D taken from the present matrix) is executed and, ifsatisfactory, convergence is reached.

3-1.2.1.2 Matrix Storage for QR-AlgorithmThe modified QR method consists of two steps: l) reduction of

the original matrix to an upper Hessenberg form, and 2) the modified QRiterations which for an n x n matrix are as follows:


29/52

1) Computation of the first column of

r - (\ tik) J ) (\ - 4k) i) ^ k s n-lfor n odd, and

r = (\ - 5 |k) i) (\ - 4k) i) for n even. The matrices, A., are constructed by

A... = Q* A. Q., where A. = Q.R., i.e., A. . = R.Q.l-i-l 111 i l i' ' l+l i^ifor i = 1, 2, ...

where A. is the original matrix and R. and Q. are an upper triangularmatrix respectively.

2) Finding of a unitary matrix N, such that the first column ofN-. T is e_ .1 i

3) Reduction of E, A. N-, to an upper Hessenberg form by unitarytransformations according to whether N is odd or even. The original QR-algorithm calculates A p from A^ using

r '


30/52


31/52

where j_, j, , ..., J. are such that J is expressed by(J X K.J 2* Jk + ^ Jk-i + +2Ji + J

k+1and 2 is the number of PE's in the machine.

3.2 Linear ProgrammingDesign of the data preprocessor for the Linear Programming

System (LPS) was largely specified this quarter. This preprocessoroperates on input data already existing as B65OO files. Facilities forinputing the data (i.e., user specification and modification of LPmatrices), will be separate from the LPS solution package and will inter-face with it. Following input, the major preprocessing tasks on the dataare allocating rows to PE's, scaling the A-matrix, converting from B65OOto ILLIAC numeric representation, and formatting ILLIAC disk files. Dueto the quantity of input data and the amount of manipulation required forthe LP SETUP, most of this preprocessing will be done in the ILLIAC PE'srather than in the B65OO. The B65OO allocates rows to PE's and passes tothe ILLIAC disk an A-matrix file which is row, column, and PE sorted.The records of this file are in B65OO format and sized to interact wellwith the B65OO multiprocessing environment. The ILLIAC converts the datain this file to ILLIAC representation and re-formats the records to LPSsize and specifications. Row and column scaling factors are calculatedto equilibrate the A-matrix and to transform all upper bounds to a commonvalue. Final output from this preprocessor is a set of scaled data filesfor the PRIMAL solution routine.

3.3 Long CodesThe programs mentioned last quarter are essentially complete.

The primary program models the behavior of a discrete linear dynamicsystem of order ten or less. The user specifies the initial stateof the system by a vector, X(0). The program then produces a discretetime series of new states, X(l), X(2), ... , X(TMAX) , by theapplication of a series of transition matrices, $(l), $(2), ..., (TMAX).

-19-


32/52

The transition matrices, , are assumed to be non-derogatory matrices ,that is, we assume that no two sub-blocks of the Jordan canonical form of$ contain the same eigenvalue. This requirement must be met if $ is to betransformed into the companion matrix form:

-

,

Y

The search for a relation between this requirement and the commonly con-sidered system properties of identifi ability and observability wasrewarded by the development of a proof which guarantees that the matrix,, is non-derogatory if the system is identifiable , that is, if the matrix

I I II.2 ri/_x i i .n-1 ,B def X(0) | $ X(0) of X(0) 1 ... I $n_1 X(0)I I *

illia civ quarterl 395 univ

Documents