Flexible real-time nuclear data acquisition processing software

N U C L E A R I N S T R U M E N T S AND METHODS 160 ( 1 9 7 9 )

147-158 ; ©

N O R T H - H O L L A N D PUBLISHING CO.

FLEXIBLE REAL-TIME NUCLEAR DATA ACQUISITION PROCESSING SOFTWARE L. M. TAFF Kernfysisch Vetsneller lnstituut, Rijksuniversiteit

Groningen, The Netherlands

and Fermi National Accelerator Laboratory, Batavia, Illinois, U.S.A. * and F. SPORREL Kernfysisch Versneller Instituut, Rijksuniversiteit

Groningen, The Netherlands

Received 9 October 1978 A computer program for nuclear data acquisition is described which performs "incremental linking" of memory-resident data-processing software modules according to console keyboard commands. The modules perform functions associated with pulse-height analysis. This technique allows a single program to adapt to many experimental situations and allows an experimenter to change his data acquisition program during an experiment. On-line processing of arbitrary complexity is possible. After outlining the data acquisition software framework, the paper discusses details of the data acquisition processor, and an example of its use is given. A critique discusses shortcomings of the first release of the program. An appendix describes an algorithm for updating histograms on a fixed-head disk in real time.

1. Introduction This paper describes a computer program for data acquisition in a nuclear physics research laboratory. The techniques employed - incrementally linking code modules which perform specialized tasks - are quite general, and may be useful in a variety of applications demanding a combination of high flexibility and high performance in either real-time or off-line situations where continuous data streams are processed. The outline of the paper is as follows. In the remainder of this introduction we describe the institution and motivation behind our work, and survey briefly a few programs which span a range of philosophies. Section 2 considers the logical splitting of a typical program into a "main program" and a "data acquisition processor", and section 3 introduces the idea of such a processor which is the thesis of this paper. In section 4 the program resulting from our work is described in more detail. Section 5 presents performance figures and an application, and gives a critique of some areas where improvement is warranted. Finally, ideas about future directions for further development are mentioned in section 6.

*

Present

address.

1.1. DESCRIPTION OF THE ENVIRONMENT

For background information, the Kernfysisch Versneller Instituut (KVI) is a university/government-sponsored laboratory devoted to basic research in nuclear physics. It operates an AVF cyclotron providing particles of 160q2/A MeV (70 MeV protons), and has experimental hardware for particle detection, gamma-ray coincidence work, and a magnetic spectrograph of the Q3D iype. The data acquisition system is heavily computeroriented, currently consisting of three Digital Equipment Corporation PDP-15 computers. The PDP-15 is an 18-bit single-address computer with a memory cycle time of 0.8 as. One machine is usually devoted full-time to data acquisition, the others being used for software development and off-line analysis. At any given time, several experiments are in various stages of planning, execution, and analysis; normally each will have different data acquisition needs. Therefore several different programs for the PDP-15's normally must be operational at any given time. Additionally, a significant fraction of the KVI staff is visitors with neither the time nor inclination to become involved with programming. Finally, experience has shown that as experiments become more complex, data analysis becomes the main bottleneck in the research process,

148

L.M.

T A F F A N D F. S P O R R E L

and leads to a desire by experimenters to do more and more with the computer on-line, during the course of a measurement, rather than queue for computer time afterwards. It was this situation of frequently changing requirements, increased complexity of processing, and a dearth of programming manpower that led us to the work described in this paper. 1.2. OVERVIEW OF SEVERAL PROGRAMS Data acquisition programs which we have seen used in nuclear laboratories have been of a few general types which we will describe briefly to distinguish them from our work. One such program ~) is currently in use at KVI, a single self-contained program written in assembly language, not using a monitor (operating system), dedicated to acquisition of spectra. The program does its task well, is compact (leaving more memory for spectra), is convenient to operate, and has facilities for simple operations on spectra (add, substract) built in. Its chief disadvantage is that it is complicated internally and therefore difficult to change. To provide the flexibility required by changing experimental needs, an additional data acquisition program was implemented in a high-level language (FORTRAN at the KVI). Several "real-time extensions" were provided in the form of FORTRANcallable assembly-language subroutines to provide high-speed processing in time-critical areas. The approach has proven its usefulness over the course of several years by being much easier to adapt to new experiments. In our experience, the drawback of this approach is the proliferation of similar programs, and the fact that virtually every experiment will require at least some programming effort. A third approach has been used by Rogers2), who developed a large "master program" written in assembly language. The master program incorporated a wide variety of modes of data-taking, only a small subset of which would normally be used by an experimenter. Prior to data acquisition, the experimenter would run a "program generator" which would produce auxiliary input for the assembler so only the desired portions of the master program would be assembled. Therefore a program results which is capable of handling various kinds of input data in individually tailored ways. There are serious drawbacks, however. The processing algorithm executed during data acquisition is assembled into the user's program, and cannot

