1 INTRODUCTION
The basic form of the event structure is derived from the
fact that all event-related data originates from electronics
channels within Scanners (being either an MEP+MX combination
or a SSP). Each Scanner handles the data either for a
particular detector component or in some cases for all
components within a localised region of the detector. Thus
the basic identification for a particular electronics channel
is:-
(Scanner ID, Channel ID)
where the Scanner ID uniquely identifies the geographic
location of the scanner and the Channel ID uniquely identifies
the particular electronics channel within the scanner.
Each Scanner produces a YBOS bank so that the basic
identification becomes:-
(Bank Name, Scanner ID, Channel ID)
This organisation is rather un-natural in that it has a
rather remote relationship to what the physicist would like to
have, namely:-
(Detector Component, Module ID, Channel ID)
Note that there is not a one-to-one correspondence
between Scanner Bank Name and Detector Component because of
the layout of Scanners. One example of this is the Central
Wedges; all components in a particular (Rapidity, Azimuth)
range are readout by a scanner that therefore contains data
from EM Calorimetry modules, Hadron Calorimetry modules and
Muon Chamber modules.
Furthermore there are several components where the
Channel ID is itself composite, examples being the
Calorimeters which are segmented in Rapidity, Azimuth and
depth.
One possible approach would be that each application
program would contain a "map" (perhaps hidden from the user by
a subroutine call) so that the user could request the data
from a particular physical channel and in some magical fashion
he would receive it. This is not only tedious and slow but
would also require a fairly large table or subroutine to be
slung around the necks of all users.
The ideal situation would be to reformat the data in such
a way that it was easily accessible under the physicist mode
of access. This would minimise the mapping and the burden of
tables or subroutines. This is the approach that has been
chosen for CDF, where the responsibility for the Reformatting
is the Event Builder's. This is a FASTBUS object (or process
on the VAX in the early stages of the experiment) that reads
in the individual Scanner Banks and forms the new Component
Oriented Banks from them. Thus the physicist will only have
available to him the Component Oriented Banks.
This document discusses only the Component Oriented event
organisation, the Scanner oriented organisation being
described in detail in another document. In effect, what is
described here is the raw data format for the CDF experiment.
Before a detailed discussion of this data structure, the
coordinate system, numbering schemes and other related topics
will be discussed.
2 COORDINATE SYSTEM
The Coordinate system is the standard CDF one, namely:-
1. The positive z axis is in the direction of the
protons
2. The positive y axis is vertical.
3. The positive x axis points out of the ring
4. Polar angle theta is zero along z axis.
5. Polar angle phi is zero along the x axis and
increases from the positive x axis to the positive y
axis.
3 NUMBERING
The Numbering scheme within each Detector Component is
essentially the same as that proposed by R. Kadel except that
all indices are in the range 0 through n-1.
Most of our detector components are segmented in azimuth,
rapidity and depth. The numbering scheme is the following:-
1. Azimuth Segmentation. Channel 0 corresponds to
0 < phi < delta where delta is a positive quantity
dependant on segmentation (typically delta is 5 to 30
degs). Channel Numbers increase with increasing phi
and where several Photomultiplier Tubes are
associated with one channel then these are numbered
in increasing azimuth.
2. Rapidity Segmentation. Channel 0 corresponds to the
channel in the detector component with the smallest
absolute rapidity (i.e. nearest the z=0 plane).
Channel Numbers increase with increasing absolute
rapidity.
3. Depth Segmentation. Channel 0 corresponds to the
channel in the detector component encountered first
by a neutral particle generated at the interaction
region. Channels increase with increasing "distance"
from this region.
Where the data for a particular component is contained in
separate East and West data blocks within a data bank, these
blocks are arranged in the order:-
West Block 1
...
West Block n
East Block 1
...
East Block n
This ordering (first blocks with negative rapidity, then
positive) is then compatible with the other ordering rules.
Any further specific allocation of channels for a detector
component is detailed in the description of the relevant
banks.
4 CLUSTERING
The main aim of the data structure is to minimise the
amount of "dead" datawords required in the event record for
identifying actual channel addresses. The present scheme uses
"clustering" in order to achieve this, data from adjacent
channels being identified only by the first channel address
and the cluster width followed by the contents of each channel
in sequence. Channel addresses themselves have a structure,
identified by assigning specific bit fields for each component
in the channel specification. Thus bits 0-4 might be a
channel number, bits 5-9 a plane number and bits 10-11 a
module number. Thus there might be discontinuities in the
encoded channel address range which would imply that clusters
would be limited within these discontinuities. However this
has the advantage that when scanning the event record a simple
arithmetic comparison may be made to determine whether the
channel occurs in a cluster rather than having to scan
clusters in detail.
5 LOGICAL RECORD AND BANK FORMATS
The detailed logical record and bank formats are
described in other documents so won't be repeated here.
CDF-156 (Version 3.00) contains a summary of these formats and
should be used as the reference document for these. The
following descriptions of the banks within an event record
uses a parameterisation of the Bank Type that is also
described in CDF-156. Furthermore, displacements are given
relative to the Bank Data Index (INDDAT) returned by BLOCAT,
rather than relative to the basic Bank Index (IND). Thus
displacements are all relative to zero (in other words, the
first word data word in the bank is located at offset 0).
6 EVENT RECORD BANKS
6.1 LRID Bank - Logical Record IDentifier Bank
The LRID Bank is the first Bank in any logical record and
has the following Bank Header Characteristics:-
Bank Name : "LRID"
Bank Number : 1
Bank Data Length : 9
Bank Type : BNKTI4 (Integer*4)
The Bank contains the following information:-
Displacement Word
(I*4) Type Description
0 I*4 Run Number
1 I*4 Run Type
2 I*4 Record No.
3 I*4 Record No. of this Type
4 I*4 Record Type
5 I*4 Creating Process ID
6 I*4 Creation Date
7 I*4 Creation Time
Notes:
1. Run Number. Run Numbers for runs writing data to
tape or disk shall be unique within each Experiment
Type and shall monatonically increase. Note that the
Run Number is a "Managed" Resource, such that it will
be allocated to all Partitions. Within each
Partition it will monotonically increase, but there
will be gaps in the sequence, caused by other
Partitions also requesting a Run Number. In Run1A,
the Run Number was filled by the Event Builder which
received it from Run_Control.
2. Run Type. This word has the following fields:-
Bits 0-11 Run Type
Bits 12-15 Run Modifier
Bits 16-19 Partition Number
Bits 20-23 Spare
Bits 24-31 Experiment Type
During Run1A, the Run Modifier field was not used,
the Event Builder filled in the Run Type and
Partition Number which it received from Run_Control,
and the Data Logger and/or Level 3 filled in the
Experiment Type.
3. Record No. This field indexes each event (logical
record) sequentially as it is written to tape or
disk. It is only specified for logical records
written to tape or disk and indexes records
commencing at 1 within each run. It was filled
during Run1A by the Data Logger or Express Logger.
4. Record No. of this type within Run. This field was
originally intended to index each logical record of a
particular record type sequentially as it was written
to tape. It was only specified for logical records
written to tape and indexed records commencing at 1
within each run. During Run1A, however, this field
was used to store the alphabetic characters in the
raw data file name. With this information and the
run number, the full raw file name could be
reconstructed. For example, if the run number for an
event was 46497 and the value of this field was
'00444152'X, then the raw filename for the event was
R46497AD.RAW. This information was only filled by
the Data Logger, not by the Express Logger.
5. Record Type. Identifies Logical Records as Events,
Calibration Records, Comments etc. This word has the
following fields:-
Bits 0-15 Record Type
Bits 16-31 CDF Computer ID
During Run1A, the Record Type was filled by the Event
Builder which received it from Run_Control, and the
CDF Computer ID was filled by the Data Logger or
Express Logger. Events written on B0CC06 during the
last several months of Run1A do not have the Computer
ID field filled, however.
6. Creating Process ID. This identifies uniquely the
process that was the creator of this logical record.
It is made up of the following fields:-
Bits 0-15 Process ID
Bits 16-23 Release Number
Bits 24-31 Version Number
Thus each process that generates an event record has
assigned to it a unique Identifier, being in the
range 0-65535. Additionally, each process is stamped
by Version and Release Numbers in the range 0-255.
The Version Number should be incremented for major
changes to the software, whereas the Release Number
should track such things as bug fixes etc. within a
Version. This information was filled by the Data or
Express Logger, but it is not clear that this format
was used during Run1A.
7. Creation Date. Date of creation of the record in the
form:-
65536*Years + 256*Months + Days
Where the Years should be in 4 digit form (e.g.
1983). This format has the property that it
monatonically increases with increasing date and
therefore enables easy searches to be made. This
information was filled by the Data or Express Logger
during Run1A.
8. Creation Time. Time of creation to nearest second in
the form:-
65536*Hours + 256*Minutes + Seconds
Where a 24 hour clock should be used. This format
has the property that it monatonically increases with
increasing time and therefore enables easy searches
to be made. This information was filled by the Data
or Express Logger during Run1A.
The various objects such as Record Type, Experiment Type and
Run Type etc. are further described in an Appendix. Include
files which describe the parameters for LRID are
Run$Library:LRID_Bank.Inc and C$Inc:Rec152.Inc.
6.2 EVCL Bank - EVent CLassification Bank
The EVCL Bank contains information from various sources
that serve to classify the event. It has the following Bank
Header Characteristics:-
Bank Name : "EVCL"
Bank Number : 1
Bank Data Length : 16
Bank Type : BNKTI4 (Integer*4)
The Bank contains the following information:-
Displacement Word
(I*4) Type Description
0 I*4 Trigger Number
1 I*4 Trigger Summary (1)
2 I*4 Trigger Summary (2)
3 I*4 Trigger Summary (3)
4 I*4 Trigger Summary (4)
5 I*4 Readout Times
6 I*4 TS Start Scan word
7 I*4 Components (1) Readout
8 I*4 Components (2) Readout
9 I*4 Components (3) Readout
10 I*4 Components (4) Readout
11 I*4 Components (5) Readout
12 I*4 Components (6) Readout
13 I*4 Run Conditions
14 I*4 Error Summary
Notes:
1. Trigger Number. This indicates the order of
digitisation (creation of the event) and so does not
necessarily monatonically increase since the event
sequence downstream of the Level 3 Processors may
differ from the event sequence upstream. Furthermore
there may be gaps in the Trigger Number sequence
because events are rejected by the Level 3
Processors. The Trigger Number is initialised to
zero at run startup time. During Run1A, the Trigger
Number was assigned by the Buffer Manager and filled
in EVCL by the Event Builder.
2. Trigger Summary. These four longwords contain a
summary of the Level 1, 2 and 3 Trigger decisions
such that the event may be classified. This 128 bit
summary is also used by the Data Acquisition
Interface Routines to decide whether the Event should
be made available to Consumer Processes.
The original assignment of online trigger mask
bits in the EVCL bank was described in CDF note 338.
The bit assignments were revised in September 1987
and July 1988. The most recent revision (sometime in
1991) was implemented for the 1992 run (Run1A).
For Run1A, the concept of Level 3 subtriggers
was introduced. This allowed the number of Level 3
triggers to expand beyond the 54 bits which Level 3
was allocated in EVCL. In this scheme, the full
Level 3 trigger mask was contained in the EVCD bank,
and the Level 3 bits in EVCL corresponded to
"combined" triggers, i.e. a logical "OR" of the
associated subtriggers.
During Run1A, all information except the Level 3
trigger bits and the Invalid Event Type bit was
filled by the Event Builder with data from the event
record.
Bit Bits
Field Used Name of Field Description/Comment
------- ---- ------------- -------------------
0:0 1 Always on
1:4 4 Global Accepts Level 0, 1, 2, and 3 accepts
5:5 1 Data Absent Insufficient L1/L2 Trigger info
6:9 4 Fastbus Errors
10:10 1 Invalid Event Type
11:11 1 Reserved
12:15 4 Bunch ID Hex code for bunch number
16:31 16 Level 1 CDF FRED Level 1. There is one
bit for each Level 1 trigger
defined in the physics table.
32:73 42 Level 2 There is one bit for each of
the 42 Level 2 triggers
defined in the physics table.
74:127 54 Level 3 There is one bit for each of the
54 "combined" Level 3 triggers
defined in the physics table.
See the EVCD bank description
for Level 3 subtriggers.
3. Information to construct the trigger mask was
obtained from the following sources during Run1A:
Bit Field Num Source
--------- --- ------
0:0 1 Always on - set by EVB
1:1 1 L0 global - not used in Run1A
2:2 1 L1 global - OR of bits 16-31
3:3 1 L2 global - OR of bits 32-73
4:4 1 L3 global - set by Level 3
5:5 1 Data Absent (see below)
6:9 4 FASTBUS Errors (see below)
10:10 1 Invalid Event Type (see below)
11:11 1 Reserved
12:15 4 Bunch ID (see below)
16:31 16 L1 - TFRD block 0 word 1 bits 0:15
32:73 42 L2 bits (see below)
74:127 54 L3 bits - set by Level 3
4. The Data Absent bit is set by the Event Builder when
either the TFRD bank (the source of the Level 1
trigger bits) or the TL2D bank (the source of the
Level 2 trigger bits) is missing from the event data
or the TL2D error bit is set (block 0 word 1 bit 0).
5. The FASTBUS error field set by the Event Builder is
defined as follows:
Bit Description
--- -------------------------------------
6 Scanner error
7 Error reading MX or SSP scanners
8 Error reformatting detector banks
9 Error writing event to Level 3 memory
6. The Invalid Event Type bit is set by the Buffer
Manager when an invalid event type is reported by the
Event Builder for an event.
7. The Bunch ID was obtained in the following way during
Run1A. Bits 12:14 were copied from TFRD block 0,
word 0, bits 28:30. Bit 15 was always set so that
the Bunch ID would be in the range A-F (hexadecimal).
8. The Level 2 bits were determined during Run1A by
taking a logical "OR" of TL2D block 4, words 2 and 4
to obtain the lower 32 bits and words 3 and 5 to
obtain the upper 10 bits. In principle it was
possible to handle up to 64 Level 2 triggers since
bits 0:9 of the "OR" of words 3 and 5 were copied to
bits 64:72 and bit 73 represented an "OR" of bits
10:31 in words 3 and 5. In practice, however, the
maximum number of Level 2 trigger bits used was 42.
The filling of the Level 2 bits was done by the Event
Builder.
9. Readout Times. This longword contains the following
fields:-
Bits 00-15 Scanner DONE Timer
Bits 16-31 Stale Event Timer
This is not what you get when you ACDUMPEV EVCL,
however.
10. Trigger Supervisor Start Scan. This longword
contains the following fields:-
Bits 00-01 Scanner Buffer Number
Bits 02-07 Start Scan Event Number
Bits 08-12 Reserved
Bit 13 Flag for Start Scan Broadcast
Bits 14-15 Reserved
Bits 16-31 Partition ID
This word was filled by the Event Builder which was
passed the information from the Buffer Manager.
11. Components Readout. These 6 longwords give a bit map
of the component banks which were built by the Event
Builder. For example, if component number 35 was
present in the event, then the second word of
Components Readout would have bit 3 set. The
component number for each bank is listed in the
section entitled Detector Component Bank Names which
follows.
Note that the Hardware and Software Event
Builders set these bits differently in X-mode. The
Software EVB sets the same bit for a given component
number independent of whether the bank is a D-mode or
X-mode bank (the bit corresponding to the component
number). The Hardware EVB sets the bit corresponding
to the component number in D-mode but in X-mode sets
the bit which corresponds to the internal HWEVB
representation of the X-mode bank. For some banks
this internal representation is simply the component
number plus 100. For most banks, things are not this
simple, and interested users should talk to an Event
Builder expert if they want to decode the Components
Readout words from an X-mode, HWEVB event.
12. Run Conditions. This longword contains the following
fields:-
Bit 00 Clock Source
Bits 01-02 C&S Gate
Bit 03 Unused
Bits 04-05 EVB Control
Bits 06-07 Unused
Bits 08-15 Main Ring Conditions
Bits 16-23 RABBIT Scanner
Bits 24-31 SSP
Only the EVB Control field was filled during Run1A.
Run_Control generated this word and then sent it to
the Event Builder which filled it in EVCL.
13. Error Summary. This longword was intended to contain
a set bit if there was a readout error associated
with the corresponding Scanner oriented
"pseudo-component". This word was not filled during
Run1A, however.
14. The Components Readout Words were extended on 29 Aug
1985 to accommodate a maximum of 128 Detector
Component IDs. They were extended again on 6 Mar
1986 to accommodate a maximum of 196 Detector
component IDs. At the same time, the Scanner Readout
and Residual Scanner Readout words were removed.
Include files which describe the parameters for EVCL are
Run$Library:EVCL_Bank.Inc and C$Inc:Rec152.Inc.
6.3 EVCD Bank - Full Level 0-3 Trigger Bits
This Bank has the following Bank Header Characteristics:-
Bank Name : "EVCD"
Bank Number : 1
Bank Type : BNKTI4 (Integer*4)
The EVCD bank format is:
Displacement
(I*4) Contents Description
------------ -------- -----------
0 4 Number of blocks (trigger levels)
1 P0=6 Pointer to block 0 (level 0 trigger results)
2 P1 Pointer to block 1 (level 1 trigger results)
3 P2 Pointer to block 2 (level 2 trigger results)
4 P3 Pointer to block 3 (level 3 trigger results)
5 P4 pointer to end of data + 1
--------------------------------------------------------------
Data for Block 0, (level 0 trigger results)
--------------------------------------------------------------
P0 Result bits for first 32 Level 0 triggers
. .
. .
--------------------------------------------------------------
Data for Block 1, (level 1 trigger results)
--------------------------------------------------------------
P1 Result bits for first 32 Level 1 triggers
. .
. .
--------------------------------------------------------------
Data for Block 2, (level 2 trigger results)
--------------------------------------------------------------
P2 Result bits for first 32 Level 2 triggers
. .
. .
--------------------------------------------------------------
Data for Block 3, (level 3 trigger results)
--------------------------------------------------------------
P3 Result bits for first 32 Level 3 triggers
. .
. .
--------------------------------------------------------------
Notes:
1. EVCD is not a fixed length bank. Each block contains
enough words to specify the result of each trigger in
that trigger level. For example, if there are 38
Level 2 triggers, block 2 will be two words long. If
a trigger level uses no triggers, it will still be
allocated a minimum of one word in EVCD.
2. Trigger results are recorded by a trigger's bit being
on (the trigger passed) or off (the trigger failed).
There is a one-to-one correspondence for each trigger
level between trigger result bits in that trigger
level's EVCD block and the triggers for that trigger
level in TAGC. Trigger bits are assigned starting
with the least significant bit of the first word in
each trigger level. Thus:
Trigger # 1 - bit 0, word 1 in trigger level's block
Trigger # 32 - bit 31, word 1 in trigger level's block
Trigger # 33 - bit 0, word 2 in trigger level's block
Trigger # 42 - bit 9, word 2 in trigger level's block
The remaining bits at the end of each block are set
to zero.
3. The number of triggers in each level is not specified
in this bank. Information on the count of triggers
in each level and the trigger names is contained in
TAGC.
4. Although no Level 0 are being used in the 1992 run,
EVCD reserves a block for Level 0 triggers. Future
runs may use Level 0 triggers.
5. For Run1A, there was one word for the L0 block, one
for the L1 block, two for the L2 block, and four for
the L3 block. The L1 word, bits 0-15 were copied
from TFRD, block 0, word 0, bits 0-15. The first L2
word was the "OR" of TL2D, block 4, words 2 and 4.
The second L2 word was the "OR" of TL2D, block 4,
words 3 and 5. This information was filled in EVCD
by the Event Builder.
6.4 TPID Bank - TaPe IDentification Bank
This bank contains raw tape and file name information.
It is also intended to provide a history of the parent files
for the current file. If you are creating your own data set
and you wish to update this bank for your own output files use
the A_C command: "set TPID_Updating ON". Offsets for this
bank are defined in C$INC:DSTPID.CIN. This Bank has the
following Bank Header Characteristics:-
Bank Name : "TPID"
Bank Number : 1
Bank Type : BNKTAS (ASCII Character)
The TPID bank format is:
Displacement Word
(Longwords) Type Description
------------ ---- -----------
0 C*8 Online Tape Drive Device Name
2 C*8 Raw Data Tape Label
4 C*16 Raw Data File Name
8 C*16 Next file in production chain (if it exists).
. .
. .
Notes:
1. The Online Tape Drive, Tape Label and File Name will
always be present. Input file names will be added
for each job along the production chain. The bank
data size will indicate how many files there are: 4
words (16 bytes) for the Raw Data Tape information,
plus 4 words (16 bytes) for each file name (in terms
of include file parameters TPRDFN+N*TPNWPF, where
N=the number of files). The filenames will be added
automatically by Analysis Control on output if
TPID_Updating is enabled.
2. Words not completely filled will be padded with
blanks. We suggest you use UICYAC to unpack since
this function is machine independent.
3. Filenames with more than 16 characters will be
truncated.
4. If you only want the raw data file name and TPID bank
has been dropped from your data you can get it from
the A_C function STATUS = ANGRFN(FILNAM) which uses
information in the LRID bank to reconstruct the name.
5. The TPID bank is filled online by the Data Logger(s)
and not by the Express Logger. In the data logging
configuration for run 1A in which we have multiple
Data Loggers and a single Express Logger, this means
that not all of the events in the express-line data
will have TPID filled with the online tape and file
information. Only those events which are destined
for the Data Logger running on the same Vax as the
Express Logger will have TPID filled.
next page