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 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.