HTC

Aus HERMESwiki
(Unterschied) ← Nächstältere Version _ Aktuelle Version (Unterschied) _ Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Page maintainer: Rebecca

Underconstruction.gif This page is not yet ready for use or review. It is assigned to Rebecca, Caro, Alexander. The page isn't being edited right this minute, so feel free to add any information you have about this subject.

Intro

HTC (HERMES Tracking Code) is a sophisticated method (Kalmann filter) to reconstruct tracks in the forward Spectrometer taking into account the target magnetic field, the passage through materials (multiple scattering) and the Beam position. HTC provides a parametrization of every track at any z position. The vertexing routines provide track-to-beam and track-to-track crossings (up to 3). HTC gives back tracking quality parameters, vertexing probabilities and covariance matrices. HTC uses the spacepoints found by HRC (the traditional HERMES ReConstruction method). Differences between HRC and HTC arise from the different track fitting. Because HTC has no built-in trackfinder engine, it will neither lose nor gain new tracks compared to HRC (hm... unless one starts applying probablity cuts!). HTC just adds complementary information about tracks and vertices.
Some more details about HTC are compiled below. Some information may also be found on the Tracking Corrections page.

Essentials

  • An example code which explains how to extract HTC-related information from uDST files, together with an extensive README file is available as a self-contained bundle
/hermes/r26/htc/ucode-1.6.tar.gz

This README file contain most of the essential information needed to beginning to running HTC.

  • Also see the Code Repository section below for links to emails about HTC in Fortran code.
  • Which data are available in HTC format is compiled on the Productions page.

User tips and tricks

Reading HTC

To recover the usual HRC tracking parameters in the new HTC productions (those are: 02d1, 03d1, 04d1, 05d1; 06e1, 07c2 in the end of 2009), the user has to read the new table smTrackSave. If the user does not apply any code changes and continues to read the track parameters from g1Track and smTrack, he or she will use HTC track parameters determined at z=12.5 cm for the short target cell data (z=0 cm for the long target cell data). This is not the best choice. If the user decides to use HTC, he or she should rather call the vertex finder in his or her user code.

The Vertex Finder and track topologies

The vertex finder searches for the common vertex with the beam and/or other tracks in the event. An example how the vertex finder is called in a C-code using HANNA can be found in the user code of Alexander (see Code Repository). Each analyzer must make his/her choice about the track topology typical for his/her events, for example "1-track-to-beam" for a DVCS analysis, which desires exactly one track in the event. Up to maximum three such crossings are provided, where one of the tracks can be including the beam ("track-to-beam"), or only tracks of produced particles are considered ("track-to-track").

Track charge

The momentum "P" stored in t_track_flavor is always positive (not signed like the g1Track equivalent), so you will need to use "charge" in the t_htc_vtrack structure to get the particle charge

Flavors

The HTC parameterizations are written as _TF_*, where * is some string, and they are referred to as track flavors. They meet the different requirements in various analyses.

Vertex constrained parameterization
  • _TF_HTC_ is the vertex-contrained HTC parameterization. If the user chooses it, the track parameters are modified according to the found vertex. This option can fail more often than the track flavor _TF_HTC_UNBOUND, resulting in some loss of statistics.
  • _TF_HTC_UNBOUND_: in this parameterization, the track parameters are not recalculated, which is thus the technically safer option than _TF_HTC_.
TMC related values

NEEDEXPERT

Fiducial cuts with HTC

When calculating the fiducial volume one must take special care to get the correct track parameterizations.

  • The flavor _TF_FIDUCIAL_VOLUME_CUT_FRONT_ should be used to get
     xoff    = HTCtrack->S[0];     // offset at target
     yoff    = HTCtrack->S[1];
     rTheta  = HTCtrack->theta2beam;
     rPhi    = HTCtrack->phi2beam;
  • The flavor _TF_FIDUCIAL_VOLUME_CUT_BACK_ should be used to get
     xpos   = HTCtrack->S[0];   // xposition of backtrack at magnet center
     ypos   = HTCtrack->S[1];
     xslope = HTCtrack->S[2];   // slope of back partial track
     yslope = HTCtrack->S[3];


Vertex and Track Probabilities

