DIDAS(ID:5910/did001)Simulations languagefor Digital Differential Analyzer Simulator Lockheed, Georgia 1957 IBM 704 Related languages
References: By far the majority of numerical integration formulas are of the multipoint type. In these types the unknown point on the integral is found as a function of known previous points and derivatives at those points. The number of these previous values varies from one to four or five. Using more than that becomes quite unwieldy. A refinement of the multi-point formulas is the "predictor-corrector" technique. Here a formula such as disuussed above (e.g., one using the previous ordinate and the four previous derivatives) is used to predict the desired point. Then a,completely different formula is used to cor-rect this value. This latter formula employs the value of the derivative at the point just predicted. Consequently it serves as a check: on the accuracy of the predicted point. More specifically, one of these formulas is used to integrate ahead by extrapolation, and ths other is used to check the axtrapolated value. The predicted and corrected values are required to agree to within a predetermined tolerance. If this requirement is not met, then the integration increment can be reduced. Conversely, if the values agree closely enough, then the integration increment raay be increased to speed up the solution. Three predictor-corrector type routines were programmed: (1) Adams-Moulton (2) Adams-Bashforth (3) Milne (A fourth multi-point formula was tested and has been used extensively at GELAC. It employs only a predictor formula using three previous points. It was programmed by G. S. Slayton and is incorporated into his routine, DIDAS, a Digital Differential Analyzer Simulator. Both the accuracy and speed of this program seem to be quite good.) These methods require the knowledge of four starting points on the solution (three in the case of DIDAS) to get started. Various methods exist for finding these values, one of which is the method of Runge-Kutta. External link: Online copy 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 |