How to add a new detector

The addition of a new tracking detector requires only a rather small number of steps. The tracking code is quite generic, so the structure of the code should hardly be affected at all. Whenever reference to a specific example helps to illustrate the necessary tasks, the new detector will be referred to as NEW (Non-Existing Wire chamber).

First of all, the geometry definition and declaration of a sensitive volume have to be added to the GEANT declarations in Brahms. A new detector ID, $ID\_NEW$ , has to be defined, plus possibly subcomponent (layer) IDs $ID\_NEW1$ , $ID\_NEW2$ etc. The generic subdetector ID $ID\_NEW$ should be a multiple of 100 (Brahms detector ID convention). Subcomponent IDs can then take any useful value between $ID\_NEW+1$ and $ID\_NEW+99$ . Details of how to create a detector in GEANT are not discussed here.

The track reconstruction system has to know what type of track reconstruction (ideal or realistic) it is supposed to use for this detector. This requires an entry in the

array. Increase the array size of

in the TKFFREAD keep sequence in TKSTEER by one. The FFKEY statement in TKINI has to changed accordingly, and the upper limit of the DO loop that sets the default values in the same routine has to be increased. In TKSETR, the detector name array

has to be extended by one entry with the name of the new detector. The increased number of detectors has to be taken care of in two DO loops in this routine.

The creation of GEANT hits for the new detector has to be steered by a routine similar to TPCDHIT et al. -- just add a routine NEWDHIT to account for hits from this detector and make sure it is called from GUSTEP.

The next step is to provide means to read the hits from the new detector and make them available for the track reconstruction routines. A new subroutine TKHNEW is needed which uses the generic hit read routine TKGHIT to retrieve hits and store them in the tracking data arrays. The new routine should be modeled after TKHTPC etc. A call to this routine has to be added to TKTREV.

TKHNEW must also take care of adding an adequate amount of noise hits to the hit data banks. The implementation of noise requires a few additional steps. First of all, a new variable

(or, for a multi-layer detector, variables

, ...,

) has to be added to the TKNOISEPAR sequence in TKSTEER. Add initializations of this variable/these variables to TKSETR in TKSTEER, depending on beam energy (

) and magnetic field (

). This is done in a huge IF-ELSE-statement.

During track reconstruction, the information provided by the new subdetector has to be presented in DELPHI TE format (see Table

). For detectors without local pattern recognition, this is easily achieved by using the generic dummy pattern recognition routine $\rm LP_DET$ in DUMPATREC. See $\rm LP_FCH$ for usage of this routine. For a detector without capability of local pattern recognition, $\rm LP_DET$ will just return all the hits in TE format. The routine $\rm LP_NEW$ calling $\rm LP_DET$ for the new detector must then be called from TKTREV. In order to call $\rm LP_DET$ , one needs the Brahms detector ID of the new detector (or, respectively, all subcomponent IDs), the detector type (plane, cylinder, cone) and the DELPHI measurement code to be assigned to the TE - both for hits and possibly fitted tracks. See Table

for the definition of this code. $\rm LP_SI$ might give nice examples for most detector types. $\rm LP_DET$ furthermore requires a pattern recognition code. A value larger than zero asks $\rm LP_DET$ to store hits and tracks (if any). Values below zero prevent hit TEs from being created -- only fitted tracks are returned. So far this option is only used for the TPC. Since no attempt is done to improve the TPC pattern recognition at a later stage of the track reconstruction, storage of all TPC hits is considered an unnecessary burden. Multi-layered detectors whose hits are to be used in the track reconstruction must have a separate detector ID for each layer, otherwise track reconstruction will simply not work: the DELPHI code takes at most one TE per detector ID to construct a track candidate. $\rm LP_NEW$ has to be called in TKTREV close to where the corresponding calls are for the existing subdetectors.

For a detector with local pattern recognition capabilities the action at this point should depend on the entry in the

array associated with the detector. A value of 1 is used for realistic pattern recognition. This requires a custom routine which should read hits with the routine TKREAD and return collections of hits to be fitted as tracks using TKMKTE. A value of 2 in

asks for ideal pattern recognition. If the code is implemented as described above for detectors without local pattern recognition, everything should work automatically. $\rm LP_DET$ fits tracks whenever possible, i.e. it attempts to fit tracks whenever one track leaves at least three hits in the respective subdetector. Depending on the value in

, either the custom realistic pattern recognition routine or $\rm LP_NEW$ have to be called in TKTREV close to where the corresponding calls are for the existing subdetectors.

