Some notes about Translating ESPACE to Podd
R. Michaels, Nov 2009
ESPACE is our legacy Fortran code, used for the earliest experiments.
Translation of
detmap.config (ESPACE)
to
db_cratemap.dat
db_M.det.dat where M = L, R (HRS) and det = vdc, s1, s2, etc
I. Notation and History notes
The HRS used to be called "hadron" and "electron".
Later they were called "Left" and "Right". There was a
detector swap on Sept 15, 2000. The entire detector
stacks were swapped in location using a crane operation.
The reason: The R-HRS can only run to 3.1 GeV (magnet
limitation) and so the FPP was moved to the L-HRS
which can run to 4.0 GeV.
Some history:
before Sept 15, 2000
ROC1 on Left HRS. Was called "electron" arm.
ROC2 on Right HRS. Was called "hadron" arm.
ROC3 was typically the FPP crate on Right HRS.
after Sept 15, 2000
ROC1 moved to Right HRS
ROC2,3 moved to Left HRS.
At some point, I think it was for the GDH experiment,
we split the Right HRS DAQ into 2 fastbus crates.
So in recent times we have ROC1,2 on Right HRS
and ROC3,4 on Left HRS. In any case, ROC1 is
always ROC1 in the datastream, so you do NOT have
to do anything silly like rename the ROC numbers
when doing the translation of the detmap.
II. List of Database Files to Maintain
I assume the reader knows all about ESPACE's detmap.config
and database, otherwise they wouldn't be doing this job.
For Podd you'll need
db_cratemap.dat
db_L.vdc.dat and db_R.vdc.dat
db_L.s1.dat and db_R.s1.dat
db_L.s2.dat and db_R.s2.dat
and similiarly for detectors = cer (Cerenkov),
s0 (the S0 scint), a1 = A1 Aerogel, a2 = A2 Aerogel,
P = preshower (normally R-HRS), S = shower (normally R-HRS),
prl1 = pion rejector layer 1, prl2 = pion rej. layer 2,
(the pion rejectors were normally on L-HRS), and
db_urb.BPMA*, *BPMB* for beamline.
Maintain these if the detectors exist and are relevant
to you.
Some general documentation about this scheme, which I'll
assume you know, is here:
http://hallaweb.jlab.org/root/doc/database.html.
III. Crate Map
The file db_cratemap.dat is the full list of crates and slots
which are to be found in the data. The model number is given
and the expected number of channels and maximum number of data
(= "ndata" below).
For example
ADC 1881 = Fastbus ADC, 64 channels, 1 hit per channel
TDC 1875 = Fastbus high-res TDC, 64 chan, 1 hit per chan
TDC 1877 = Fastbus low-res TDC, 96 chan, usually 6 hits per chan.
(etc, etc)
If Podd finds a slot in the data that was not defined in cratemap,
or is different from what is defined, it will complain with a
printed error message. If it finds a hits outside the maximum
hit range (= ndata), it will complain. The "simple-brain" way
to fix this is to add more lines for those slots and/or increase
the "ndata" to stop the complaints.
One can discover all used (crate, slot) from ESPACE's detmap.config
and then simply build the list in db_cratemap.dat. There is some
"danger" that ESPACE didn't define all the existing slots. So you
just add them to db_cratemap.dat as the complaints occur.
Start with an existing db_cratemap.dat file for a template.
The syntax is like this:
A "#" symbol starts a comment line.
You need "==== Crate 2 type fastbus" to define the start
of a crate (number 2) and the type (fastbus or vme).
The other fields don't matter -- only slot, model,
nchan, and ndata. Leave the rest as in the example
without understanding why.
Example:
==== Crate 2 type fastbus
# slot model clear header mask nchan ndata
6 1877 1 0x0 0x0 96 672
7 1877 1 0x0 0x0 96 672
8 1877 1 0x0 0x0 96 672
IV. db_M.det.dat
where M = L,R and det = s1,s2,vdc,cer,P,S,prl1,prl2 (see section II).
The detmap syntax is (probably) the same for each detector.
Some examples should suffice.
From the summer 1999 HAPPEX run here are the S1 scint
in db_L.s1.dat for L-HRS :
Crate,Slot,1st,Last ADC chans,Beg S1 chan --------------------------------------
1 25 48 51 1 - ADCs pads 1-6 (right)
1 25 0 5 7 - ADCs pads 7-12 (left)
1 20 32 37 1 - TDCs pads 1-6 (right)
1 20 16 21 7 - TDCs pads 7-12 (left)
-1 0 0 0 0
Note: the last line has -1 0 0 0 0
This is to tell the code to stop reading
And here is for db_L.s2.dat on L-HRS :
Crate,Slot,1st,Last chans,Beg S2 chan - need equal # entries for ADC and TDC
1 25 6 11 7 1881 - ADCs pads 1-6 (left)
1 25 54 59 1 1881 - ADCs pads 1-6 (right)
1 20 22 27 7 1875 - TDCs pads 1-6 (left)
1 20 38 43 1 1875 - TDCs pads 1-6 (right)
-1 0 0 0 0
Meanwhile in db_cratemap.config you'd need
# Date/Time = Summer 1999 (HAPPEX-I)
==== Crate 1 type fastbus
# slot model clear header mask nchan ndata
25 1881 1 0x0 0x0 64 64
20 1875 1 0x0 0x0 64 512
and the corresponding lines in detmap.config:
s1adc_e 1 1 1 25 48-51 1881
s2adc_e 1 1 1 25 54-59 1881
s1adc_e 7 1 1 25 0 -5 1881
s2adc_e 7 1 1 25 6 -11 1881
s1tdc_e 1 1 1 20 32-37 1875
s2tdc_e 1 1 1 20 38-43 1875
s1tdc_e 7 1 1 20 16-21 1875
s2tdc_e 7 1 1 20 22-27 1875
In some sense, detmap.config was more elegant because in the above
example 8 lines from detmap.config got translated into a bunch of
lines spread across 3 files. C'est la vie.
Another example is for the VDCs. For example, db_R.vdc.dat
from the summer 1999 run:
###### (was called "hadron" in 1999) RIGHT VDC #############
No of Crate, Slot, First, Last chans
[ R.vdc.u1 ]
2 6 0 95
2 7 0 95
2 8 0 95
2 9 0 79
0.0 0.77852 -.0042426 -45.0 z, wbeg, wspac, wangle (m)
49.28e3 Drift velocity (m/s)
TDC Offset Values
1 1870.0 2 1870.0 3 1870.0 4 1870.0 5 1870.0 6 1870.0 7 1870.0 8 1870.0
9 1870.0 10 1870.0 11 1870.0 12 1870.0 13 1870.0 14 1870.0 15 1870.0 16 1870.0
17 1870.0 18 1870.0 19 1870.0 20 1870.0 21 1870.0 22 1870.0 23 1870.0 24 1870.0
etc ...
and matrix elements
matrix elements
t 0 0 0 -1.0027E+00 -3.3482E-01 -4.3559E-02 0.0000E-01 0.0000E-01 0.0000E-01 0.0000E-01 3
y 0 0 0 -4.7380E-03 5.3500E-03 1.5870E-03 -6.9700E-05 7.1740E-03 0.0000E-01 0.0000E-01 3
p 0 0 0 -3.2084E-03 -6.4032E-03 1.6696E-03 -9.2629E-03 0.0000E-01 0.0000E-01 0.0000E-01 3
D 0 0 0 0.0000E-01 8.4663E-02 1.1766E-02 0.0000E-01 0.0000E-01 0.0000E-01 0.0000E-01 5
and many more lines like this
corresponds to detmap.config lines :
vdc_u1h 1 2 1 6 0 - 95 1877
vdc_u1h 97 2 1 7 0 - 95 1877
vdc_u1h 193 2 1 8 0 - 95 1877
vdc_u1h 289 2 1 9 0 - 79 1877
In addition, in ESPACE the database had TDC offsets, matrix elements, etc.
These all need to be translated to the Podd database.
Similarly, each detector has constants read in from their database
files. One must look at the respective classes to see what is
read in and how it's used.
There is no all-inclusive documentation that I know of about this;
you simply have to look at the codes that read the info, and do
the work.