HTC provides for each track two indpendent probablilities:

  • Track probability. The track probability reflects the Fehler beim Parsen (Konvertierungsfehler. Der Server („https://wikimedia.org/api/rest_“) hat berichtet: „Cannot get mml. Server problem.“): {\displaystyle \left.\chi ^{2}\right.} or "goodness" of the track fitting. It compares the measured and calculated track coordinates, and the better the two match together, the higher the probability is that the object is actually a track. This probability is independent of the vertex.
  • Vertex probability. The new feature in HTC is that it does not only look to individual tracks when determining the track parameters. Rather it takes into account the whole topology of the event by trying to match together the vertices of all tracks in a given event. The vertex probability gives a measure of how well the vertices fit together and how probable it is that the true vertex has been found.
  • All users need to look at distributions of the relevant probabilities and vary the cut on these probabilities to find the appropriate cut. The probability cuts cannot be directly obtained from MC because their distributions in data and MC are different. The latter assumes a perfectly aligned beam, for which the distributions are flat (if the errors are correctly taken into account).
    • A good place to start is 0.01 (1%).
    • The F2 team used a probablility cut of >0.0001. This cut was determined comparing cross sections in Monte Carlo and real data.
    • The cosphi team uses a probability cut of >0.01 after confirming that tightening the cut to up to >0.05 does not change their amplitude results.
    • DVCS: NEEDEXPERT:Jennifer
  • Users will generally notice a (~10%) drop statistics when using HTC due to the vertex probability cut, which is not present in HRC at all.

Counting DIS events in a SIDIS analysis

  • NEEDTEXT Some comment about how to count DIS when your analysis uses 2-trk vertex tracking

User example: how to implement the vertex finder (DVCS)

The vertex finder can easily be implemented into a HANNA-based C-user-code. Find the tarball as described below in the Code Repository, copy it in your private directory, unzip it (gunzip ucode-*.tar.gz), extract its contents (tar -xvf ucode-*.tar), cd ucode-* and have a look at the README and the file ucode.c.

  • Open your analysis code and #include all required header files (*.h) in your *.c file.
  • Scroll to your user_event() routine (or if you are not using HANNA, to the corresponding place where you process an event) and then to the place where you loop over all tracks. For a DVCS analysis, the suitable track topology is 1-track-to-beam-vertex. The common track-beam vertex is fetched by calling
get_htc_beam_vertex(1,id,&vtx)

separately for each track of the event, i.e. also for events with more than one track. The 'single lepton' selection follows only later in the code and I think for DIS normalization it is OK to look to all tracks of an event independently. If no common vertex with the beam is found for this track (i.e. a non-zero value is returned, which happens in about 1.3% of all tracks), the track is still kept despite it has no track parameters and the event is subject to all cuts.

  • The HTC vertex-constrained parameterization
_TF_HTC_

is used. It should be checked at some point if instead using 

_TF_HTC_UNBOUND_

makes any difference.

  • Then the HTC track parameters from the
vtrack->

or 

vtx.

structures are read in. This is straightforward after a look to the example in ucode.c.

  • The front and back track HTC parameterizations are fetched by the track flavors
_TF_FIDUCIAL_VOLUME_CUT_FRONT_

resp. 

_TF_FIDUCIAL_VOLUME_CUT_BACK_

They are needed for the fiducial volume cut of tracks ("Andy's FVC").

  • The HRC tracking parameters are read for each track from the table smTrackSave.
  • Note that the normal user does not need to understand the ADAMO structure coming along with HTC.

Analysis notes and studies

NEEDTEXT - studies that people have done, links to analysis reports, conclusions

  • Improvements in anything?
  • NEEDEXPERT - Exotics group
  • NEEDEXPERT - Not possible to use HTC in F2 analysis
  • With the present set of tracking detectors, the beam slopes cannot be determined better than 100-200mrad. The top and bottom spectrometer halves are believed to be in the same coordinate system. (Alexander, please confirm. Noted down in the cosphi pre-release discussion 16.12.2009)
  • Analysis of the 2006/2007 DVCS data
    • NEEDEXPERT:Caro add some more words here
    • Comparison of HRC and HTC statistics
    • Failure of the vertex finder
    • Track level and histogram level comparisons of HRC and HTC
    • Resolutions from MC, comparing HRC and HTC

More Info

Alexander's Presentations

Code Repository

  • HTC user code:
/hermes/r26/htc/ucode-1.6.tar.gz
Abgerufen von „https://hermes-wiki.desy.de/index.php?title=HTC&oldid=11051“