conveniently be changed at run time. Furthermore, the code is in assembler language, so when changes become necessary they are difficult to implement. A fourth method is that adopted by Snyder3) in which data-acquisition featttres are incorporated into an interpreter for an interactive language. In this case the interpreter must be resident, but the actual program is in source-language form and requires little memory. Since the interpreter (Snyder uses the FOCAL language) is available to the user at run-time, a powerful and flexible analysis capability for acquired spectra results. Unfortunately, the flexibility does not normally extend to specification of operations to be carried out in real-time on the input stream of data. The goal of the present work was to develop software whose flexibility was comparable to that afforded by, e.g., the program of Rogers, yet giving complete run-time control of operation. We have used techniques which we have not previously seen in laboratory data acquisition systems. In processing nuclear events the program we describe can perform an arbitrary sequence of operations (building spectra in memory or on a d i s k , digital gating of a spectrum by one or more other parameters, etc.) in any order, with the entire sequence specified at run time. Any of the operations can be turned off and back on at will, without affecting other operations. Although our motivation was to cut down on proliferation of subversions of a basic program, the flexibility and run-time specification of the processing algorithm has opened qualitatively new possibilities in data acquisition complexity. The means by which the flexibility is achieved is the imbedding of a simple "incremental linker" into a data-acquisition framework. 2. Basic program structure

The operation of most data acquisition programs can be divided into two logically distinct parts: (a) a continuously processing data acquisition part in which the hardware input devices (ADCs, etc.) are serviced, and data are processed and stored, and (b) the part responsible for everything else the program does - typically including a "main program", keyboard listener and command interpreter, and various routines for starting and stopping acquisition, data analysis, etc. We should point out that in a typical nuclearstructure laboratory, all data are passed through

149

FLEXIBLE PROCESSING SOFTWARE

the processing phase. It is not usually the case that, as in high-energy physics for example, the data are all logged to magnetic tape, but only a fraction might be analyzed on-line. Therefore, high processing rates are demanded. On the other hand, the processing of each nuclear event is not usually very time-consuming, consisting mostly of simple integer arithmetic and bit-manipulation. We discuss (b) first. 2.1. MAIN PROGRAMS Structurally, "main programs" are essentially executives and dispatchers, as illustrated in fig. 1. When a command is entered the executive gains control (either by polling o r - in an interrupt-driven system - by being given control after an interrupt). It may check the command for syntax and proper arguments. It then searches a command table to see if the command was legal, and if so, calls a routine to carry out the desired function. Normally it will return then to its listening state. Typical operations may control a display, print out data, perform arithmetic operations on spectra (e.g., subtract background), start or stop counting, enable writing to magnetic tape, etc. We expect most data acquisition programs can be broadly fit into this two-part structure, whether they are simple or elaborate, written in a high- or low-level language, whether of a polling or interrupt-driven nature. The importance of this executive part of the program is that it is what the user sees. The acceptance of a program depends on

I

J input hardware

hardware I

s&oftware

data

oquisition

Ubf

---4

command i tab/e search

Fig. 1. Typical main-program polling loop. On detection of a command, the command table is searched. If a match is found,

a routine corresponding to the command is called. If it is desired to retain control when no commands are present, special measures are needed to input a command from the console device so that control is not lost to the executive while waiting for input to terminate.

how easy it is to get a good display, to enter a command, to make use of special features, etc.; our experience with the present program indicates that acceptance also depends on being able to easily obtain a comprehensive overview of the current state of the system. 2.2. DATA ACQUISITION PROCESSORS The function of the data acquisition software [logical part (a) above] is to process a stream of data, and is depicted in the data stream in fig. 2.

data aquisition

\

processor

C)

Fig. 2. Global flow of data during processing. The role of the data acquisition processor is to generate appropriate histograms from data gathered by the hardware.

150

L.M.

T A F F AND F. SPORREL

The input data are gathered by a software device driver or the hardware into an input buffer of from one to, perhaps, 1000 words length. The data are taken from the buffer and processed by a data acquisition processor (dap). The dap produces spectra (histograms) and lists of event descriptors ("event-by-event" recording). It is the internal operation of a dap which is the subject of this paper.

