Data description for TOF
W.J. Llope, C. Stokely, K. Kainz
Rice University

Draft - 8/12/97
Version 1 - 8/20/97
Version 2 - 8/24/97
Version 3 - 9/19/97


Here's a brief description of some files useful for unpacking and analyzing
TOF data in E896. This document will be updated whenever necessary so that
it can always serve as the single source of information needed to get at TOF
data in E896.

The format for the configuration files necessary for unpacking YBOS data is
space delimited ascii text in that format expected by the routine Raw of
the STAF PAM e896. The file containing this configuration information (i.e.
crate/slot/subaddress for the ADC and TDC channel for each slat) for the 
TOF system is
	/afs/phy.bnl.gov/e896/files/tof/tof-map.txt.
Its format and content is described first below.

At the spring 1997 collaboration meeting (LBL), the collaboration decided that
the format for detector element descriptions (sizes, positions, angles, etc.)
to be used both geant- and STAF-based codes is ascii files of fortran
namelists. This file is
	/afs/phy.bnl.gov/e896/ref/all/geant/geo/tof.geo 
Its description is given second below.

A third file format with TOF positioning information is also maintained for
convenience only. This file is
	/afs/phy.bnl.gov/e896/files/tof/tof_holepos_geant.dat 
and it is described third below.


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	Please direct any questions/comments about these configuration 
	files or the present description to llope@physics.rice.edu.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


-------------------------------------------
/afs/phy.bnl.gov/e896/files/tof/tof-map.txt
-------------------------------------------

This file is used to instruct Raw.c on the association between a given
crate/slot/subaddress and the corresponding slat/PMT/word, where word is
either ADC or TDC data.

The file is ascii text and the first ten lines look like this:

* Wall   Slat  PMTloc  TDCslot  TDCchan  ADCslot  ADCchan  Crate  Hole
* ----   ----  ------  -------  -------  -------  -------  -----  ----
    1      7       1       25         43      9       87      8     33
    1      7       2       23         50      7       66      8     33
    1      8       1       19         12      9       86      8     34
    1      8       2       23         51      7       67      8     34
    1      9       1       19         11      9       85      8     35
    1      9       2       23         52      9       56      8     35
    1     10       1       19         10      9       84      8     36
    1     10       2       23         53      9       57      8     36

The first two lines are comments for ease in reading this file. The first
column is 'Wall', which is 1 for McGill slats, and 2 for the Rice slats. The
blackened PMTs, of which there are three at the moment, have Wall=3.

Two words deserve definition at this point. 
	Slat: A number uniquely identifying a specific TOF counter
(scintillator/pmt/base assembly), which doesn't change even if the particular
counter is repositioned or removed for some experimental configuration.
	Hole: A number uniquely identifying a position in the TOF mounting 
structure where one could place a TOF counter. 

The Slat<->Hole mapping may change for good reason between running periods.
For example, certain McGill slats may be moved in or out of the area where
where the beam goes depending on the beam species. For each such
configuration, the file tof-map.txt must reflect the correct Slat<->Hole
mapping used on the floor. It is therefore obvious that, as e896 evolves, more
than one version of tof-map.txt will need to be available for analyses of TOF
data. These appropriately named versions will be provided as necessary and
maintained by us. One would need only to change the definition of the
environment variable TOF_LAYOUT to instruct the Raw routine on the
identity of the proper Slat<->Hole and electronics mapping.

The second column is labelled 'Slat' and it corresponds to a Slat number.
The ninth column is labelled 'Hole' and it corresponds to the Hole number
for the Slat numbered in the second column.

All TOF scintillators are arranged vertically and PMT double-ended. The third
column is PMTloc, where 1 corresponds to upper PMT, and 2 corresponds to lower
PMT (for the Slat numbered in the preceeding column).

The next five columns are the slot and subaddress map for the TDC and the ADC
channels, respectively, in the TOF Fastbus crate (Crate number 8 for all TOF
channels).

Slat numbers go from 
      1-154 (Wall=1)   McGill slats
      1- 40 (Wall=2)   Rice slats
      1-  x (Wall=3)   Blackened PMTs (note X=3 right now)

