Outstanding Issues
There are a variety of problems and features which need to be addressed for v13. These can be subdivided into modifications to and the understanding of the existing unpackers and trackers, general code and interface development and the development of new trackers.
In no particular order...
SMT Unpacker
- Test Tim's modifications to the SMT unpacker. Encorporates:
- Better cluster error estimation (including the possibility to set different errors for different types of detectors) and adopts thresholds closer to offline.
- Kills clusters with a size > 32 consecutive strips.
- Adds methods to return first strip and pulse height for the strips in the cluster.
- Does not join two strips separated by a strip into a cluster. This was originally done to take into account the presence of dead strips.
- Changes to trigger list parameters (in the level3.sim file):
- Channel threshold = 0.023 (default 0.03)
- Cluster threshold = 0.028 (default 0.03)
- ADC threshold = 7 (default 10)
- Ensure that we are running with the correct pedestals, etc. Do we want this automated in some way?
- How do/ should we deal with noisy strips and chips. Kill as in offline? In any case it will be worthwhile to add this information to the track finding algorithms.
- Currently the SMT unpacker only kills chips with bad chip id and not HDIs with multiple readout of the same chip id. Also there is no check for bad channel id. The effect of the above is currently under investigation with the smt group.
- Figure out how we are dealing with "bad" data and what exactly is bad data.
This version of the unpacker has not been tagged into cvs and will need to be.
CFT Unpacker
The CFT unpacker seems to be working well compared to offline. Only major modification attempted was the use of more realistic errors for the fibre clusters. Unfortunately this has a large (and not completely understood) impact on the global tracker (see "plots" HAVE TO LINK THIS section). The default unpacker in p16 uses the old errors, the new errors for the clusters are in cvs l3fcftunpack v00-04-08
The major modification made to the unpacker was the inclusion of dead cft fibres in the tracking algorithm (see plot for the distribution of the dead fibres). Currently these are read in from a flat file and are treated as if they were 1 fibre clusters. This file can be found in l3fcftunpack/config/l3cft_dead_fibres.dat. In order for the unpacker to utilise this file the .dat file has to be copied into the run directory. This affects runs from 185469. There was no correction for this until run 187680 after which the new L3 cft unpacking, in which the dead fibers are artificially turned, on was implemented.
The way the dead fibres are used is not ideal as they will be also be used in the track parameter fitting routines. This will need to be changed so that the dead fibres can be used for the track finding but are not involved in anyway in the fitting procedure. Furthermore there is the issue of maintaining the flat file and a better way has to be found (maybe some database?). Both of these issues will be relevant if similar modifications are made to the l3 SMT unpacker.
Global Tracker
The global tracker is largely unmodified from that used in v12. However a variety of potential limitations and areas where there was room for improvement were identified.
- There is noticeable drop in the efficiency at high pt. This is being looked into by Claus Buszello.
- Can we improve the tracker resolution at high pt? From the p16 results it is clear that the spread in resolution is mainly due to the inherent problems in fitting to low rinv values. However compared to offline there is still some room for improvement. The effect of changing cluster errors has been looked at. There is marginal if any improvement (with loss in efficiency and purity!).
- Can the extrapolation of the tracks from the CFT to the SMT be improved? This might be linked to the problems in resolution. Preliminary investigation shows that this cannot be simply improved by changing the clustering.
- The effect of the new errors for the SMT clusters need testing.
- How well do we track high pt particles in jets? Is there an efficiency drop with isolation of tracks?
- Need to shift focus slightly to improving and understanding the tracker for samples of interest (e.g. MZ W/Z events). Currently the focus has been on overall improvement.
- Need to treat dead/missing clusters differently in the track finding (see cft unpacker). This will require a change to the global tracker
-
Code Development and Interface Changes
Code development can be subdivided into two sections: the development of the tracking algorithms (including the addition of new algorithms) and the modification general code structure.
New/Alternative Tracking Algorithms
- Stand-alone CFT tracker, tagged into cvs as ??????
- Stand-alone SMT tracker, tagged into cvs as l3fsmttracking.
- Specialised high pt tracker, tagged into cvs as htrk and l3ftrack_htrk.
Instructions on how to run the above and some general documentation can be found in the links section.
Interface Changes and Software Development
The global tracking in its current form is not particularly modular i.e. it is not possible to replace the SMT algorithm of the global tracker with another algorithm. As new tracking algorithms have been developed for both the CFT and the SMT the modular nature of the global tracker needs to be restored. Hence there are two solutions:
- Leave the current global tracker as is and develop new tools and infrastructure for the new trackers so that the SMT and CFT sections can be combined. Eventually replace the global tracker with the more modular trackers if efficiency and purity values are equivalent (or better).
- Modify the interface of the global tracker such that the CFT and SMT parts can be separated and integrate the new trackers as needed.
The first solution is the simplest to implement but it does rely on the new algorithms having a better performance than the current global tracker. The latter solution is more risky and difficult due to the non-trivial nature of the global tracker however the CFT and SMT algorithms which are currently running in the v13 trigger list would not be lost.
There is also the issue of whether the trackers should store information on the SMT and CFT clusters associated to the tracks. Currently this information is not required to be stored however it will be useful information when debugging and comparing different trackers. If it is decided that this information should be stored then it would imply interface changes to all the trackers.
Michele Petteni,Ray Beuselinck
Last modified: Fri Apr 16 15:34:05 BST 2004