3. Basic processor structure 3.1. TRADITIONALDAP In fig. 3 we present a flow diagram of a reasonably flexible dap which could be called "traditional". The routine can give fast execution of the most-used pulse-height analysis functions. Incor-

get event from

nput buffer

In°

offset; update proper spectra '

ioo,o , ° yes

no

yes no

3.2. NEW DAP STRUCTURE Many of the operations in fig. 3 can be implemented as subroutines called one or more times from the main dap. In our system every operation is carried out by a subroutine. The structure is that of a miniature, fast executive calling each in a list of subroutines (see fig. 4). (The term "list" as used here does not imply any kind of linkage structure; we use it simply to denote a series of elements usually in the form of an array.) The keys to power and flexibility lie in (1) the choices of operations available in the subroutines, and most importantly (2) the fact that the list is not specified at load time. The list is filled in (the subroutines incrementally "linked") at run time in an arbitrary sequence. Therefore the same program may be used in widely different experiments of varying degrees of complexity.

4. Program description With the preceding as a foundation, we now describe a data acquisition program which has been in use for about two years. We will describe first the "main program", or executive, then the dap introduced in section 3.2. We will then discuss details such as the addition of a process to the dap subroutine list, and give an application of the program.

[tape buffer ].

I /.r.. 0uff.

@

poration of "user-written" subroutines tor specialpurpose processing makes it adaptable to special requirements.

get event from nput buffer

/J

I'-°'°'I processing

]

ut yes

Fig. 3. "Traditional" data ac,quisition processor. One drawback of such a scheme is that the processes are "frozen" relative to each other; i.e., their order cannot be reversed without rewriting the code.

Fig. 4. "Subroutine-list" data acquisition processor. Each element in the " l i s t " is the address of a simple processing subroutine. Note that more than one list element may call (point to) the same subroutine.

FLEXIBLE PROCESSING S O F T W A R E

4.1. BAsic PHILOSOPHY For ease of maintenance our philosophy is to operate a manufacturer-supplied operating system, and to program as much as possible in a higherlevel language (FORTRAN was the only suitable high-level language available to us). We attempted to refrain from tricky coding and go-to knots, using assembly-language only where the task was difficult or impossible in FORTRAN, where significant memory savings could be achieved, or where highly time-critical code was necessary. We have thus far been able to avoid the complications introduced by overlay techniques; at this writing the entire system is resident in memory. 4.2. " MAIN PROGRAM" Fig. 5 shows the flow diagram of the main routine. We can make the following remarks about certain features. 4.2.1. Command input The keyboard listener is not a standard FORTRAN READ operation (which waits for input be-

I "'°r I

I dl~ °, call

11

subroutine °° [

no

yes

data II call aqu fltlon I pro~B$$o¢ Fig. 5. Main-program polling loop of present software is an elaboration of fig: 1. See discussion in text.

151

fore proceeding) but an assembly-language routine which changes the value of a FORTRAN variable when a command is entered (i.e., the FORTRAN variable is interrupt-driven). We have preferred commands with no arguments; any necessary parameters are acquired by the computer through keyboard conversation. 4.2.2. Display The display subroutine is also partially interrupt-driven. A multi-push-button box is used to control the (storage tube) display. When a button is pressed, the interrupt-service code sets relevant FORTRAN variables. During the cyclicly repeated call of the display subroutine these variables are tested and the display is initiated if necessary. Only a small part of a display is written following any one call so the display buffer is kept small.

4.2.3. BuJJer-lull detection Note that the test for "data input buffer full" as well as the call to the dap are located in the main executive scanning loop of the main program. This results in a clear picture of what the computer is doing for those who simply read the main program text. It also means that dap processing is done at mainstream priority; therefore a high data rate cannot lock out the display or command input for any longer than it takes to process one input buffer. The price one pays for this simplicity is that at high rates the second of a twobuffer ("ping-pong") input buffering scheme may be filled before the entire loop is executed, resulting in counting losses. One solution to the counting-loss problem is to use a multi-level priority system with various tasks at different priority levels; this would work as long as the real-time data processing can keep up with the input rate. Such a scheme represents a major departure from our requirement of simplicity, and we have therefore rejected it. To keep counting losses at high rates to a minimum we use larger input buffers. Then at high data rates only a relatively small fraction of total time is spent in the executive loop, and rate limitations are in the data processing software. 4.3. DATA ACQUISITION PROCESSOR We recall the position of the dap in the data stream from fig. 2. We now consider-the details of our dap, which are diagrammed in fig, 6,,where an input " e v e n t " is processed: . , .... ' , , ,.,, ~.:

152

L. M. T A F F

A N D F. S P O R R E L

m I get

-t

event

from

input buffer I

I

TI

/~

oo,,' current

II ~L___C

.I-',, I I

subroutinen -~ "-"~--~,.. ~l , ' I~\ , ~

It

~

~

, /,

i !',/ / :/; !(

~

~'~/"

Fig.6. Detailsof dataacquisitionprocessor.Even thoughthe same subroutineiscalledfrom severelplacesin the processing list,eachcallpassesa uniqueparameterblock. The dap is entered when the main program has detected that an input buffer has been filled. One complete event is then extracted from the buffer and held in an internal ""event array" for processing. The dap dispatcher is given control and it threads its way ("threaded code") through the list of subroutines (I). For each subroutine call, arguments are passed in various active and memory registers pointing to the event array and to a block of parameters (11) to be used by the called subroutine in its processing. Each time the subroutine list has been traversed a new event is extracted until the buffer is exhausted. The parameters in the parameter block include everything needed by the subroutine, including the addresses in the event array of the data to be operated on, the address to deposit its result (by convention, only one result is produced and passed on by a processing subroutine), and constants to be used in its calculation (e.g., the number of bit-positions to shift, or a digital offset above which a spectrum is to be stored). The event array contains not only the original input data, but has an entry (III) for the result of every subroutine called. Thus a subroutine may use not only hardware-acquired data, but results previously calculated. While we have arbitrarily restricted output to one word per subroutine, there is no lim-

it to the number of inputs a subroutine may use.

After the dap list of processing subroutines is set up, execution of any entry may be temporarily suspended by replacing its entry in the list with the address of a dummy (no operation) routine. The address removed from the list is saved in an additional list (IV) so it may be restored at a later time. 4.4. EXAMPLES To fix ideas, it may be useful at this stage to describe a few subroutines and a simple processing list. We enumerate here some of the key subroutines. They are designed for single- and multi-dimensional pulse-height analysis. l) Create a channel (histogram bin) number from a datum. Channel n u m b e r = [ d a turn-(digital offset)l/scale. The setup procedure chooses the scale based on the length of spectrum (histogram) desired. 2) Create a two-parameter channel number from two data. To construct a 2-parameter descriptor one normally must apply subroutine 1) twice (the most commonly used analog-digital converter (adc) at the KVI is a 13-bit instrument), and construct the 2-parameter result from these numbers. This rou-

