Current Known Tracking Problems
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.
setup cdfsoft2 4.9.1
newrel -t 4.9.1 btag_4_9_1_v02
cd btag_4_9_1_v02
addpkg TrackingObjects btag_4_9_1_v02
addpkg TrackingUserMods btag_4_9_1_v02
- Track fitter tricks and traps
- Don't forget the puff the silicon hit information. The tracks cannot be
refit without the hit positions.
mod talk PuffModule
puffOnly add SiHitSet
exit
- 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.
mod talk PuffModule
puffOnly add StorableRun2SiStripSet SiClusterSet SiHitSet
exit
- 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
are properly handled in this way
- 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=...
can be ignored if the track does not fail the fit. Note if the track does not fail the fit in the end it's
been successfully fit.
- 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
From multijet data
- 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%
- 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
cvs update -A -r 1.28 TrackingKal/src/KalSiHit.cc
- 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.
talk GeometryManager
SiliconGeometryMenu
CreatePhantomLayer set t
PhantomLayerThickness set 0.XXXX (see note 6355)
exit
exit
- 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
talk PuffModule
siHitRes read hitres.txt
show
exit
- 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
This is fixed in 6.1.1.
Also the data affected by this bug (December, 2004- March, 2005) will be reprocessed in the Summer, 2005.