QwTracking

Files
file	nodenode.h
	Definition of nodenode which links treenodes to their siblings.
file	QwBridgingTrackFilter.h
	Definition of the track filter for the bridging methods.
file	QwMatrixLookup.h
	Definition of the matrix lookup bridging method.
file	QwRayTracer.h
	Definition of the ray-tracing bridging method for R2/R3 partial tracks.
file	QwTreeEventBuffer.h
	Definition of the class that reads simulated QweakSimG4 events.
file	shortnode.h
	Definition of a shortnode, the short version of a nodenode.
file	shortnode.h
	Definition of a shortnode, the short version of a nodenode.
file	treenode.h
	Definition of a treenode which contains the bits that make up a tree pattern.
file	QwSimTracking.cc
	Example of the QwTreeEventBuffer class to read QweakSimG4 events.
file	QwTracking.cc
	This is the main executable for the tracking analysis.
file	nodenode.cc
	Definition of nodenode which links treenodes to their siblings.
file	QwMainDetector.cc
	This is the main executable for the tracking analysis.
file	QwRayTracer.cc
	Raytrace in magnetic field to bridging R2/R3 partial tracks.
file	QwTrackingTreeRegion.cc
	Implementation of the container for the pattern databases for each detector region.
file	QwTreeEventBuffer.cc
	Implementation of the class that reads simulated QweakSimG4 events.
file	shortnode.cc
	Definition of a shortnode, the short version of a nodenode.
file	shortnode.cc
	Definition of a shortnode, the short version of a nodenode.
file	treenode.cc
	Definition of a treenode which contains the bits that make up a tree pattern.

Namespaces
	QwTracking
	Contains tracking-related objects.

Data Structures
class	QwPMT_Channel
class	QwDelayLine
class	QwDetectorInfo
class	QwDriftChamber
class	QwDriftChamberVDC
class	QwHitContainer
class	QwMainDetector
class	QwSubsystemArrayTracking
class	QwTrackingTreeSort
	This module is used to identify good track segments versus ghost tracks/hits. More...
class	QwTriggerScintillator
class	QwTracking::nodenode
	A nodenode is used as a pointer which links treenodes to their siblings. More...
class	QwBridgingTrackFilter
	Track filter for the bridging methods. More...
class	QwEventHeader
	Contains header information of a tracked event. More...
class	QwKinematics
	Kinematic variables. More...
class	QwEvent
	Contains a tracked event, i.e. all information from hits to tracks. More...
class	QwGeometry
	Collection of QwDetectorInfo pointers that specifies an experimental geometry. More...
class	QwHit
	Hit structure uniquely defining each hit. More...
class	QwHitPattern
	Hit patterns used in the tracking tree search. More...
class	QwMagneticField
	Magnetic field map object. More...
class	QwPartialTrack
	Contains the straight part of a track in one region only. More...
class	QwQuartzBarLight
	Contains header information of a tracked event. More...
class	QwTrack
	Contains the complete track as a concatenation of partial tracks. More...
class	QwTrackingTree
	Creates and manages the treesearch pattern database. More...
class	QwTrackingTreeMatch
	Module that matches track segments for pairs of wire planes. More...
class	QwTrackingTreeRegion
	A container for the pattern databases for each detector region. More...
class	QwTrackingWorker
	Controls all the routines involved in finding tracks in an event. More...
class	QwTreeEventBuffer
	Read simulated QweakSimG4 events and generate hit lists. More...
class	QwTreeLine
	One-dimensional (u, v, or x) track stubs and associated hits. More...
class	QwVertex
	Contains vertex information. More...
class	QwTracking::shortnode
	Similar to a nodenode. More...
class	QwTracking::shorttree
	Similar to a treenode. More...
class	QwTracking::treenode
	A treenode contains the bits that make up a tree pattern. More...
class	Uv2xy
	Converts between (u,v) and (x,y) coordinates. More...
class	VQwBridgingMethod
	Interface to the various bridging methods. More...
class	VQwsubsystemTracking
	Base class for tracking subsystems. More...
class	VQwTrackingElement
	Virtual base class for all tracking elements. More...

Detailed Description

Overview of the Qweak Track Reconstruction package

The Qweak Track Reconstruction package (QTR) was originally based upon software developed for the HERMES experiment. In both experiments, charged particles pass through drift chambers without the presence of a magnetic field. In each experiment, upstream and downstream straight track segments are connected by a magnetic field inwhich there are no detectors. Therefore track reconstruction is performed separately for the upstream and downstream regions, and then a fit is performed to match the tracks in the magnetic field.