FLEXIBLE PROCESSING

tine can be re-applied to its own results with additional single or multiple-parameter descriptors to produce descriptors of dimensionality higher than two. 3) Increment a spectrum residing in memory or on a disk. Parameters passed to the incrementing subroutines include the location of the channel-number descriptor in the result array, and the base address of the spectrum to be incremented. There are separate subroutines for incrementing memory- and disk-stored spectra. Although the disk routine is somewhat large and non-trivial3), its calling sequence is identical to that for memory stored spectra; complications due to the need to read and write data on the disk are transparent to the caller. The fixed-head) disk has a capacity of 262144 18-bit words, which can be divided as desired (e.g., one 512 × 512 channel matrix, or 64×4096 - i.e., 64 4 K spectra, perhaps used as 32 gates with individual background gates). With this capacity, users of the program are usually not interested in writing individual events to magnetic tape. 4) Test if a datum falls into a digital gate. The gate number is returned if the datum falls within a gate; if it does not, a code indicates this fact. We have considered two (non-exclusive) schemes for such gate-checking. In the simpler, one merely maintains lists of lower and upper gate limits, testing each datum by successive subtractions. The advantages of this scheme are that it does not require much memory, even for many gates, and that a channel may be in multiple gates. Its disadvantage is that it is slow when there are many gates. The alternative scheme uses a table-look-up approach; a table, or "gate spectrum", of the same length as the spectrum corresponding to the descriptor to be gated contains either a gate number or a not-in-gate code in each of its various "channels". When a datum is to be tested one merely looks in the corresponding "channel" in the proper gate spectrum to find the gate number. This method is fast, with a constant execution time for all cha.nnels (even with very many gates), but it requires considerable memory space for gate spectra. (When using germanium detectors,

SOFTWARE

153

for example, one often must have spectra of from 1024 to 4096 channels.) The space requirement could be relieved somewhat by using part-words for storing the gate spectrum, but one then may have problems displaying the gates conveniently if one uses the same display routine as that for spectra. In spite of the extra memory requirements, we have chosen the look-up method for our gating to obtain superior execution speed. 5) "Branch" over one or more following operations if a specified element did not fall within a gate. The datum is tested for the "not-in-gate" code. If found, the routine increments its return address such that a number of following operations is skipped. This subroutine, implementing decisionmaking capability, adds qualitatively new power to standard data-acquisition functions. It could be used, for example, to treat various particles differently after on-line particle identification, or in a gamma-ray multiplicity experiment to take various actions depending on the number of detectors activated (multiplicity) in each event. 6) Add two data together. This is useful in particle-telescope work where the total energy is lost in multiple detectors. 7) Put an x, y coordinate in the "twinkle" display buffer. When the buffer is full, a spot will be displayed at this x, y. Typically this datum is generated as a two-parameter result of telescope input. One sees a "projection" from above of (E, delta-E) or an (E, particle) surface. Looking at fig. 6, one may imagine it describes an experiment whose " e v e n t " is composed of 3 descriptors. Let operations A, B, and C of fig. 6 correspond to subroutines 1, 2, and 3 of this section. Then the processing of fig. 6 would be building a two-dimensional spectrum from two datum descriptors, and a single spectrum from the third. 4.5. DAP SUBROUTINES The operations carried out by these subroutines were designed to give efficiency in complex processing. For example, if one desires a "' projection" spectrum of a two-parameter matrix, a digital gate on one parameter of this matrix, and a twinkle display of the matrix, the channel number for each of the two parameters need be computed only once, and can then be used in all further cal-

