Muon Offline Meeting -- Minutes ================================= 29 - May - 2002 ---------------------------------------------------------------------- Ken Bloom -- Notes and comment ================= Ken followed up on some of the items he discussed at the beginning of last week's meeting. In the past two weeks, reprocessing was done with 4.5.0, and Alexei did make the W and Z skims, plus an inclusive good-muon skim, as requested by the top/electroweak group. The Web page at http://fcdfhome.fnal.gov/usr/varganov/RunIIAnalysis/stripping.html tells the story. However, there were a number of problems. The least of these (maybe) is that only the data from 2/24 to 4/8 was reprocessed, and obviously we are interested in more than that. But there were also problems with tracking in 4.5.0, leading to duplicate tracks, and a high rate of tracks with negative chisquared values. As a result, reprocessing of Stream B with a fixed release 4.5.2 is to begin imminently, and should finish about a couple of days after it begins. The data will cover the entire range we are interested, going up to data taken 5/26. When this is done, Alexei will make new skims, but the existing skims can be regarded as a reasonable first draft of what muons will look like for this summer. If we run into disk-space troubles, we will start deleting data processed with 4.3.2, but warn people in advance. (These data will still exist on tape.) On the simulation front, Tracey does have the tools to make large samples on the farms, but is holding off until 4.5.2 is ready, to avoid the reconstruction problems. She has concentrated mostly on making Z's so far, but doing W's also should be straightforward. We'll make at least 100K of each, using a simulation with the bluebeam, keystone and miniskirts disabled. Finally, Ken floated a plan for a uniform reprocessing of stripped data samples. We know that there are more improvements yet to come that will not be in 4.5.2, in particular improved cosmic-ray tagging, primary vertexing, and a good-run list. We hope to run a single, uniform reprocessing of stripped samples with these improvements, if time allows it before summer results are due. The reprocessing would be only for the purpose of adding in these few extra things; we would not rerun the entire production executable. If we run out of time, then we will at least package things up into AC++ modules in CVS. Andreas Korn -- G3X victory =========== Andreas reported that muon reconstruction with G3X passed an 800K test on the farms, with one crash unrelated to G3X. One problem found was that there is a text file with the particle database (convert PDG codes to GEANT codes) which had to be copied on the farms. Validation distributions show that everything looks fine. We're on track to have this on by default in 4.6.0! Thanks to many. Andreas brings goodies for everyone, but we got run out of the room for the next meeting before we could sample them! Eric James -- Progress on good-run list ========================= Eric has completed a good-run list for the range 139788 through 142718, which is what was covered by the 4.5.0 reprocessing. He even distributed the list to the group on paper. The requirements for a good run are integrated luminosity > 10 nb-1, the ANA bit on, Young-Kee's COT validation and Michael's muon validation passed, no bad news in the logbook, run type = physics, data type = beam data, and a trigger table with the word PHYSICS in it, but not the word TEST. We are reluctant to cut on the good-run bit set by the shift crew, because there is no obvious reason for declaring some runs bad in the logbook. Are there good runs marked bad by the shift crew that appear to be good? Yes. Of course, there are borderline cases as you look carefully -- is something in the logbook bad enough? So there were judgement calls. Result is 104 runs, with an integrated luminosity of 5.8 pb-1, compared to 7.1 pb-1 for the entire 4.5.0-processed sample. Many runs were eliminated, but most had very little luminosity. Next, we plan to send this on to Jimmy Proudfoot, so that the runs can be marked in the official database. We should remove the runs that were bad due to the COT from our bad-run list, but Eric said that all of those runs were bad for other reasons, too. Shouldn't be hard to extend the list to later runs, and in fact Michael has completed his work through 144673. David Dagenhart -- Update on CMX reconstruction efficiency ======================================= David measures the efficiency for finding a CMX muon by requiring that the second leg track of a J/psi does in fact reconstruct as a CdfMuon linked to a CMX stub, as Ken had described four weeks ago. The results vary with the pT range: 94 +- 14% for pT > 3 GeV/c, 48 +- 14% for 2 < pT < 3 GeV/c, and 11 +-7% for pT < 2 GeV/c, where there shouldn't be any muons anyway due to rangeout (which Patrizia knows as "absorption"). The last two numbers suffer from low statistics; there is less than two-sigma significance in the "not-found" muons. David's big advance is to account for all of the dead chambers in the CMX in defining the fiducial volume. He makes cuts similar to what Ken showed a few weeks ago on the first leg. On the second leg, he requires that the track be fiducial by 10 cm in the CMX, minimum ionizing, and some minimal track quality cuts. David fits the "found" muons to fix the parameters of the J/psi peak, and then uses that fit to measure the number of not-found muons. The results are statistically limited in general, especially in the restricted momentum ranges. Ken Bloom -- Update on CMU/CMP reconstruction efficiency =========================================== Inspired by David's work, Ken sat down to look at the CMU and CMP again. He fixed up some things from the last time. Most importantly, he added minimum-ionizing requirements to the second leg, and fixed a bug that allowed for the CMU to compensate for CMP inefficiency and vice versa. He cuts a little harder on the fiducial volume (but it doesn't make a difference, and the bluebeam is still called fiducial), and is much more careful about avoiding rangeout. Thus, he uses 1.5 GeV/c as the minimum pT for the CMU analysis, and 3.0 GeV/c for the CMP and CMUP analysis. The basic results are reconstruction efficiencies of 0.837 +- 0.054 for CMUP, 0.940 +- 0.066 for CMU, and 0.839 +- 0.044 for CMP. Ken tried to map out rangeout effects by looking at the results as a function of the minimum pT used for the analysis; it's a little hard to judge, but there does seem to be an effect in the CMP. In addition, the overall CMP efficiency feels low (at least to Ken). He tried making sideband-subtracted distributions for the second-leg tracks, but couldn't locate any region of parameter space that is the source of the inefficiency, except possibly for a softer pT spectrum for the not-found muons, which is statistically insignificant at this point. At this stage, the uncertainties are small enough that we can use these numbers for the summer analyses, even after hanging a substantial systematic error on them. But it's not clear that we understand the values of the numbers. This will require more data, but that is on the way -- the sample could easily increase by a factor of four once the 4.5.2 reprocessing is done and more events are stripped. We also have a few more knobs that we could turn and a few more tools to put together that could help us understand things. Ken and David will write a CDF note about this soon. Wolfgang Wagner for Yves Kemp -- MuonValidation ============== Yves has added many useful histograms to the MuonValidation module, which was basically useless beforehand. We're now looking at the BMU, we have a consistent naming scheme, and yes, there are plenty of plots, in general. (We agree that non-existent BMU chambers are in the right place.) Yves is also working on a program to make run-summary plots, look at quantities as a function of run number. These ROOT scripts can be run as a cron job, even. So it works, and we have to decide what to do with it next. In the medium term, we hope to feed back knowledge gained from the good-run studies into this module, so we can have the right plots easily in hand. Wolfgang Wagner -- Primary vertexing performance in W -> mu nu ============================= Wolfgang looked at the "W" skim that comes from 4.5.0 processing to understand the performance of the primary vertexing. At the moment, there is the vxprim module, which is the driver for the VertexFitter, which does the actual fitting. In production, there are three different modes, which differ by which tracks are used -- all defTracks, COT standalone only, and silicon outside-in tracks only. (Note that cuts used in all three of these modes are tuned for the beamline fit, not for efficiency.) As a result, there are three vertex collections. In the W sample, see 38%, 45%, and 23% efficiency, respectively -- pretty low. But of course there are lots of cosmics in there; this is a worst-case scenario. (The fact that the COT efficiency is lower than the defTracks efficiency is a puzzle, but at least we are seeing that there are improvements from 4.3.2, due to various tracking and alignment improvements.) But then, you can set up the vertex finder to always return a vertex, regardless of chisquared or what have you. The efficiencies go up to 53%, 52%, and 47%. Why only that high? Because there is a requirement of at least three tracks with pT > 0.3 GeV/c in the vertex, i.e. the inefficiency is all cosmics. So how to deal with this in terms of vertexing? Wolfgang advocates simply using the requirement of finding a vertex with something like the above cuts to eliminate cosmics, which is effectively a number-of-tracks cut. This ought to work fine in events that have only cosmics in them. The problem is the cosmic overlaps, where a cosmic muon comes close to a true collision. For those, Wolfgang suggests seeding the vertex finding with the muon, and if there are no vertices found in the vicinity, or if there is a bad chisquared for the vertex, then it is a cosmic. This would need some study, of course, to figure out what the cuts are. To this end, Wolfgang has put together some new interfaces to the vertex fitting, including one that can be called from analysis code and that can be fed a seed z0, or an initial set of tracks. Should the muon track be included in the fit or not? It would need study. Much debate and discussion ensued, which the minute-taker really couldn't keep track of. There are issues of efficiency and philosophy at stake. The bottom line is that Wolfgang suggests following two strategies. One is at least to run the default vertex-finder, but force it to find a vertex without regard to chisquared and the like, as was done two paragraphs ago. The other is to use the muon as the seed for a vertex. He will provide sample code and tcl scripts; Ken is already in possession of the latter.