DEPI(ID:2326/dep002)Continuous simulation languagefor Differential Equation Pseudo Interpreter Henry Lesh, Nasa Jet Propulsion Lab, 1957 (On a Burroughs 204) Early continuous simulation language; highly declarative - coded directly from flowcharts, (hence the "Pseudo") Places Hardware:
Related languages
Samples: References: Introduction One of the problems facing large computer installations today is the increasingly large ratio between problem preparation time and problem solution time. Sometimes weeks or even months may elapse between the time a problem is first presented to a programmer and the time the first production occurs. Many methods have been tried for simplifying this presentation. Compilers, formula translators, and interpretive routines have been written and tested on a wide range of problems and some of them are quite effective. In the field of differential equations, the preparation of a problem for solution on an electronic analog computer is frequently much easier than the preparation of the same problem for solution on a digital computer. For this reason there has been some work done to simulate analog computers on digital computers. Selfridge has done much of the introductory work along these lines. The system described here is an extension of Selfridge's work in that it uses a more powerful integration scheme (Runge-Kutta) and a different method of problem presentation. The routine described in this paper called DEPI, for Differential Equations Pseudo-code Interpreter, was written to simulate a general-purpose analog computer on a digital computer in the hopes of combining the programming ease and program flexibility of the analog compater with the accuracy and reliability of the digital computer. In general, the plan was to simulate the operation of actual analog computers unless considerable simplification would result from the introduction of non-similarity. Extract: Control Word Structure Control Word Structure Programming for DEPI is done directly from a flow diagram, and consists of writing a sequence of control words on a coding sheet. The structure of the control words is shown in figure 2. Notice that each control word has a number which appears in its first three digits. The phi and theta in the integrator and amplifier control words stand for the numbers of two components whose outputs are multiplied together to form a single input. Each integrator and amplifier can have as many control words as desired. The total input is the sum of all the designated product pairs. The phi and theta of the divider control word indicate the component numbers of the numerator and denominator respectively. The theta's in the square-root generator, resolver, and function generator control words indicate the arguments of the operations and the U indicates whether a sine or cosine is desired. The theta in the function generator control word indicates the argument of the desired function. The Y is the address of a potentiometer which contains the relay switching constant, and the 0 is the address of the input variable. The s in the output listing routine control word designates the number of digits to be ignored at the left end of a number to be listed. The b gives the number of digits to be printed before the decimal point and a the number after. The 0 indicates the component number of the variable to be listed. This control word can be either positive or negative. If it is positive the sign of the variable is listed, but if it is negative, the sign is suppressed. Extract: Programming and Coding for DEPI Programming and Coding for DEPI A simple comparison between analog and DEPI programming is shown on figure 4. Notice that because of the ease with which multiplication and division can be performed on a digital computer, the DEPI program contains only half as many components as the corresponding analog program. The input pairs to integrator 000 in the DEPI program specify that its input will be the square of the output of integrator 001 plus the output of divider 050 times constant number 100. The translation of the program into a code is quite simple. Integrator 000 has two control words since it has two input pairs. The first of these expresses the prodt~ct of the output of integrator 001 by itself and the next specifies the product of the outputs of divider 050 and constant number 100. The zero word indicates the end of the control words for integrator 000. The next control word specifies the input to integrator 001 as the output of integrator 000 times constant number 101. This is the only input to integrator 000 and the next zero word indicates this fact. In a specific location in the computer memory the programmer must place a 2 so that the integrator routine can compare this number with the number of zero words it comes to and transfer control to the amplifier subroutine when they are equal. This code is not complete, of course, since it does not even specify the output, but there is perhaps enough shown to give some idea of the simplicity of the problem formulation. Extract: Conclusions Conclusions A DEPI program has been written for a Datatron 204 at the Jet Propulsion Laboratory in Pasadena. Two problems were run on it for evaluation purposes. The first of these was a set of two non-linear, first-order differential equations describing flame temperatures which could not conveniently be run on the analog installation because of the range of the variables involved. The second problem was a flat earth trajectory, many of which have been run both on the analog computer and the Datatron 204. This is a set of four first-order differential equations with several arbitrary functions, a square root, and several discontinuities. The preparation time for this problem was two to three days as compared to two to three weeks for a standard digital program or about a week for an analog program. The resulting code was far more flexible than the standard digital one and at least as flexible as an analog code. The ratio of computing times, however, is high--a single DEPI integration step taking, for this problem, four times as long as the same step in the standard flat-earth trajectory program. Since the standard digital solution to the trajectory takes about two and one-half times as long as the analog solution at comparable accuracies, the ratio of DEPI time to analog time is approximately ten to one. Datatron 204 is a medium-speed machine, however, and this ratio would reverse on some high speed computers, so that the DEPI time would only be one-tenth of the analog time. Several basic improvements could be made to the methods used in DEPI. For one thing, the attempt to simulate the component structure of an analog computer seems artificial and a freer approach would probably lead to a great improvement in the simplicity and coding ease of the resulting scheme. The necessity for serial servicing in DEPI is highly undesirable from the point of view of the prograrpmer and could probably be eliminated altogether. The fact that DEPI operates in the interpretive mode causes its computing speed to be about a third of what it could be. Compiling techniques could probably overcome this defect, though a routine using this technique would be much harder to write and to keep flexible. The Runge-Kutta type integration is probably one of the best features of DEPI. It allows the attainment of high accuracy without a prohibitive expenditure of computing time. in [ACM] JACM 5(3) July 1958 view details in Simulation 3(6) December 1964 view details Introduction The possibility of using a digital computer to obtain check solutions for the analog was recognized by many people at the dawn of our 15 year old history. Unfortunately several problems existed then, mainly at the digital end, which made this impracticable. Digital computers of that day were terribly slow, of small capacity and painfully primitive in their programming methods. It was usually the case when a digital check solution was sought for an incoming analog problem, that it was several months after the problem had been solved on the analog computer and the results turned over to the customer before the digital check solution made its appearance. The fact that the two solutions hardly ever agreed was another deterrent to the employment of this system. As we all know, digital computers have made tremendous strides in speed, capacity and programmability. In the area of programming ?and throughout this pa per - we're talking of scientific problems expressible as differential equations; the main effort has been in the construction of languages such as Fortran. Algol, etc. to permit entering the problem in a quasi-mathematical form, with the machine taking over the job of converting these to the individual serial elemental steps. While the progress along this line has been truly awe-inspiring to an analog man (usually all engineer), the resulting language has become quite foreign to him so that if he wishes to avail himself of the digital computer he must normally enjoy an interpreter in the form of a digital programmer (usually a mathematician). This means that he must describe his engineering problem in the required form, detail, and with sufficient technical insight to have the digital programmer develop a workable program on the first try. This doesn't happen very often and it is the consensus of opinion among computing facility managers that a major source of the difficulty lies in the fact that the engineer does not always realize the full mathematical implications of his problem. For example, ill specifying that a displacement is limited, he might not state what happens to the velocity. This can lead to all sorts of errors as an analog programmer would know. It is, of course, possible for an analog programmer to learn to program a digital computer by studying Fortran. This has been attempted here at Wright-Patterson AF Base with little success, mainly because, unless used very often, the knowledge is lost so that each time a considerable relearning period is required. Some computing facilities have even embarked on cross-training programs so that each type of programmer knows the other's methods. While this has much to 1,ecommend it, it is often impracticable. In March of 1963, Mr. Roger Gaskill of Martin-Orlando explained to us the operation of DAS (Digital Analog Simulator), a block diagram type of digital program which he intended for use by control system engineers who did not have ready access to an analog computer. We immediately recognized in this type of program the possibility of achieving our long-sought goal of a means to obtain digital check solutions to our analog problems by having the analog programmer program the digital computer himself! We found that our analog engineers became quite proficient in the use of DAS after about one hour's training and were obtaining digital solutions that checked those of the analog. At this point several limitations of this entire method should be acknowledged. First, the idea that obtaining agreement between the digital and analog solutions is very worthwhile is based mainly on an intuitive approach. After all both solutions could be wrong since the same programming error could be made in both. Secondly, the validity of the mathematical model is not checked, merely the computed solution. Finally, it might be argued that the necessity of the analog man communicating the problem to his digital counterpart has the value of making him think clearly and organize his work well. This is lost if he programs the digital computer himself. In spite of these limitations we thought it wise to pursue this idea. Although DAS triggered our activity in the field of analog-type digital programs, several others preceded it. A partial list of these and other such programs would include: DEPI California Institute of Technology DYSAC University of Wisconsin DIDAS Lockheed-Georgia PARTNER Honeywell Aeronautical Division DYNASAR General Electric, Jet Engine Division Almost all of these - with the possible exception of PARTNER (Proof of Analog Results Through a Numerical Equivalent Routine) - had as their prime purpose the avoidance of the analog computer. They merely wished to borrow the beautifully simple programming techniques of the electronic differential analyzer and apply them to the digital computer. While DAS proved to be very useful to us, certain basic modifications were felt to be necessary to tailor it better to our needs. Principal among these modifications was a rather sophisticated integration routine to replace the simple fixed interval rectangular type of DAS. Other important changes were made but the change in the integration scheme and our wish to acknowledge our debt to DAS, led us to the choice of the name MIDAS, an acronym meaning Modified Integration Digital Analog Simulator. In this paper a brief description of the method of using MIDAS will be given, followed by a summary of our experience in using it in a large analog facility for about 18 months. in [AFIPS JCC 26] Proceedings of the 1964 Fall Joint Computer Conference FJCC 1964 view details in [ACM] CACM 9(10) October 1966 view details in [ACM] CACM 9(10) October 1966 view details the DEPI (Differential Equations Pseudo-code Interpreter) language was developed in 1958 by H. F. Lesh at the Jet Propulsion Laboratory (Pasadena, CA). Lesh also used machine language and employed a fourth-order Runge-Kutta integration algorithm (Lesh, 1958). DEPI was developed further and saw use in the early 60!s (Hurley, 1960). in [ACM] CACM 9(10) October 1966 view details |