154

L. M, T A F F AND F. SPORREL

culations. For simpler experiments one could construct higher-level subroutines, e.g., to both calculate t h e channel and increment the spectrum in memory in one subroutine. Setting up such higher-level subroutines from the keyboard may be somewhat easier, and the high-rate performance slightly better, since fewer subroutine calls are needed. The specific detailed design of the subroutines and the calling sequences and argument blocks, etc., must be to optimize performance. These assembly-language coded routines and their calling sequences can be highly machine-dependent, taking full advantage of any special features of the hardware, such as index registers, autoincrementing, fixed and floating-point arithmetic hardware, microcoding of instructions, etc. We expect the rate limitations will be in these processing subroutines for most counting experiments. 4.6. DAP SET-UP PRIMITIVES There are a number of fundamental or primitive set-up operations carried out internally within the dap. Each operation is executed when a corresponding entry-point is called. The entry points are as follows: 1) Insert a subroutine call at a specified entry in the processing list. This is an unconditional set-up at an arbitrary entry. The subroutine entry-point address, the list element number, and the parameter block address must be given as arguments. 2) Add a subroutine call to the list. Bookkeeping must be done as to where the current end is of the processing list. We do this simple arithmetic inside the dap; this entrypoint increments the list count and calls the previous primitive to insert the desired subroutine. The process number of the inserted subroutine is returned to the caller. This number must be known as it may be used to address the current result in a subsequent operation. 3) Kill the processing list. Effectively erases the processing program. No " e r a s e " primitive was implemented for single process calls for fear that if a process were so cancelled, subsequently set-up processes using the cancelled process' result may be overlooked, which might in turn lead to erroneous data acquisition. 4) Temporarily suspend a process. The call to a

processing subroutine is saved in the list reserved for this purpose, and its place is filled with a call to a dtmlmy subroutine. 5) Resume a suspended process. A suspended subroutine is restored to active duty. 6) Initialize the dap for service. Prior to a series of data-processing calls, the dap is initialized here, insuring that the most recent processing status is used. 7) Process an input buffer. This is the main business entrance of the dap. Since we normally employ multiple input buffers, the address of the buffer to be processed is passed to the dap. 4.7. INSTALLING A SUBROUTINE

We describe briefly the sequence of events when a subroutine is to be added to the dap processing list. A keyboard command unique to the subroutine to be entered is typed on the control console keyboard. When the set-up subroutine for the desired process gets control, it obtains the parameters it needs via keyboard conversation. It sets up a block of memory (obtained from a simple software memory manager) to use as a parameter block for the processing subroutine, and obtains the memory address of this block via a small assembly-language routine. Then the "add a process" primitive of the dap is called, and the process number returned by the dap is used in setting the parameters of the parameter block. (The block must contain the absolute address of the memory location in which the process subroutine must deposit its result. The process number is needed to compute this address.) Finally, the process number is reported to the user.

