Current Known Tracking Problems

4.8.4 known problems
5.1.3 known problems
5.3.1 known problems
5.3.2 known problems
5.3.3 known problems
5.3.4 known problems
6.1.0 known problems
features

Some notes

Don't forget to use the Pass table to get the correct alignment and beamlines: See: Tracking calibration: Pass tables - silicon alignment tables and beamlines

Current know problems in in farms production release 4.8.4, simulation release 4.9.1 and physics release 4.9.1hpt5(see below for 5.1.3 problems. In general 5.1.3 problems are also present in previous releases).

Fit bias in Kal kalman fitter: fixed in 4.9.1htp5 with refit

Bugs in 4.8.4 productions led to a 25um beamline offset and the inclusion of L00 hits on a small number of OI tracks(on order 1%). All tracks should be refit using 4.9.1 in which the refit is corrected. The user should call the option which drops L00 hits. The refit tracks should be used with the remade or corrected beamlines which are fully ready at this time. Beamlines are ready for runs on the Silicon good run list. TrackingUsageExample gives an example of refitting tracks.

A TrackRefitModule is available as part of the 4.9.1hpt3 physics release. This module correctly refits all tracks and alters defTracks so that the refit tracks are returned instead. The refit tracks will be the daughters of the original tracks. When using track based objects such as muon objects you will have to ask the track for it's daughter track to get to the refit track. You should add this module before your analysis module.
This module can be checked out against 4.9.1 as follows. The top group processed their data and MC using this procedure and users should be sure to follow the same procedure or use 4.9.1hpt3.

Track fitter tricks and traps

Don't forget the puff the silicon hit information. The tracks cannot be refit without the hit positions.

There will be a ELwarning issued in the next physics release if the hits are not puffed.(the 4.10.x series releases)

If you want to access the strip and cluster information you need to puff those as well. The order in the puff module statement is important.

The SiliMap not initialized error. SiliMap is not currently used so this warning can be ignored.
OI tracks rarely fail the track refit. Sometimes silicon standalone or COT tracks fail. You should always check the return code of the TrackRefitter to see if the track fit failed. If you use the TrackRefitModule the failed tracks have a bad fit status and are marked as bad. This means that defTracks will not return them, though you can see them by asking for the allTracks view.

The 4.10 series releases now note the type of the tracks that fail the refit.
Errors such as

Failed to refit a previously good track TrackRefitModule Note the fit that is being performed now is slightly different than the one that was done before, so some new failures are expected.
Warning! track fit failed
Warning! si standalone track fit failed
Warning! cot track fit failed

Errors such as

KalKalmanFitter::conv2Perigee ERROR: Inversion of weight matrix failed. (This should never happen.)
Warning: cannot extrapolate to cylinder r = ...
Ominous Warning in KalmanFitter::apply(Measurement): chi^2/dof=...

Note warning made more useful in 4.10 release.

Time dependent beamline: Available in 4.11.2

The beamline shifted by large amounts during some runs. For instance in run 148824 the beamline moved by 80um. Since beamlines are based on the average beam position in a run, the beamline for this run could have up to a 40um error for the time periods in the run where the beam is furthest from the average.

We have developed list of such runs. We recommend not using them for analysis that depends on the beamline for the moment.
We now have a new system allows us to generate beamlines for periods smaller than a run. The corrected beamline is be loaded if the user sets a flag in the beamline class. This code is available in the latest physics release. Accessing this information is the recommended way to tell which runs have a large variation.
However, you should check with your physics conveners to see whether they intend to use the time dependent beamline as part of their "blessed" procedure for performing physics analysis.

Beamline crash: Fixed in 4.11.2

There is a known crash in SvxBeam for run 144583. Code fixing this is ready and will go into the next physics release. (4.10 series release)

Bug in beamline used set method: Fixed in 5.1.3