Hole numbers increase from +x (beam-left) to -x (beam-right), and 
      1- 26            Rice beam-left positions
     27-186            McGill positions
    187-200            Rice beam-right positions

Some comments on the expected evolution of tof-map.txt are necessary. The
present version of tof-map.txt (/afs/phy.bnl.gov/e896/files/tof/tof-map.txt)
applies to the p-97 run configuration. A version to be used for the Au-97 run
will be provided shortly. Generally speaking, it differs from the p-97 run map
in that ~10 mcgill wall slats were removed to make a hole for uninteracting Au
beams. Also, at least one more version of tof-map.txt will be necessary for
the Au-98 run. So, the filenames that we'll use are:
 	/afs/phy.bnl.gov/e896/files/tof/tof-map_Au97.txt
	/afs/phy.bnl.gov/e896/files/tof/tof-map_p97.txt
	/afs/phy.bnl.gov/e896/files/tof/tof-map_Au98.txt
If more than one tof-map is needed for the Au-98 run, we'll give
them similarly descriptive names.

When the file tof-map_Au97.txt is available (shortly), the file presently
called tof-map.txt will be renamed to tof-map_p97.txt. The way in which one
specifies the map file that Raw should use is via the environment variable
TOF_LAYOUT (see the file /afs/phy.bnl.gov/e896/login/stafsetup). The default
value for TOFLAYOUT defined by sourcing stafsetup is
	/afs/phy.bnl.gov/e896/files/tof/tof-map.txt,
so, a soft link called tof-map.txt will be made, which will be maintained to
always point at the version of tof-map applying to the most recent set of
experimental data. Staf'ers intending to study previous data sets would need
to set the environment variable TOFLAYOUT appropriately before starting their
STAF executable, i.e.
	> setenv TOFLAYOUT /afs/phy.bnl.gov/e896/files/tof/tof-map_Au97.txt
	> time tofStaf 
It would not be hard, of course, to revise Raw so that it would pick which
version of tof-map.txt to read based on the Run number (for example), in which
case there would be no possibility that users apply the wrong map to a data
set.

Click HERE for comments on how Raw uses 
tof-map_xxx.txt to fill the STAF table rawTof.

-----------------------------------------------
/afs/phy.bnl.gov/e896/ref/all/geant/geo/tof.geo
-----------------------------------------------

The file is in the standard E896 fortran Namelist format, which was agreed
upon by the collaboration as the sole source for detector element size,
positioning, and angle information for both geant and STAF software. This file
is maintained as part of the geo package under E896 CVS control. That is, it
is contained in the file .../geant/geo/tof.geo when one checks out the geant
package from CVS. A copy of the file for perusal is also kept in the reference
area - i.e. /afs/phy.bnl.gov/e896/ref/all/geant/geo/tof.geo. This namelist can
be trivially read into a geant executable that includes the standard
mcg_sys_geom namelist-read routine, and from there displayed and/or simulated.

The tof.geo file is generated using a Fortran program ("nml_create_tofgeo")
which is based on those used in STAR to define detectors before the advent of
AGI. All of the namelist formatting and writing in the proper order for
mcg_sys_geom is taken care of by separate routines, so the defining all of the
detector geometry parameters needed to generate the namelist are done in a
smaller routine that is easy to read and debug.

Two input files are used by this program. One is a file obtained from Roger
Lacasse which contains the positions, expressed in microns, of the McGill wall
slats as they sat in E877. As the frame holding the slats themselves was not
changed when we completely tore down and rebuilt the mounting superstructure,
the same relative positioning and relative angle information between McGill
slats still applies for the E896 implementation. This information is thus used
to position all of the McGill slats in E896 given the positions and Hole
numbers of the two most extreme slats in the wall, which was measured by us
with a plumb bob and a tape measure. Basically, nml_create_tofgeo just
translates and X-Z rotates the E877 numbers so that the extreme slats are
in the right spot, then the "exact" relative slat position and angle 
information is taken directly from the rotated and translated E877 numbers.
This way of defining the wall position "crudely", but the slat positions
within the wall "exactly", bears on the error estimates on the positioning
information that is described later in this section. 