5. Experience with the program 5.1. PERFORMANCE In general for a complex real-time processing algorithm it is difficult to give meaningful performance figures. We have, however, measured counting rates for some basic pulse-height-analysis functions which appear in most applications. The counting of one single-parameter spectrum has been measured at about 9500/s. This rate should not be compared directly with systems which perform some of the present software tasks via hardware. The time to process one event (about 105/~s) can be divided into five parts: (l) fetching and identifying an event (36/~s), (2) constructing a histogram bin (channel) number

FLEXIBLE PROCESSING SOFTWARE

(27/~s), (3) incrementing a histogram bin (21/~s), (4) overhead associated with subroutine linkages (5.6/,ts/processx 2 processes = 11/~s), and (5) general overhead of the main-program loop, interruptservice register saving and restoration, etc. The total of steps (1)-(4) is about 95 tts,-so we conclude about 10/~s/word is spent on general overhead external to the dap. This includes about 2.5/1s for the PDP-15 "data-channel" hardware (3 memory cycles per word). The rather long " f e t c h " step involves identifying which of eight adc's was digitized, insuring that a valid coincidence was registered, checking that the adc's were digitized in the proper order, and seeing that the datum is valid (non-zero). Similarly, step (2) subtracts a digital bias from a datum, guarantees the result is within a digital window, and scales it to fit the length of the desired histogram. In many systems these functions are carried out by the hardware (or simply not done at all). We have also measured the rate achieved by the algorithm of Snyder 3) which we have adopted for updating spectra kept on an fixed-head disk. In our test a 512x512 matrix (i.e., 262144 total channels) was updated at an average rate of about 350 events/s, which is about what one calculates from an analysis of the algorithm for the sorting buffer sizes we utilized (see appendix). 5.2. USAGE

The original implementation of the program as described has been employed for a number of experiments over a period of about two years. It has been variously used in experiments with heavy ions, in gamma-gamma coincidence measurements, in measurements of coincidences between gamma- and X-rays, and between gamma-rays and conversion electrons. An example of the latter type of work 4) involving coincidences of gammarays with both other gamma-rays and with conversion electrons is shown in table 1, in which there are 28 processing steps. A nearly identical version of the data-acquisition program is available for analyzing data on magnetic tape. 5.3. CRITIQUE

In general the flexibility of this program is such that, with the exception of particle identification [for which there is a well-accepted program s) at KVI], we have been able to use it to satisfy all special requests which were made (i.e., there has not been a request which could not be implement-

155

ed). To this extent our main goal - one program to take the place of many - has been reached. There have been obstacles, however, to wide acceptance of the program within the laboratory. Firstly, there does not yet exist a mechanism to obtain a complete overview of how real-time processing is set up at any given moment (though hard-copy teleprinter output of the setting-up procedure is always at hand). It turns out such a facility is highly desirable; Tipple and Kulaga 6) also report dissatisfaction with this aspect of their own system. Secondly, the set-up procedure is relatively time-consuming, since the high flexibility requires specification of arguments in considerable detail. To some extent the problem involves repetitive conversational prompting of responses by the computer. Design of an appropriate user interface to the software - which allows specification of detail yet is not inordinately complex or time-consuming - is not an easy task. Thirdly, once set up, the list of processing subroutines cannot be changed without a completely new set-up. This is because absolute memory references have been incorporated (i.e., information binding has occurred). Finally, we have not yet implemented a way to record a particular software set-up so it may be easily re-loaded into the program from mass storage. This would be useful if the system fails, or if it is desired to temporarily run another program and return later to data-taking. 6. Future

directions

In our opinion the fundamentals of this work the software architecture and the incremental linking of pulse-height-analysis-oriented code modules - are sound and yield a high level of performance. Plans for additional work are directed toward the points in the previous section, namely, toward a smoother interaction with the user. Our intention at this time is to alter the procedure whereby each command to install a processing routine is executed immediately. Instead, relevant arguments will be written to an external file in text form. When data acquisition is to begin, the entire collection of such commands will be "compiled" at once (in milliseconds), and data acquisition will proceed. The difficulties encountered with the current program should then be eliminated: (1) the parameters specified by the user would always be

156

L. M. T A F F AND F. SPORREL

TABLE l Example of a dap set-up used in an experiment on multipolarities of transitions following nuclear reactions4). Three detectors were employed: (I) a Go(Li) detector used for software coincidence gates on transitions between levels of the ground-state band, (2) a second Go(Li) detector registering gamma rays in coincidence with (I), and (3) a Si(Li) detector for conversion electrons at the focus of a mini-orange spectrometer which filtered out delta-rays, including positrons. The algorithm first prepares the raw data. It then takes one of two major branches according to whether the transition of detector l fell in a peak or background gate. Each branch constructs two disk-stored histograms of 2 × 8 x 2 0 4 8 = 32768 bins. The histograms record the parameters (prompt/delayed)×(detector l gate ~/)× (energy) for both detectors (2 and 3). By recording coincidences with background gates in entirely separate matrices as is done here, one can subtract background from all gates with a single matrix-subtraction operation. Step number