At this stage, everything should be in place to provide the track merging processor DELSEARCH with the information it needs. However, DELSEARCH itself requires a couple of adaptations for the new detector. First of all, a detector number has to be assigned to the detector. This has to be done in the FSFPARAMS sequence in DELSEARCH. Add a new parameter definition for $i\_NEW$ to the existing list of parameters $i\_TPC$ , $i\_FCH$ etc. If the new detector is capable of local pattern recognition, one might want to start the merging process from this detector (among other strategies, of course). In this case, $i\_NEW$ has to be inserted early, before $i\_SCAN1$ . All detectors capable of functioning as seed for the track merger have to be listed in the beginning, and their total number

(max primary detectors) has to be increased by one when adding the new detector there. For non-primary detectors $i\_NEW$ must be larger than all $i\_SCANn$ values, and

stays the same. In any case, the total number of detectors, indicated by

, must be increased by 1. Each submodule ID requires its own parameter, i.e. $i\_NEW1$ , $i\_NEW2$ etc. if applicable. (Applicable means that the new detector has submodules and the submodule hit TEs are stored in the tracking banks for usage in the merging processor. See comments on $\rm LP_DET$ usage given earlier. E.g. there are no individual parameters for all TPC pad rows, because individual TPC hits are not passed on to the merging processor.)

DELSEARCH requires some more information on the new detector in the FSFPARAMS sequence. The variable

needs an entry for the new detector. It describes the printing order of detectors whenever track candidates are shown on the screen.

needs an entry for the new detector to tell DELSEARCH what name to print for the new detector. The variable

needs another detector ID for the new detector. Track candidates are described as bit patterns of contributing subdetectors in DELSEARCH. Therefore each detector (submodule, layer) needs to have a unique bit number between 0 and 31 assigned. The values of 0, 1, 2, 30 and 31 are reserved for internal purposes. The value of $detid(i\_TPC)$ =5 should never be changed.

The routine FSFINP in DELSEARCH is responsible for reading all subdetector TEs from the tracking banks. It needs to know the correspondence of Brahms ID $ID\_NEW$ ( $ID\_NEW1$ , ...) and $i\_NEW$ . Add this to the long IF-ELSE-statement. The correspondence between Brahms ID and DELPHI ID ( $detid(i\_NEW)$ ) should be taken care of automatically in the routine DELDET in TKSTEER. In case the identification of subdetectors in DELSEARCH fails to work, this routine is a good place to check.

A diagnostic routine in DELSEARCH, FSFPRINTTE, also wants to know a detector name. It should be added to the IF statement in that routine.

The next issue is to tune the merging algorithm itself. FSFANA3 in DELSEARCH loops over all possible subdetector combination using a large number of nested DO loops. Find out what the maximum number of tracking subdetectors is a track can traverse in the detector. In standard Brahms, this is 5 CCD layers, SIT1, SIT2, TPC, FCH (TPC and FCH do not return individual hits, so there is only one TE for the full detector), i.e. 9 detectors -- correspondingly more after adding another detector. FSFANA3 needs at least this number of nested DO loops to operate correctly. If necessary, add more loops, including the IF statement accompanying each loop header. Don't forget to update all variable names, goto destinations and statement labels when doing copy/paste to add more loops!

Technically, DELSEARCH is now able to treat the new detector correctly. However, with the above changes applied, it will still not be used in the merging process. DELSEARCH needs definitions of track search strategies that include the new detector. This is done in FSFSTR. There we have a sequence of track searches starting from various detectors (TPC, SI), and a few re-iterated searches starting from partially merged tracks (SCAN1, SCAN2 etc.). For each existing search one has to define whether the new detector should be included in this specific approach. $method(i\_NEW)$ =0 does not attempt to merge any TE of the new detector into track candidates at this stage. $method(i\_NEW)$ =

means that DELSEARCH should attempt to extrapolate track candidates from the primary detector of the respective search to the new detector and attempt to find suitable TEs. Whether this merging is done according to matching track parameters (realistic mode) or according to matching Monte Carlo ID of the track elements (ideal track reconstruction) is determined from the value of the FFREAD card MCMERGE (true=ideal, false=realistic).

If the new detector is a primary detector, one will probably also want to start a track search from it. Copy for example the TPC track search section somewhere before the ``cleanup and iterate searches'' section in FSFSTR. Make sure that the new search defines the new detector as starting point of the track search by setting $method(i\_NEW)=none$ . The first argument of the FSFANA3 call has to be adapted as well. Furthermore, to allow for time consumption analysis, change the argument of the