The main difference between the experiments in terms of track reconstruction, is that in HERMES there were multiple types of tracked particles, and thus particle identification was an additional requirement. in Qweak, only electrons will be tracked, therefore there is no need for particle identification algorithms. Additionally, due to the nature of the Qweak experiment, precision is of the utmost importance. This requires the development of calibration routines which include but are not limited to: fitting drift-time-to-distance functions, detector alignment, detector plane alignment, and possibly drift chamber wire alignment.

QTR makes use of pattern recognition in order to identify good tracks from a set of hits. In the simplest case, a single electron track produces a nominal set of hits in each drift chamber (DC) wire it passes. In reality, DC wires may suffer from various inefficiencies. They may fire all the time, without the presence of a charged particle track, giving rise to false hits. They may also fail and not fire at all, creating gaps in the data set. Additionally, in the case of multiple tracks, pattern recognition must be used to identify which hits belong to which track. While it is not currently the plan to run at a beam current which would produce a significant percentage of multi-track events, the reconstruction software should be flexible in this aspect so that running conditions are not constrained by software capabilities.

Differences between Region 2 HDCs and Region 3 VDCs

Due to the fundamental differences between the HDCs in region 2 and the VDCs in region 3, they are treated differently in the tracking code too.

The region 2 HDCs

In the HDCs (Horizontal Drift Chambers), there are four planes of wires in each direction, and the nominal particle track is very rougly perpendicular to the wire planes. Due to the HDC design, an individual hit determines the distance of closest approach to the wire. From this distance and a rough calculation of the entrance angle, the position of ht eparticle on the wire plane may be determined. Therefore, each plane is divided into a bit array with the hit position(s) corresponding to the 'on' bit(s) in the array. The 2D pattern is then created from the set of planes that lie in the same direction.

The region 3 VDCs

The VDCs (Vertical Drift Chambers) are constructed with an array of signal wires that lie between two cathode planes. The chambers are oriented such that the nominal particle trajectories traverse four to eight of the drift cells in a single plane. Given an approximate entrance angle, the drift time (measured using a TDC) is correlated with the distance of the track to the wire, on a line between the wire and the cathode plane. Therefore, each plane of wires has its own 2D bit pattern, consisting of the wire number on one axis, and the drift distance on the other axis. Currently, the bit pattern contains eight columns, corresponding to the maximum number of hits for ideal tracks.

Due to the large number of sense wires, limited space and funding, and the complication of rotating the detectors in the lab, each TDC measurement will correspond to a group of eight non-consecutive sense wires. The multiplicity arising from this setup may generate ambiguities in the identification of the correct wire hit by an electron. In the case of multiple tracks in a single event, these ambiguities must be resolved by the tracking code.

In the region 3 part of the tracking code method QwTrackingWorker::ProcessHits, there is a loop over the two VDC planes. The QwTrackingTreeSearch::TsSetPoint method is called for each plane to map the hits in the event to a bit pattern. Next, the QwTrackingTreeSearch::TsSearch method is called to find all matching patterns for each plane. Finally, TreeCombine::TlTreeLineSort is called to obtain the track segment candidates for this wire plane.

TreeCombine::TlTreeLineSort first matches a subset of the hits in the event to the matching patterns. This is done by checking which hits are closest to the bits in the patterns. Once the correct hits are identified, they are fit to a line and a chi-square value is calculated. TreeCombine::TlTreeLineSort then uses the treesort class to sort the track candidates by likelihood. Each track candidate is strung together into a linked list and is available to the QwTrackingWorker::ProcessHits.

At this point there are sets of track candidates in the upstream and downstream planes of a single wire direction. QwTrackingWorker::ProcessHits next calls the QwTrackingTreeMatch::MatchR3 method which loops over the upstream and downstream track candidates to identify which best line up according to their slopes and intercepts. QwTrackingTreeMatch::MatchR3 returns a new set of track candidates which represent both planes in the same wire direction. The loop over the two wire directions is ended, with tracks in the u and v directions.

Code Overview

The Qweak Tracking code is built around four main tracking modules:

• QwTrackingWorker (the main entry point)
• QwTrackingTreeSearch
• QwTrackingTreeCombine
• QwTrackingTreeSort
• QwTrackingTreeMatch

The organization is done by the module QwTrackingWorker.