DARE-II(ID:6944/dar010)Continuous simulation languagesv 2 of DARE ran on DEC PDP-9 Related languages
References: Extract: BEDSOCS Bradford Eaucational Simulation language for Continuous Systems (BEDSOCS), is an interactive digital computer language designed to allow the easy solution of problems described in terms of ordinary differential equations. The language uses Dartmouth BASIC as the procedural language and, like most BASIC systems, operates interpretively. BEDSOCS has such advanced features as automatic equation sorting, variable-step integration and graphic displays. The equations describing the simulation need not be represented in terms of block diagrams, but rather are entered much like ordinary differential equations. Above all, because BEDSOCS uses an interpreter, there is no compilation time. This allows users to write and debug programs quickly at the cost of longer execution time. BEDSOCS, written by Geoffrey Brown (1973) at the University of Bradford, can be implemented on an HP2100 computer having 16k words of memory. The system uses HP BASIC as a subset and supports floating point firmware and a Tektronix storage display. Many options are available for implementing BEDSOCS. However, the authors used a single user version distributed on paper tape. Using BASIC as a subset, BEDSOCS partitions a program into a control region, which contains BASIC statements, and a dynamic region, which describes the representation of the system to be simulated. In the control region the user can program in BASIC to establish initial conditions, set control variables and perform general computation and input/output. The dynamic region contains the representation of the set of differential equations. The control region is divided into the initial region and the terminal region. The initial region precedes the dynamic portion of the BEDSOCS program and is used to set initial conditions and control variables to be used in the dynamic region. The terminal region is executed when the simulation is completed. This region is generally used to perform final calculations, print results, or loop back for iterative differential equation solving runs. The dynamic region of a BEDSOCS program contains the 'representation set'. This is a set of equations and procedure blocks representing the simulation to be performed. Fig. 2 shows a typical procedure block, enclosed by the 'PROCED' and 'PROEND' statements. The 'PROCED' statement has the form: (statement no.) PROCED (output list) = (input list) where the (input list) contains the dependent variables used within the procedure block and the (output list) contains the dependent variables which are assigned values by the procedure block. Within a procedure block, the user may describe nonlinear functions or other operations involving any BASIC statement just as in the control region. There may be any number of procedure blocks within a BEDSOCS program. However, a variable may not occur in the output list of two procedure blocks. Inputs and outputs of procedure blocks are sorted just like those of a defined variable equation. Equations of the representation set differ from BASIC statements in their location and form. These statements are not preceded by the 'LET' identifier of BASIC and they are automatically sorted into a BASIC program which evaluates derivatives and then updates state variables (integration). For example, the following differential equation may be expressed in BEDSOCS with the aid of the 'DER' identifier. dxZ/dt2 - 5x + 3 = y In BEDSOCS 300 DERZ= Y - 5 * X + 3 310 DER X = Z or 300 W = 5 * X - 3 310 DERZ= Y- W 320 D E R X = Z These simple equation statements combined, if necessary with procedure blocks, make it very easy to describe complex systems. Since BEDSOCS is interpretive, it is executed without compilation. When the user types 'RUN', BEDSOCS checks the program structure, creates the symbol table, sorts the representation set and initialises the independent variable or variables to zero. As this initial setup is performed, errors are displayed on the user's console with the number of the line where the error occurred. Execution continues procedurally region is split into two sections, a procedural part and the representation set. When control flows into the dynamic region, it encounters the first procedural section. This region (transparently to the user) repeats derivative calls and integration steps as determined by the derivative computing routine, defined by procedure blocks and equations within the representation set. This routine is executed until a communication point is encountered. Such points occur at regular intervals set by the user in the control region, or at points determined by test values described by 'EXIT' statements. When a communication point occurs, execution is transferred to a procedural section of the dynamic region following the equations section of the program, typically to produce output. Fig. 3 shows a program which uses the communication points by means of the 'EXIT' statement. When the value of the inequality in the 'EXIT' statement changes from 'FALSE' to 'TRUE', the program transfers control to the procedural section following the representation set as shown. BEDSOCS uses a 4th order Runge-Kutta-Merson integration routine which allows variable step sizes. By using control variables, the user can set the error tolerance and the minimum step size. As the simulation continues, the step size is adjusted according to the estimated truncation error. Perhaps the most significant feature of BEDSOCS is the ease with which it can be mastered. Using BASIC as a procedural language and implementing the representation set in a familiar format allows even the novice to write complex simulation programs. BEDSOCS not only requires no compilation time, but also greatly simplifies debugging. For users requiring immediate response on small problems, BEDSOCS is an attractive simulation language. in The Computer Journal 23(3) 1980 view details Extract: Introduction Computer simulation is vital for engineering development and partial system tests. ~ Interactive digital simulation systems2 let an experimenter enter and modify programs from a keyboard and, with a minimum of delay, present graphic- display results as the simulation proceeds. Since experiments will be modified and rerun many times, close interaction is necessary between the experimenter and the model. Such interaction requires convenient facilities for program and data entry and modification (editing), fast program translation and solution, prompt error reporting, selection of different integration routines without retranslation, runtime graphic displays and CRT-terminal listings, self-documenting hard-copy output of programs and data and report preparation, interactive file manipulation (storage, retrieval, and combination of programs and data), and provision for interactive simulation studies involving multi-run experiments (crossplots, statistics, optimization, model matching). While much digital continuous-system simulation is still batch processed, interactive simulation is usually preferable. Interactive simulation is necessary for partial system tests involving, say, real missile-guidance components on a flight table Positioned by a Computer simulating the vehicle. Interactive digital simulation has been realized by the various Dare differential analyzer replacement simulation systems developed at the University of Arizona since 1968. In particular, Dare/Eleven runs on DEC PDP-I I minicomputers, 2 and the newer Dare P/l system is portable machine-independent) and suitable for timesharing as well as for VAX 32-bit superminicomputers. Dare programs translate into Fortran and can access all the facilities of that language. Fortran-based simulation languages like CSSL IV, ACSSL, or Dare require translating of system equations into Fortran, compilation of the resulting Fortran program, and linking of the binary program with a set of library routines for integration, display, etc. Dare systems implement this translation sequence automatically on a COMPILE command. The complete translation process requires from 35 seconds for short programs to several minutes for longer programs. This period is tolerable if we have many interactive runs with the same model, since parameter changes do not require recompilation. Research simulation, however, often involves frequent changes in the model (modified system equations) and/or changes in the experiment, and thus in the job- control program that calls the simulation runs. Under these conditions, even a one-minute recompilation becomes annoying, especially if the translator or compiler rejects a program change because of an error. Translation delays interrupt the experimenter's train of thought. For this reason, immediate simulation-language translation with a line-by-line interpreter is attractive, even though the resulting code will necessarily execute more slowly than compiled code. Interpreter systems permit at least primitive line-by-line editing without a special editor, and they report many syntax errors as soon as a program line is typed (interactive programming). The best-known interpreter language is Basic, which can serve modest simulation applications. As an example, the University of Arizona s BDare simulation package, written in ANSI minimal Basic, runs even on eight-bit personal computers. Basic, though, is inadequate for larger simulations. Interpreter execution is necessarily slow; in particular, the entire derivative computation and integration loop must be translated again and again at each integration step DT. Few Basic systems, moreover, permit double-precision integral accumulation, which is absolutely necessary to prevent roundoff errors in simulation. Basic can also be compiled, but its compilation produces less efficient code than Fortran. A different solution is needed. Extract: Microdare I, II, III The Microdare I and II systems, developed at the University of Arizona, were the first to combine a job-control interpreter and a simple compiler language, which emulated analog-computer block diagrams with threaded-code routines. Microdare III added a real inline expression compiler. Microdare, designed primarily for fast digital signal processing and control rather than for simulation, has only two integration rules and compiles fixed point operations to gain speed. The simulations are, then, very fast but must be scaled. The University of Arizona s new language, Desire (Direct Executing Simulation in Real Time), on the other hand, employs a scale-factor- free floating point language and permits the user to overlay any number of different integration rules without recompilation. Extract: Summary Summary Early Desire is a new floating point equation-language system for interactive dynamic system simulation. It runs 1.3 to five times faster than threaded Fortran and executes immediately on a RUN command without any external compiler or linker. An experimenter thus obtains results of model changes at once. An interpreted job-control language serves for interactive program entry, editing, and file manipulation and for programming multi-run simulation studies. The dynamic program segment containing differential equations in first- order form is entered just like the job-control statements and accesses variables with the same name. An efficient, extra-fast mini-compiler translates the dynamic segment practically instantaneously. Different precompiled integration routines can be overlaid from mass storage while the program runs. Early Desire runs on any 28K-word PDP-I I or LSI-I I processor with FIS or FPU instructions under the RT-I I operating system and is configured for up to 40 state variables. The system provides a true CRT screen editor with cursor-control and number-pad keys and produces runtime graphics even on VT-52 alphanumeric terminals and on VT-I I displays. Future Desire systems will run on 32- bit super-minicomputers and, for extra speed, on minicomputers with attached array processors. in COMPUTER 16(5) 1983 view details |