array references to $i\_NEW$ . One should also add a statement whether the TPC (or whatever detector was primary detector in the track search we copy-pasted from) should be included as target in our new track search: $method(i\_TPC)=method$ or 0. The call to FSFANA includes a bit code setting some flags, the definition of which can be found in Table

Table: List of bit flags used to steer the behavior of the track search engine FSFANA3. Track parameter estimation by polar inversion is foreseen for angular regions without standalone pattern recognition capabilities. It should not be necessary in Brahms.

flag	meaning
FLAG_DATA	select TE merging according to
	measured hit/track parameters
FLAG_LABL	select TE merging according to MC track ID
FLAG_USEUSED	allow to add same TE
	to more than one track candidate
FLAG_GIVESINGLTE	allow single TE to be used as
	track candidate (e.g. TPC)
FLAG_PCONST	constrain momentum with beam spot
FLAG_SCANDET	scan previous track candidates
	for missing detectors
FLAG_CUT100	check at most 100 TEs per subdetector (layer)
FLAG_NOPLINV	do not use polar inversion to get
	initial track parameter estimate
FLAG_AVERAGETHETA	for polar inversion: use average $\Theta$ of all TEs
	instead of primary TE only
FLAG_BEAMSPOT	use beamspot constraint in track fit

Further changes have to be applied to DELSOLVE. As DELSOLVE is C code as opposed to FORTRAN as used in DELSEARCH and TKSTEER, it uses its own set of symbolic constants to describe the subdetectors. Add the value of $detid(i\_NEW)$ to a definition of

in the list of compiler directives defining

and so on. The array

defines how important it is to keep a TE of a specific subdetector in a track candidate. If the importance is very low, one might tend to throw out this subdetector if this increases the track fit quality significantly. Add a value for the new detector to this array to reflect the relative importance of it. For example, standard Brahms assigns 20 points to a TPC track, whereas each SI hit gives 5 points. A value of

in the array marks an unused detector ID.

At this point Brahms should be able to reconstruct tracks including the new detector. Every TE of the new detector will be added to the track where it fits best -- unless all track fits involving this specific TE fail. This means that all track combinations involving the new detector are tested. This might be rather slow, but should give the largest reconstruction efficiency that Brahms can achieve with this system. If that does not work, at least one item of the list of changes described in this section was not correctly implemented.

To speed up the merging without too much loss of efficiency, the DELSEARCH can preselect matching TEs looking for matching track parameters. Usage of this feature requires some tuning. The routine FSFINI in DELSEARCH defines cuts for the helix extrapolation of track parameters from each subdetector to each other. The cuts define a maximum deviation of track parameters of the target detector TE compared to extrapolated values of the primary detector TE. (Where no cuts are defined, the default behavior is to combine all TEs that survive a common track fit, as described above.) Possible cuts are given in Table

. For tuning, add arbitrary cuts on all variables you consider useful. Cut values of 0 are recommended for all quantities for tuning, as tuning can be done with any cuts, and the harder the cuts are, the faster Brahms runs. Switch on DELSEARCH performance histogramming (FFREAD card DESHST 1) and run a few events. The number of events should be large enough to contain a total of a thousand tracks or more. After the run, look at the histograms in the DELSEARCH subdirectory of the tracking histogram output file. Two histograms are filled for each combination of detector $i\_FROM$ and detector $i\_TO$ if cuts on the extrapolated track parameters are defined in FSFINI. The histogram IDs for any such extrapolation are $10000\times i\_FROM + 50 \times i\_TO +10$ ...

for correct combinations, and

...

for wrong combinations. All combinations are filled into the histogram, even if they fail to pass the cuts defined in DELSEARCH. It might be necessary to adjust the histogram range and/or binning towards the end of FSFINI in DELSEARCH. Optimized cut values can be found best by plotting the correct and the wrong combinations on top of each other with log scale on the y axis.

Table: List of track parameter variables, cuts on which define compatible and incompatible TE parameters. A second set of variables, starting with pl instead of xc, is available for cuts on parameters obtained by polar inversion.

variable	meaning
xcx	cut on agreement of coordinates
xcy	cut on agreement of coordinates
xcRPhiR	cut on agreement of $R\Phi$ coordinates
xcz	cut on agreement of coordinates
xctheta	cut on agreement of $\Theta$ coordinates
xcphi	cut on agreement of $\phi$ coordinates
xcthest	cut on agreement of $\Theta^*$ directions
xcphist	cut on agreement of $\phi^*$ directions

The overall performance of Brahms track reconstruction can be evaluated by switching the FFREAD card TKPERF to 1. Then, a file tkperf.summary will be created, showing a text summary of