For runs that do not have a valid beamline the isValid() method does not properly return false. Explicitly checking whether the beamline average x and y are 0 can detect this problem. Though it is highly recommended to use the used set mechanism, even though this additional check must be performed.

Bad alignment period(Pass table now has correct calibration and data reprocessed in 09 series)

Incorrect alignments were used for runs 152595 to 154012. The alignment used was 10016 TEST 3. This alignment had the incorrect Z barrel positions for the SVXII. The positions are bad enough that we expect stereo(Z) pattern recognition to be effected. Axial pattern recognition is probably OK and the r-phi information for the tracks can be recovered by refitting.

Largest effect is on silicon Z information

less stereo hits 6.0%
less 90Z hits 13.6%
less tracks with any stereo hits 4.0%
less tracks with any 90Z hits 7.3%

Effect on r-phi information is on order 1%

See page 10 of blessing talk for single leg silicon efficiency for J/psi muons

To be more specific. If you need Z information your efficiency would go down. It's possible that wrong hits could be added. However, this is hard to check since nothing measures Z with the accuracy of the silicon for comparison. If few Z hits are added the purity tends to be lower, but this problem is avoided because the default track cuts require that the Z information is dropped if not enough hits are used. However, performing fits based on Z information is not recommended for this data.
The silicon efficiency for these runs has been checked and is documented as part of note 6318. The efficiency has also been measured for this data retracked with the correct alignment.

Compressed silicon data problem: Fixed in 5.1.3

Data processed with the 4.8.5 Farms ProductionExe executable did not properly uncompress the raw silicon data. As a result silicon data was lost on all but events that are in the A stream. Data process with 4.8.4 does not have this problem. For example this problem effects about 12pb-1 from run 167717 to 168892 or Aug 18th to Sep 6th 2003 in all Streams. The operations group is working to fix this problem.

Less than 3 hits problem: Fixed in 4.11.2

3 hit requirement for r-phi hits on silicon outside in tracks is not explicitly made in PADTracks. The OI algorithms both will occasionally discard a hit(going from 3 to 2) during a post track clean up phase.

Silicon only tracks(known as standalone tracks) fake problem(Not fixed until 5.1.1)