The other file used by nml_create_tofgeo is the appropriate tof-map.txt. This
correctly synchronizes the positions of "live" slats in the experiment with
those in the simulations via the namelist tof.geo. The existance of a Slat for
a given Hole number in tof-map.txt is used in nml_create_tofgeo to enable the
definition of the simulated slat in the namelist.

It is important to note though that the presently available tof.geo puts slats
in all possible 160 McGill holes, even though the most we have ever run with
is 154. This more general definition is reasonable at the moment, since dead
or missing slats can just as well be masked in STAF or PAW as a cost of <1% of
the data volume. However as more tof-map.txt files become available (see end
of previous section), there will then necessarily be an equal number of
tof.geo files. As keying to a particular tof-map.txt is necessary to STAF a
specific run, keying to a particular tof.geo is also necessary to simulate in
geant the performance of the TOF for the specific configuration used in that
run.

We estimate the following errors on the detector positioning information
that is contained in the namelist tof.geo. 
    McGill wall:
       position of wall in E896 coordinate system:   1 cm (conservative)
       relative positions of slats within wall:    0.5 mm (conservative)
    Rice walls:
       position of wall in E896 coordinate system:   5 cm (conservative)
       relative positions of slats within wall:      1 mm (conservative)
As further information on the wall/slat positioning becomes available,
i.e. from surveys, the namelist file tof.geo will be updated to
reflect the (presumably) more accuracte numbers.

At Rice, a routine was added to the e896_geant package which writes the file
tof_holepos_geant.dat (see next section below) in a readable format using the
slat positioning information contained in the namelist tof.geo. The file is
maintained only for our convenience in the development of certain online
and/or visualization codes, and it is described in the following section. It
contains no dimension information, nor does it contain information on
the angles subtended by the faces of the slats in the e896 coordinate system.
Both of these quantities are non-zero for every single slat in the system. All
of this information is of course available from the namelist tof.geo, as
requested by the collaboration.


-----------------------------------------------------
/afs/phy.bnl.gov/e896/files/tof/tof_holepos_geant.dat
-----------------------------------------------------

As mentioned above, this file is maintained solely for convenience, as the
fortran Namelist file tof.geo is by collaboration definition the correct
source of TOF size and positioning information. Also as mentioned above, this
file is presently written by the modified geant using as input the information 
defined in the tof.geo namelist file.

This file has the following format:

     1    1    1    185.16      0.00    730.70    \
 [snip]                                            }  Rice, beam-left
    26    1   26     63.03      0.00    775.23    /
    27    2    1     71.79      0.00    865.75    \
 [snip]                                            }  McGill, wide, beam-left
    61    2   35     15.76      0.00    864.76    /
    62    3   36     14.37      0.00    866.41    \
 [snip]                                            }  McGill, thin
   100    3   74    -22.56      0.00    863.89    /
   101    4   75    -23.71      0.00    862.06    \
 [snip]                                            }  McGill, wide, beam-right
   186    4  160   -162.34      0.00    841.03    /
   187    5    1   -114.06      0.00    758.86    \
 [snip]                                            }  Rice, beam-right
   200    5   14   -175.76      0.00    731.23    /

The first column is the Hole number, which corresponds to the numbers in the
last column of the file tof-map.txt (described above). The second column is
used to determine the slat dimensions in the following manner:

    Column 2    Slat Type          Slat Dimensions (XxYxZ, in cm)
    --------    ---------          ------------------------------
     1          Rice (beam-left)   5.0 x 100 x 1.5
     2          McGill wide        1.7 x  80 x 1.0
     3          McGill narrow      1.0 x  65 x 1.0
     4          McGill wide        1.7 x  80 x 1.0
     5          Rice (beam-right)  5.0 x 100 x 1.5

The dimensions in the table above are full widths.

The third column is simply a counter within each group of holes. The fourth,
fifth, and sixth columns are the X, Y, and Z, positions in centimeters in the
E896 coordinate system, respectively, of a Slat mounted in the given Hole
(first column).