Command name

Arguments

l

SIP

1st datum

2 3 4 5 6

SIP SIP SIP SIP LUG

2nd datum 3rd datum 4th datum 5th datum result 1

7 8 9

JNG LUG S2P

result 6, (8 steps) result 4 results 8 and 6

10

S2P

results 9 and 2

ll

ADI

result 10 (disk)

12 13

LUG S2P

result 5 results 12 and 6

14

S2P

results 13 and 3

15

ADI

result 14 (disk)

16

LUG

result l

17 18

JNG LUG

result 16 (8 steps) result 4

19 20 21 22 23 24 25 26

S2P S2P ADI LUG S2P S2P ADI AD!

results 18 and 16 results 19 and 2 result 20 (d!sk) result 5 results 22 and 16 results 23 and 3 result 24 (disk) result 1 (memory)

27 28

ADI ADl

result 4 (memory) result 5 (memory)

Explanation

Setup single-parameter descriptor. Create useful-length descriptor from I3-bit hardware value from detector I. Same for parameter 2 (detector 2) Parameter 3 (detector 3) Parameter 4 (time difference between detectors 1-2) Parameter 5 (time between detectors 1-3) Look up in a gate "spectrum". Gets a digital gate on parameter 1. Gates in the gate spectrum were set on peaks. Jump if not in gate. Skip 8 processes if result 6 was " n o t in a gate". Get a l-bit time gate on time/digital converter (tdc) of detector 2. Set up a 2-parameter descriptor. Use l-bit time gate from result 8 and 3-bit gate number from 6. Set up a 2-parameter descriptor from previous 2-parameter result (9) and l I-bit single-parameter result 2. Thus a 3-parameter descriptor is made. Add I to a histogram. The histogram has 32768 bins and is stored on disk. Get a I-bit time gate on tdc of detector 3 Set up a 2-parameter descriptor with I-bit time gate from result 12 and 3-bit gate from 6 As in process 10, produce a 3-parameter descriptor for an element of a matrix 2x8x2048 Increment the bin whose address was computed in step 14 in a disk-stored histogram. Look up in a background gate spectrum to see if descriptor falls in a background gate. Come to this step if gate-lookup failed in step 6. Jump if not in gate. Skip to step 26 if not in a background gate. Steps 18-25 are analogous to 8-i15, except that the histograms are coincident with background gates rather than gamma transitions of detector I

Increment memory-stored histogram at address given by descriptor result !. This step maintains a histogram of the spectrum used for gating, i.e., for coincidence requirements. These last 3 steps are performed even if the transition of detect9r I did not fall within a peak or background gate. Increment memory-stored histogram of time delays between detectors 1 and 2. Increment memory-stored histogram of time delays between detectors I and 3.

FLEXIBLE PROCESSING SOFTWARE

available in their original form for a status overview, (2) the processing specifications, being in text form, could be changed or added to easily, and (3) the setup would automatically be retained for subsequent use in other runs or experiments. Careful thought needs to be given to re-designing the precise form of keyboard communication with the user. Although convenience can be increased, for example, through use of default values for parameters which are not specified explicitly, great care must be taken that the resulting code does precisely what the user expects it to do. We thank Dr. F. Snyder for providing us with his disk-based sorting software. Part of this work was performed as part of the research program of the "Stichting voor Fundamenteel Onderzoek tier Materie" (FOM) with financial support from the "Nederlandse Organisatie voor Zuiver Wetenschappelijk Onderzoek" (ZWO), and by the United States Department of Energy.

Appendix Disk histogramming algorithm We give a brief description of the software of Snyder 3) for updating histograms on a fixed-head disk; the work has not been explicitly discussed in the literature. The algorithm is based on a fixed-head disk which has 128 tracks (i.e., 128 independent read/write heads) of which only one may be active at any instant. Each track holds 2048 18-bit words. With appropriate care to keep the software fast, it is possible to switch from one track (head) to any other during a " g a p " as the disk rotates through a small angle between the end of the tracks and the beginning (i,e., between words 2047 and 0). The algorithm exploits this fact, and attempts to operate synchronously with disk rotation. It is not possible to switch tracks between consecutive words - that is, to read word 96 from one track and word 97 from some other track (on the same disk rotation). The sorting routine reserves two "track buffers", each 2048 words in length, a ....track list" of 128 words (one per track), and two equal-length "sort buffers". The length of the sort buffe.rs is chosen through a trade-off between performance and memory available, as discussed below. We have used from 2000 to 3000 words per buffer. The add-one-to-disk entry point is called with