The standalone tracking has a non-negligible rate of forming fake high pt tracks. This happens when enough hits from whatever source form a fairly straight line that passes the tracking algorithms requirement. If these tracks are in the central region they are most likely fakes because the COT tracking should have found them. In the forward regions Z0, d0 and chi2 cuts can reduce the fake rate.
In release 5.1.0 these tracks are removed from defTracks in the central region. Most real tracks are found by the combined COT and silicon tracking which now includes both outside-in and inside-out(using silicon parent tracks to search for

Silicon calibrations not loaded properly in secondary dataset reprocessing: Fixed in 4.11.2 - though users should not do this!

Note that the procedure for re-tracking the data revealed another bug. When secondary data sets with multiple runs are processed the silicon calibrations are not properly loaded for runs that occur after a run that did not have a good silicon calibration. This data is then dropped.

Fit errors in general: Still 30%(50% stereo) off in 4.11.2: Still 10%(30% stereo) off in 5.1.1 - rphi errors are good for low eta tracks

The pull distributions in general are 30% too large even using the best current fit

Fit errors in simulated data using 4.9.1: Fixed in 4.11.2

Simulated tracks do not correctly make use of the 90Z hits in 4.9.1 and 4.9.1 based physics releases. 4.8.4 data is not effected by this bug. This problem is actually in the fitter and only effects simulated data (or real data) tracked using an alignment table without wafer level corrections. This is true for all simulated data and very unlikely for real data. For OI tracks the stereo pull distributions are increased by on order 50%. The effect feeds through to the r-phi part of the fit and results in a slight increase in the pull distribution. The effect on standalone tracks is very dramatic. The tracks tend to be biased toward -45, -15, 15 and 45cm. Refitting the tracks with a 4.10.x series release fixes this problem.
Also for 4.9.x series release you can add the file

Note that there is some evidence that stereo information in data is improved somewhat by in the 4.10.x releases, though this is not yet confirmed or understood.

Material in detector: all fits: Improved in 5.3.1 - Still not perfect or matched to electron data

Some material in the silicon detector is not included in our material map. This means that when tracks are refit not enough energy loss is taken into account. This effect is very large for protons - but not so bad for muons or pions. We suspect the missing material is in between the SVXII and ISL where the port cards and power cabling is located. Eventually we will map this material using photon conversions. Andreas Korn has studied this problem and introduced an extra material layer that represents the material closely enough to give good results for the J/Psi mass measurement. This material layer can be invoked by the following talkto.

6355

The study of the use of this layer is ongoing and still being improved. For instance using the layer currently increases the width of mass peaks by a very small amount. This is an indication the we don't have the layer perfectly tuned yet. Also the amount of position and type of material does not agree with what is predicted using electrons.
This correction should also be used with corrections to account for energy loss in the COT and the over all scale of the magnetic field.
However, you should check with your physics conveners to see whether they intend to include the current estimate of the mass in their "blessed" procedure for performing physics analysis.

Material in detector: Kal fit: Phantom layer available - but still slightly less material, New silicon material description available in 5.3.0(changes in port card region)

Some material in the full detector geometry is not included in the material map used in the fast Kal kalman filter based fitter. This leads to similar problems as those above. It's also been noted that the errors on tracks refitted using the Kal fit are underestimated by on order 10% compared to the G3X based fitter.

B yield problem: Likely due to SVT beamline and COT charge collection problems

B yield problem: In B group there seems to be a yield problem with various b hadron analysis. This yield problem coincides with the alignment problem period noted above. One other change that was made at a similar time was the switch to 1 miss XFT mode. In addition luminosity is increasing. The problem has not been localized to the silicon, COT or the trigger. Some relevant information.

Some better confirmed observations

The change in the trigger efficiency when moving to 1 miss XFT mode accounts for the full difference in the J/psi yield. See Cheng-Ju Lin's talk from the B validation group meeting
Track embedding studies show that the COT efficiency does not look significantly different for the 1 miss XFT data
The effect on long lived particles like K shorts seems to be stronger. Also the effect for very low momentum particles may be stronger
The number of COT hits used on tracks has been going down, probably as a function of luminosity. This does not exactly correspond to changes in the XFT or silicon alignment. Though some of the lowest numbers seem to be right around the time the bad alignment was used. see: hit usage plots
Tracking groups studies have shown that in jet data the efficiency for attaching silicon r-phi hits to COT tracks during the alignment problem period is not significantly reduced.
The problem does not correspond to the change in silicon thresholds.

Some other observations

Properties like Lxy and d0 look good for the tracks and candidates that are found. From B to mu + D study
In the B to mu + D study the yield loss corresponds exactly to the bad alignment period in the D+ mode but not in the D0 mode. In the later mode the yield continues to be bad after the correct alignment was restored. However, the XFT mode does not change back.
In the J/Psi K mode the yield is down before and during the bad alignment period. The XFT was in 2 miss mode during the first period.

Silicon stereo information: Looks good in 5.3.1 - part of general improvement in errors

Stereo cluster errors are not well estimated and the Chi2 from 3D fits is not well behaved. A project to measure them from data is in progress. Though note that tracks with 3 90Z hits have well behaved errors.

COT track algorithm type and seed segment information is lost: Fixed in 5.1.3

A bug in the CdfTrack streamer caused this information to be lost for all data processed with these releases

Memory leak in SiExpected event entry point call: fixed in 5.1.1

Using usedSI() and hasSIHit( int layer, bool oddPhiAddr, bool pSide ) - There can be up to 4 hits in layer 6 in the regions where sensors overlap in both phi and z. The ambiguity between the phi overlap hits is resolved by the oddPhiAddr bit. The z overlap is not resolved.(Not fixed)

Silicon simulation bugs and crashes: Fixed in 4.11.2

The silicon realistic simulation using the Physics charge deposition model is known to crash occasionally
When applying an alignment in the realistic silicon simulation sometimes hits are lost due to a known problem that occurs when volumes overlap in Geant
When applying an alignment in the realistic silicon simulation wafer level corrections are not applied. This can lead to a bias in vertex calculations

Reconstructed track MC matching problems: Fixed in 4.11.2 using TrackMatchUtils

The cot "CdfTrackHits" are dropped by default. This can cause the matching code to fail, though it can be circumvented
The "SiClusterSet", "StorableRun2SiStripSet", "SIXD_StorableBank:CORRECTED" and "ISLD_StorableBank:CORRECTED" are dropped by default. A user who wants to do silicon MC matching should keep these objects when running ProductionExe
Look at the Matching reconstructed and simulated tracks page for more details.

Current known problems in 5.1.3 series releases(Also in previous releases).

In the 5.1.x, and all previous, alignments the Z position of the silicon barrels is slightly off. This is corrected in a the latest alignment used for 5.3.1

The track z0 positions used in the Z vertex maker were not corrected for the beamline position. This leads to an error in the Z vertex position that depends on the weighting of tracks in eta and phi. This error is corrected in version 5.3.0. Remaking the Z vertex collection improves the resolution by on order 100um: 250um to 150um. Be sure to drop the old ZVertexColl before rerunning ZVertexModule.

ZVertexModule did not properly produce Z vertices for A stream data or any events that are in the A stream even where they occur in the other streams.. Corrected in version 5.3.1

ZVertexModule: If you try to run ZVertexModule in your own job it looks for the tracks under the current process name. Unless the current process name is PROD it will not find defTracks. In 5.3.1 there is now a ProcessName tcl switch which can be set to PROD independently of the process name used in your tcl: Fixed in 5.3.1

Matching of COT or silicon tracks with MC parentage information does not work with the compressed raw data format: fixed in 5.3.1

The raw tracking data was not stored for the first 30 of pb-1 of data in the 5.1 series reprocessing. Affects runs before 152967. Also data necessary to perform muon trigger matching and TOF reconstruction is missing for all the data in the compressed data format. Fixed in 5.3.1
Puffing of the silicon data does not properly restore the links between the hits and the silicon strip information. This prevents users who have stored the silicon strip information from accessing it and makes matching of silicon track with MC parentage information: fixed in 5.3.1

The phantom layer did not work with the KAL type refit in early 5 series releases. Also an initialization bug in the implementation of the phantom layer in 5.3.1pre4 caused crashes that release: Fixed in 5.3.1

Current known problems in 5.3.1 series releases(Also in previous releases).

dE/dx in the COT is only well calibrated up to run 156487 in release 5.3.1: dE/dx calibrations now done through Fall 2003 shutdown in the form of a patch to CT_DedxAnalysis. See Physics Patches for the list of patches or update to revision 1.8 of TrackingCT/src/CT_DedxAnalysis.cc.

Memory leak in SiExpected run entry point call: Fixed in 5.3.2 or by patching. See Physics Patches

The run averaged beam line position is used in 5.3.1 MC production. 5.3.1 Production and user code use the time dependent beamline. The effect on pattern recognition in the COT HL and silicon standalone algorithms is expected to be small. Vertexing code and user code that vertex or calculate d0 or decay lengths using the beamline should be run with the run averaged beamline. If events are processed that are outside of the range of events in a given run the beamline position is extrapolated to beyond where it was measured in the run. This can lead to MC beam positions that are non-physical(outside the beampipe). In this case the effects on both pattern recognition, vertexing and used code are large: Fixed in 5.3.2 or by patching. See Physics Patches

The pedestal fit that is run on L00 data was misapplied to strips around strip 64 on the wide L00 sensors. This leads to a 2% rate of bad clusters. Fixed in 5.3.2

When there are 0 ADC or below threshold strips in the L00 the Ped fit can fluctuate low. The negative pedestal is then subtracted from the data creating false clusters. Fixed in 5.3.2

The L00 pattern recognition code does not seem to add clusters to the first or last 30 strips of some wide sensors: Fixed in 5.3.2

Clusters on L00 on the side nearest the beam or any place where the track trajectory crosses the L00 at a large angle have large enough charge to be frequently rejected by the standard quality cut of total charge less than 100 ADC counts. Optionally fixed in 5.3.2 Investigating if this introduces a large rate of mis-measured tracks when using L00.

Current known problems in 5.3.2 series releases(Also in previous releases).

Large overlaps were created in the L00 and SVXII bulkhead regions in 5.3.2 when simulating data: Fixed in 5.3.3

Current known problems in 5.3.3 series releases(Also in previous releases).

The intrinsic resolution in the L00 are considerably underestimated in the track fit. This leads to underestimated tracks errors on parameters like d0. Using the best numbers as measured by Bernd Stelzer results in improved track fits. These numbers can be loaded using tcl. Default in 5.3.4

Include the following talkto for PuffModule

to read the file hitres.txt

When setting a TrackRefitter for L00AddAndRefit a segmentation fault type crash is sometimes seen at the end of the job when the destructors are executed. In addition several memory leaks have been found in this class. Fixed in 5.3.4

There is an error in the conversion from Kal internal covariance matrix representation used in the (re)fitter to the the perigee parameter covariance matrix. In rare cases with large correlations between covariance elements the error can lead to non-positive matrices. Fixed in 5.3.4

There is an error in the matching of reconstructed and obsp helix parameters in the TrackMatchUtils::cotObspMatchEff method. If the phi0 is near 0 for one and near 2pi for the other the tracks are not matched. This only happens if the primary hit matching method fails. Fixed in 5.3.4

The flag non-integrated ladders flag used in MC Production does not kill all classes of non-active ladders. Ladders where all of the stereo chips are dead(but not all the axial chips), ladders where the axial to stereo side power jumper is broken and ladders where the threshold is set to prevent data taking are not flagged as non-active. This primarily effects the stereo side and standalone tracking. Fixed in 5.3.4

Strips that are excluded from the L00 pedestal fits are not excluded when running L00 MC. This leads to an overestimate of the efficiency.
Also bad strips are included in the data L00 pedestal fits. Not excluding these strips may have led to some bad fits in places where there were a number of noisy or saturated strips. Fixed in 5.3.4

The three silicon alignment periods must be specified by hand in the simulation tcl when running realistic MC with silicon misalignment. Default tcl in 5.3.4

COT hit resolutions were tuned in the 5 series releases to match high pt muon resolutions. Though this tuning is sound, the mass pulls are too large by a factor of more than 2 for low pt data(high pt data is being checked). Also the mass peak of the Z in MC is somewhat thinner than in data. This problem in the Z MC has been identified as due to the t0 smearing being too large in MC and the hit resolution smearing being too small. This problem also leads failed track fits and large chi2 in events that are on the tails of the t0 distribution. Improved parameters are default in 5.3.4

COT single hit efficiencies are too good in 5.3.3 MC. A new tuning of the hit width, t0 and hit resolution distributions in 5.3.4 improves the agreement between data and MC. Using the track embedding MC a perfect match with data can be achieved.

Current known problems in 5.3.4 series releases(Also in previous releases).

When SiClusteringModule is run in cdfSim which is typically done before running TrigSim with svtsim the dead/hot strip calibration is sometimes not properly loaded.

A small memory leak has been found in TrackMatchUtils.cc. Fixed by loading -r 1.13 of TrackingUtils/src/TrackMatchUtils.cc

Features and problems of the tracking code. Volunteers to work on these problems should contact the tracking group leaders.

Track errors are computed at 0,0. Since the beam is off center this can leads to the error being incorrectly estimated. The effect is phi dependent. A new class called TrackExtrapolator fixes this problem. However, since the errors are only extrapolated(the measurement points are not taken in to account) there is still a small error for tracks on the side nearest the beam. TrackExtrapolator has been integrated into VertexFit via the functions setTrackReferencePoint and moveReferencePoint. See SecVtxStrategy for an example.

Material and silicon(cot) track errors and refits

Stereo and axial errors appear better behaved in 5.3.1
Stereo errors still underestimated by 30% but Gaussian
Axial errors Gaussian and well estimated except for high eta tracks they are underestimated by 10%
Material description improved and phantom layer replaced by material in the port card region. Some fine tunning that will probably improve track errors and matching between muon/hadron and electron data is in progress. The results are improved in 5.3.1
The material and the COT covariance scaling needs to be re-tuned for the 5 series releases. The first pass tcl for the new phantom layer should be taken from the setup_manager.tcl file for Production. The best current numbers can be found in Elena Gerchtein's note 6905. These numbers were blessed at the BPAK meeting.
Using the TrackRefitting procedure on COT only tracks is not ideal since there are no constraints when fitting across the silicon volume. The fit has a slightly higher rate of failure. For physics not involving vertexing or lifetime information COT tracks should probably be beam constrained rather than refit.

COT data exhibits overall lower charge collection efficiency and a dependence on phi in the charge collection in the summer 2003 and spring 2004 data. This leads to degraded tracking performance both offline and in the XFT by a few percent and order ten percent respectively.

The silicon and COT data is compressed on the output of Production. For applications require the raw data the uncompressing module must be run: See Accessing raw tracking data

Accessing COT hit data to calculate residuals or recalculate de/dx(should not be necessary in 5.x)
Accessing COT hit data to refit track with an improved t0
Accessing COT hit data to use the CosmicFinderModule
Studying silicon strip data - note the silicon clusters are deleted so to study silicon strip data you need to retrack from scratch(Hit data is kept for performing refits)
Matching silicon only tracks or silicon hits to MC parentage information. See the Matching reconstructed and simulated tracks page for more information on this issue:
Retracking

SiExpected produces a database error( %ERLOG-s DBSTALE: Attempt to access stale data held by DB handle) when trying to access SiExpected information for runs before 138858. This is the first run that is considered good for silicon by the silicon and DQM groups. You should not use silicon for runs before this and should not use runs before 138815 in general. If you find this error for other runs you should check if your specifying the correct pass table for 5.1.x data(Pass 11) or 5.3.x data(Pass 13).

Bad neighbor strips are not marked and therefore clusters that are next to bad strips are not marked as bad.

IO and forward going COT tracks are refit with the same covariance error matrix scaling parameters as the central tracks. These parameters are necessary to account for multiple scattering in the material of the COT which is not taken into account in the standard COT fit. These parameter are overestimated for forward going tracks which do not traverse as much material. Additionally the COT fit may perform poorly for COT tracks with very few segments such as IO tracks. The quality of the fit and the estimated errors is being investigated. Currently we advise the user to only apply cuts on IO track errors after careful investigation of the effect.

Current known problems in 6.1.0 series releases.

Data processed with 5.3.1 has bad dE/dx if it is read out with 6.1. To get good dE/dx one needs to pick up this patch:
- a) Check out the TrackingObjects package
- b) Add this file:
- cvs update -r 1.76 TrackingObjects/src/CdfTrack.cc
- Fixed in 6.1.1 release.
In generation 6 the t0 is also included in the fit. A bug in the code makes that only the positive tracks are being fitted for t0, a vertex t0, vt0, is being then made only using the positives tracks, and later only the positive tracks gets constrained to the vt0.
For effects of the physics, see the talk given at JPM, July 08, 2005. talk given at JPM, July 08, 2005

Last updated: July 31, 2005 by Mircea Coca