Some Conventions on the Filling of Arte Tables
Appendix to the official Arte Manual
--- Various Artists ---
collected by R. Mankel (mankel@ifh.de)
Last update: 3-Aug-1999
The following text is intended
to summarize conventions in the filling of Arte tables, in particular those
not addressed in the existing Arte documentation. They are intended to
clarify the situation for subsystem experts who provide code which fills
the tables, and ease the life of the reconstruction experts who have to
use the data.
Please notify me if you know missing items of importance, or points
of conflict. Please inform me also if you can supply more detailed, more
complete or more precise information on a subject.
HITB table
Structure
All HITB table entries belonging to the same GEDE plane have to form a
contiguous group in the HITB table. It is not permitted to mix entries
from different GEDE planes - in the GEDE table, for each GEDE plane the
integers gede->hit1 (1=first) and gede->hitl (l=last) must be filled, which
contain the HITB row numbers of the first and the last hit belonging to
this GEDE plane (formerly the GEPT table in Arte-01). See under GEDE
table for details.
Sorting
Since it will certainly speed up reconstruction if the hits were sorted
within the block of each GEDE plane, we adopt the following convention
for sorting the hit coordinates in each plane: increasing hitb->x
(secondary key: increasing hitb->y for pixels, third key increasing
hitb->z).
hitb->q
In case of a drift chamber hit (OT), this word has to contain the calculated
drift distance including the DTSR and all default corrections for interaction
time, time of flight and signal travelling time in the wire & electronics
(see dedicated note
for details) in cm. An additional offset of 10cm should be added to
allow for negative drift distances which may appear on certain levels of
the timing corrections. The sign bit is reserved for the L/R assignment
in Monte Carlo data.
hitb->r
In case of a drift chamber hit (OT), this word should contain the estimated
resolution, including effects from ionization statistics, drift velocity,
etc, but not such timing effects that can be resolved within the reconstruction
procedure.
hitb->gede
Should contain the ArtePointer<GEDE>
of the corresponding GEDE plane entry.
GEDE table
gede->xmin ... gede->ymax
These parameters delimit the material of the detector planes. These borders
are essential eg. for the multiple scattering correction in the tracking
packages. prism displays these borders with the style parameter
sens=n.
gede->sxmn ... gede->symx
These parameters delimit the sensitive part of the detector planes. They
are used eg. by the pattern recognition software to define search windows.
prism displays these borders with the style parameter sens=y
gede->hit1, gede->hitl
These entries are used to speed up the access to detector hits during reconstruction
or event display. The similarity of the character for one and ell
is quite a nuisance in some fonts, hence for better reading, a capital
L is used in the following paragraph, though a small ell is mandatory
under C++.
For each GEDE plane the ArtePointer<HITB>
gede->hit1 (1=first) and gede->hitL(L=last) must be
filled, which contain the HITB pointers to the first and the last hit belonging
to this GEDE plane (formerly the GEPT table in Arte-01). If there is no
hit in the plane, the convention is that gede->hit1=0 and gede->hitL=-1.
Care should be taken that gede->hit1 and gede->hitL are
*always* properly initalized in each event, even when the corresponding
detector is inactive.
gede->cos, gede->sin, gede->rot
The meaning of various coordinate systems has been illustrated eg. in the
appendix of the prism
manual . There are intrinsic ambiguities on how to distribute symmetry
operations of the rectangle on stereo angle and rotation angle. There is
no absolute convention in HERA-B how to do this, hence always the combination
of stereo angle transformation and rotation should be considered.
RSEG table
As a rule, all track candidates produced by subsystem reconstruction, which
may be subject to a later extension, restructuring, regrouping or weedout
procedure should go into the RSEG table, which is a temporary structure.
If detector hits from the HITB table have been used to reconstruct a
RSEG entry, these HITB rows should be related via the RSEG/HITB relation.
In addition, the reconstructed coordinates should be stored into an RHIT
table entry, which should also be related to the RSEG entry. Relations
should be booked such that the first hit retrieved using the Arte relation
tools corresponds to the lowest-z point rseg->zf etc. Since the orderings
of booking and retrieving of relations in Arte are reversed, this means
that the highest-z hits have to be related first.
Note: changes in the relation ordering can still occur when
tables are read in from file. This is not relevant for reconstruction as
long as it starts from the HITB/HITC tables. Introduction of an intrinsic
sorting procedure in Arte is planned.
rseg->txf
Track slope tx = tan theta_x = px / pz in lab frame, at first point.
rseg->tyf
Track slope ty = tan theta_y = py / pz in lab frame, at first point.
rseg->pf
Momentum parameter Q/p at first point.
rseg->cvf
The covariance matrix elements are packed according to the following convention:
|
x |
y |
tx |
ty |
Q/p |
| x |
0 |
1 |
3 |
6 |
10 |
| y |
|
2 |
4 |
7 |
11 |
| tx |
|
|
5 |
8 |
12 |
| ty |
|
|
|
9 |
13 |
| Q/p |
|
|
|
|
14 |
The numbers in the table give the parameter which has to be given to access
the covariance matrix element in the C/C++ interfaces. Note that the numbering
in Fortran (frseg_cvf(..,..) starts at one. Example:
cov(x,tx) =
frseg_cvf(4,rs) in Fortran, but
rs->cvf[3]
in C/C++
rseg->cmp
The cmp word is a bit pattern used to describe the detector parts contributing
to the track. It is divided into 2 sections:
-
the least significant bits give the contribution of the logical detector
parts
-
the most significant bit indicates if the segment has been killed (=flagged
as invalid)
-
the other most significant bits give the contributing hardware types (corresponding
to gede->cmp)
The meaning of the bits is defined in the structure Rsegc (here a snapshot,
look at $HB/$HBVERS/inc/arte/RSEG_cmp.hh
for actual version):
struct Rsegc
{
enum Cmp {
vxd =
0x1, /* Vertex Detector */
patt =
0x2, /* Pattern Tracker*/
magt =
0x4, /* Magnet Tracker*/
muon =
0x8, /* Muon Detector*/
ecal =
0x10, /* Ecal*/
tar =
0x20, /* Target Constraint*/
trit =
0x40, /* Trigger Tracker, betw RICH and ECAL */
bit7 =
0x80, /* not assigned yet =first bit is bit0,*/
bit8 =
0x100, /* not assigned yet =first bit is bit0,*/
bit9 =
0x200, /* not assigned yet =first bit is bit0,*/
bit10 =
0x400, /* not assigned yet =first bit is bit0,*/
bit11 =
0x800, /* not assigned yet =first bit is bit0,*/
bit12 =
0x1000, /* not assigned yet =first bit is bit0,*/
bit13 =
0x2000, /* not assigned yet =first bit is bit0,*/
bit14 =
0x4000, /* not assigned yet =first bit is bit0,*/
bit15 =
0x8000, /* not assigned yet =first bit is bit0,*/
bit16 = 0x10000,
/* not assigned yet =first bit is bit0,*/
bit17 = 0x20000,
/* not assigned yet =first bit is bit0,*/
bit18 = 0x40000,
/* not assigned yet =first bit is bit0,*/
bit19 = 0x80000,
/* not assigned yet =first bit is bit0,*/
bit20 = 0x100000, /*
not assigned yet =first bit is bit0,*/
bit21 = 0x200000, /*
not assigned yet =first bit is bit0,*/
bit22 = 0x400000, /*
not assigned yet =first bit is bit0,*/
bit23 = 0x800000, /*
not assigned yet =first bit is bit0,*/
bit24 = 0x1000000, /* not
assigned yet =first bit is bit0,*/
trd = 0x2000000,
/* TRD straw device type*/
rich = 0x4000000, /*
Cherenkov Counter device type*/
ptc = 0x8000000,
/* HiPT Chamber device type*/
msg = 0x10000000, /*
MSGC device type*/
wch = 0x20000000, /*
honeycomb wire chamber device type*/
sil = 0x40000000, /*
silicon strip device type*/
bitsign = 0x80000000 /* Kill bit, set
if segment is deleted */
};
};
rseg->fit
Gives the status or nature (track/vertex) of the entry. Definition is very
similar to that in rtra->fit. :
0: reconstructed charged
track segment'
1: reconstructed momentum to main
vertex'
2: reconstructed short decay'
3: reconstructed long decay'
4: conversion (from tracks)'
5: space point (no angular measurements)'
6: neutral particle (from ECAL)'
7: match segment'
8: charged particle direction
(from RICH)'
9: track seed (eg from TC area)'
10: conversion direction (from RICH)'
RTRA table
The RTRA table should contain the final information on reconstructed objects.
Objects in the RTRA table can still be modified by particle identification
modules or refitting procedures, but structural aspects as hit assignments
etc are immutable at this point.
If detector hits from the HITB table have been used to reconstruct a
RTRA entry, these HITB rows should be related via the RTRA/HITB relation.
In addition, the reconstructed coordinates should be stored into an RHIT
table entry, which should refer to the RTRA entry in the corresponding
attribute. Relations should be booked such that the first hit retrieved
using the Arte relation tools corresponds to the lowest-z point rtra->zf
etc. Since the orderings of booking and retrieving of relations in
Arte are reversed, this means that the highest-z hits have to be related
first.
rtra->tx, rtra->ty, rtra->pf, rtra->cvf
See corresponding entries in RSEG table.
rtra->fit
In the RTRA table, the fit flag is packed in the way : D + 100 * E with
...
D = specifier for kind of information, same meaning as rseg->fit.
E = error flag from
track or vertex fit
RHIT table
The RHIT table is used to store the reconstructed coordinates at each hit
which has been used to reconstruct and RSEG or RTRA entity. The prism
event display uses the RHIT information to display the trajectory, which
allows for a very powerful diagnostics of eg. Kalman filter algorithms.
If possible, all track parameters should be filled, but the minimum is
the x and y coordinate at the z value of the corresponding hit.
rhit->p
If available, this word should contain the value of the momentum parameter,
Q/p, where Q is the charge sign and p the total momentum in the lab frame.
For neutral particles 1/p is stored.
rhit->q
Stores the reconstructed quantity for a hit. In the drift chamber
case, it stores the reconstructed drift distance, signed according to the
resolved left/right ambiguity, which can be conveniently used to calculate
the residual.