Contact us Heritage collections Image license terms
HOME ACL Associates Technology Literature Applications Society Software revisited
Further reading □ OverviewInformation retrievalWord-count and concordance generator (COCOA)Subject indexesChemistry-related graphicsList processing systemArchaeological classificationCollocation and collocabilitySymbolic language for simulation (SOL)Prehistory and explanatory hypothesesChess program (MASTER)Himmelbett games
ACD C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACLApplicationsCocoa :: Non-Numerical Applications
ACLApplicationsCocoa :: Non-Numerical Applications
ACL ACD C&A INF CCD CISD Archives
Further reading

Overview
Information retrieval
Word-count and concordance generator (COCOA)
Subject indexes
Chemistry-related graphics
List processing system
Archaeological classification
Collocation and collocability
Symbolic language for simulation (SOL)
Prehistory and explanatory hypotheses
Chess program (MASTER)
Himmelbett games

Simulation on Atlas: SOL

Paul Bryant

1966

THERE is a large class of real time problems which are very difficult to solve by means of numerical analysis. One section of this class concerns problems involved in studying traffic networks or the study of the flow of materials through a factory. This type of problem is, however, amenable to a simulation type of solution. In a simulation approach a computer program is written to make the computer behave like the real system, but speeded up. The flow of materials into the factory can be simulated and perhaps random number generators can be used for simulating variations in delivery times, and so on. The flow of materials can be studied at any point in the factory and at any grade of detail, limited only by the program complexity involved and the computer time available. Changes can be made to the system and these effects can easily be seen without the expense of actually making the changes on the factory floor.

As with any computer program, it is difficult to write in a language not suited to the problem; and this is especially true when dealing with a simulation problem due to the difficulties of programming parallel activities on a computer, which is essentially a serial device. However, languages have been invented to deal with this type of problem in the use of which the user need have no knowledge of exactly how the computer deals with parallel activities and similar situations, and can concentrate his attention on the more interesting aspects of his problem and express them easily. Several simulation languages have been designed, of which one, called SOL [1] seemed particularly powerful and convenient; I have written a compiler for this language which is now running on Atlas.

Apart from our customers, we ourselves in the Laboratory have a need for a simulation language; we want to study the operational effects of changes to the system, such as the proposed addition of a large disk file. In other words, we want to use the machine itself to predict its own response to changes in circumstances. But to see how the language is used we can take a simple problem, that of patients waiting to see a doctor. The program which simulates this is as follows:

       PROCESS PATIENT
       BEGIN
START) NEW TRANSACTION TO QUEUE A new patient enters the surgery 
                                After a random interval between 
       WAIT (20)                0 and 20 minutes, another patient enters.
       GO TO START 
QUEUE) SEIZE DOCTOR             Patient tries to see the doctor.
                                If he is busy the patient is queue
       WAIT 4                   When doctor is free, patient
                                'busies' him for 4 minutes during
                                which time no other patient can 
                                see him.
       RELEASE DOCTOR           Doctor may now see next patient
       CANCEL                   Patient leaves
       END

A further piece of code will deal with interruptions caused by telephone calls, thus:

  
       PROCESS TELEPHONE
       BEGIN 
START) WAIT 1 '17               Telephone calls are received at 
                                random integral intervals of 
                                between 1 and 17 minutes. If 
                                the telephone is engaged, the 
                                call is lost.

       IF PHONE BUSY THEN GO TO START
       SEIZE DOCTOR, 2          The doctor stops what he is doing
                                and answers the telephone. The
       SEIZE PHONE              '2' indicates the strength with 
                                which he is seized. A higher 
                                strength seize may interrupt a 
                                lower strength one. Call lasts 
       WAIT 3                   3 minutes.
       RELEASE PHONE
       RELEASE DOCTOR 
       GO TO START
       END

DOCTOR and PHONE are called facilities, and to couple these to the program the statements:

      BEGIN
      FACILITY DOCTOR, PHONE

are needed at the heading of the program.

The system provides facilities not shown in this example, including input/ output statements, arithmetical operations and a variety of random-number generators. While running, a program produces a continuous comment on its progress and statistical results are readily available.

The compiler at the Atlas Laboratory is implemented in Compiler Compiler [2)] which has proved itself well suited to the task. The compiler is card-oriented and a few changes have been made to the language to allow for this. For example, certain delimiters have been introduced to avoid the necessity of underlining characters; also only one statement is allowed on each line.

References:

[1] Papers on SOL - A Symbolic Language for General-Purpose Systems Simulation, D. E. Knuth and J. J. McNeley I.E.E. Transactions on Electronic Computers, 401 and 409, 1964.

[2] The Compiler Compiler R. A. Brooker, I. R. MacCallum, D. Morris and J. S. Rohl Annual Review in Automatic Programming Vol. III, 1963.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site