Varying BeamLine Hints (June 5, 2003)

Starting in 4.11.1, time-dependence in the beamlines will be on by default. This is the variation in the beamline during a run (small for most runs, up to 80um in the worst run). This is the recommended way of running for btagging for summer. You only need to call the position() accessor in the event method in order to get the corrrection automatically. If you call the position() accessor in the begin run method and save the beamline, then you will be using the run-averaged beamline. You can turn it off by setUseTimeDep(false).

Only history 19 Svx beamline has time-dependence. History 19 Cot and other beamlines do not. History 19 is the beamline for summer conferences, for 4.9.1, 4.10.x and 4.11.x refits. It is the same as ProcesName PAD_PHYSICS_CDF, PassName 08. If you request time-dep in a beamline without time-dependence, you will get the beamline averaged over the run, the current default.

Currently you can turn time-dep on in any 4.10 release, but note that there is a bug in the accessor code in 4.10.0 - 4.10.4, fixed in 4.10.0int2 and all 4.11 releases. In these old releases, you have to turn it on explicitly by setting setUseTimeDep(true).

Hints from Doug Glenzinski

• if you use dflt production output, OR refit using the KalFit, you should use 4.8.x beamlines (history code 17=4.8.4, 16=4.8.0... work in progress to make it all =17 for all runs)
• if you use SiTrackFitter, you should use 4.5.2 beamlines (historycode=13)
• if you follow the above pre-scriptions, and you plot vs phi, you will see systematic offset w/ a full spread of order +/-10um; if you use the wrong beamline, that will increase to +/-20um;

andreas was initially looking at a scatter plot of d0 vs phi... you won't see these 10um effects (nor the 20, i bet). that's how the high-Pt Btag group had been initially lulled into a sense that all was well. when we started making profile histograms, or slicing in bins of phi0 and fitting the core of the distributions, the offset became apparant. when andreas sliced and fit, he saw the +/-10um for SiTrackFitter and 4.5.2 beamlines.

the +/-10um spread is "understood" to have a component from residual COT mis-alignments (if you use only the curvature from the COT the spread is reduced to a full width of +/-3um) AND "time" (alignment constants determined using data from May; if you make the same plots employing only COT curvature vs. run number, you see the +/-3um spread get larger... like +/-7 or 8... i forget exactly; the silicon operating temperature changed in that time, there may be other plausible explanations as well).

SO, this +/-10 um spread won't get better until

• COT alignment finished and silicon alignment iterated
• ray updates alignment that has some run dependence

which is to say, we have to live w/ it for awhile. Any lifetime analysis needs to verify or quantify possible systematic effects on account of this.

the increase from +/-10um to +/-20um is due to "differences" in the two fitters used to make the beamlines. present understanding is that KalFit had some bugs; as of 4.9.0, these had not been fixed; i'm not sure about >=4.9.1.

Ray gave a nice talk about most of this at a highPt Btag meeting a few weeks ago. you'll find a link to his talk here (following the link w/ username "rlc")

more information is also available from here (follow links w/ references to "d0 vs phi" and "ray").

Beam Wrapper Hints

Fixing BeamWrapper to 4.5.2 Beamlines:

in your tcl: FixtoProdVersion set 452

Fixing BeamWrapper to 4.8.x Beamlines:

NOT available

Switch between SiTrackFitter and SiKalFitter in the TrackReFitter:

TrackRefitter::fitmethod fType = TrackRefitter::F_SIG3X;
TrackRefitter::fitmethod fType = TrackRefitter::F_KAL

_refitter->reFitTrack(track, fType, pid);

_refitter->setFitMethod(fType);
_refitter->fit(track, pid);

To get the History Code

 CotBeam::getRecord().Flag0()&0xFFFF