157

an 18-bit disk address as the input argument. The address is stored into the next available location in a sort buffer. When the buffer is full, input is switched to fill the other buffer and a cycle begins to update all disk addresses contained in the full buffer. Disk updating begins with a scan of the sort buffer by flagging in the track list which tracks must be updated. The first track to be updated is read into a track buffer. When reading is complete another read operation is initiated (into the second track buffer) on the next track to update. Then histogram updating proceeds. The sort buffer is scanned for those events (disk addresses) falling in the first track read in (there will be at least one). For each such event the corresponding location in the track buffer is incremented. When the sort buffer scan is complete, preparations are made to write the track buffer just updated back to the disk, and to quickly follow the write with a read of another track. A check is made to see if the current disk position is appropriate to write out the track just updated. If so, a write operation is begun and the increment-histogram cycle proceeds with the track buffer just read. If the disk is not ready, a return is made to the mainstream program; updating resumes on a disk-ready interrupt. When the disk is finished writing an updated track it is immediately switched (within its " g a p " time) to read another track into the same track buffer. Thus during the update cycle steady-state, the disk is always busy either reading or writing. The length of the sort buffers can be sufficient to occupy the increment-track-buffer software for exactly two disk revolutions (i.e., one write and one read to the other track buffer). This turns out to be about 6000-7000 words (18-bit disk addresses), depending on what else is happening in the computer, Therefore the worst case average counting rate R for disk-resident histograms is: R = (number of addresses in sort buffer)/(time to read and write 128 tracks) = 6500/(128 tracks - 2 * 1/25 s/track)(50 Hz line frequency), or about 630 counts/s. Memory requirements for this case are substantial' 16 000-17 000 locations are needed for buffers. Furthermore, the computer would be spending all of its time updating disk histograms. We have modified Snyder's original algorithm so that addresses are deleted from the sort buffer after they

158

L.M.

T A F F AND F. SPORREL

are used to update the proper track buffer. The sort buffers thus become shorter as the cycle proceeds, so the mainstream program gets more time to process raw data (at least toward the end of the disk-update cycle). If only half of the disk were needed for histograms, the average rate would double (only half as many tracks need be updated). Similarly, decreasing the sort buffer size will decrease the average rate. Quantitatively, the trade-off between rate, matrix size, and memory requirements is given by the average-rate equation above. The experimenter is usually interested in questions such as "How much counting rate is lost if 1024 words of sort buffer is re-allocated to (more convenient) memory-resident histograms?" For our case, using the entire 128 tracks, the answer would be about 50 counts/s per 1024 words re-allocated. (The 1024 words would come from t w o buffers, each sacrificing 512 words.) For any given division of resources the worstcase rate will improve if the data fall in peaks such that certain tracks often do not get counts and therefore do not need to be updated. For the

test described in the main text, the sort buffers were each 3000 lOcations. As 10--20% of the tracks did not need updating, our measured rate of about 350/s agrees well with the rate equation. Finally, we note that this algorithm is similar to one developed by Smith and SmuidersT). Smith and Smuiders, however, used a proprietary blockaddressable magnetic-tape ("DECtape") as the mass:storage medium for histograms. References l) p. Smulders, Lab. veer Algemene Natuurkunde, Rijksuniversiteit Groningen, The Netherlands, private communication. 2) j. G. Rogers, Texas A & M. Univ. Cyclotron Institute, Progress in Research (January 1972 - March 1973). 3) F. Snyder, Digital Equipment Computer User's Society (DECUS) library contribution 15-96. 4) S. J. Feenstra, W. J. Ockels, J. van Klinken, M. A. J. de Voigt and Z. Sujkowski, Phys. Lett. 69B (1977) 403. 5) j. R. Comfort, Internal Report KVI-44, KVI, Rijksuniversiteit Groningen, The Netherlands. 6) j. W. Tippie and J. E. Kulaga, IEEE Trans. Nucl. Sci. NS24 (1977) 492. 7) Ph. B. Smith and P. J. M, Smulders, Prec. 5th European Seminar, Digital Equipment Computer Users Soc. (1969) p. 181.