From kenbloom@umich.edu Fri Jun 14 21:55:34 2002 Date: Wed, 22 May 2002 15:13:24 -0400 (EDT) From: Ken Bloom To: cdf-muon-offline@fnal.gov Subject: muon meeting minutes for May 15 Muon Offline Meeting -- Minutes ================================= 15 - May - 2002 ---------------------------------------------------------------------- Ken Bloom -- Announcements and sample/data processing issues =============================================== In the "announcements" category, we only have six weeks until preblessings for the Rochester meeting (for which we are trying to do some demonstration analyses, remember), and plenty of work to do before then. Also, release 4.6.0 will be frozen this week. We expect that the G3X extrapolator will be on by default in this release; Andreas has made some fixes, and they will be tested on the farms soon. Ken then went over the status of datasets and processing. Anyes's skims were unfortunately corrupt due to a typo in her scripts, and they should be used with extreme care, if at all. However, she is in the process of remaking these skims; this will be done shortly, and Anyes will send out mail about it. However, we've always known that this is a temporary measure. At this moment, the farms are reprocessing data from the 8x20 era with release 4.5.0, and this processing will be the basis for any summer results. The farms are currently working on Stream J, which includes mostly lower-momentum muons, some of which are of interested for trigger and efficiency studies. Processing of Stream B, which includes the high-pT muon triggers, should be underway tomorrow, and could be complete within just a few days. At that time, Alexei and Anyes will work to bring the output over to fcdfsgi2, and to make W and Z samples from them, pretty much in the same way we did before, but we will probably consider loosening a few cuts. In particular, there is currently an AND of muon matching cuts in different systems. While this is the sort of thing you want for an analysis, it's probably better to have an OR for a skim. Once these skims are made, we will consider them the "official" samples, for this summer at least. The only expected changes would be adding in more data, and possibly running some refined processing, such as an improved primary-vertex finder, and improved cosmic-ray tagging. This sort of processing would not require us to re-run production. Ken then proposed a scheme for Monte Carlo samples. The current simulation is clearly too good, as all channels are on and working, which is not the case for the detector. The proposal was that for the purposes of summer analyses only, Mike Gold and Ken would put together a degraded simulation, with the CMP bluebeam, CMX keystone and CMX miniskirts turned off. We would then make substantial samples of W and Z events on the farms with this simulation, to serve as a uniform dataset for people to analyze, measure acceptances in, and so forth. Some debate ensued. A number of people expressed the concern that these special samples would be used for too long in the future, and that users would get things wrong in the future as a result. Everyone agrees that something of a hack is required here -- what we really want is a mechanism to drive reconstruction or simulation off of a hardware database of live and dead channels, but we don't have that yet. For now, the options available to solve the proximate problem are 1) the above, with a special simulation program, 2) use the standard simulation, with a special reconstruction that ignores the hits in the sections that are currently off, or 3) use the standard simulation and reconstruction, and let individual users take charge of knocking out systems that are off. (Variants on 1) or 2) would have us at least create talk-to switches to turn things off.) There was substantial feeling in favor of 3), even though that would mean that each user would have to get things right. A decision will be taken soon. Discussion of good-run list work ================================ One of the most important things we must do for the summer is to pull together a good-run list -- to know which systems are good when, and to make sure we don't use data (and don't sum luminosity) from runs when things are bad. Any work on analysis, efficiency studies, etc. should be done only with good runs, of course. There are two main efforts underway on this right now. Michael has been busy making plots run by run as a way of determining data quality. (See his plots at http://lotus.phys.nwu.edu/~schmittm/cdfmuon.) These are typically plots of occupancies and hit times/widths and kinematic distribution, often as a function of detector piece. It's been slow going, but many of these plots are in the MuonValidation module, so will be made automatically for runs processed on the farms. Eric, meanwhile, has been keeping track of good and bad stores, and then looking at runs within stores, checking for obviously bad things, e.g. COT dead. He pointed out that the samples coming out of the farms are being made without checking the good-run run-summary bits. Are these bits, which are set in the control room, at all meaningful? We don't really know, especially for older data. Eric spent some time comparing Stream A vs. Stream B; it looks like there are events in B that are not in A. There doesn't seem to be anything special about these runs; it's just random. Is this express A or farms A? Eric said that it's whatever Greg did; he thinks that things came from the farms, rather than the express stream. (We know that the express stream doesn't process every run, typically because silicon constants are missing.) Whatever is done on the farms should be consistent between A and B; they have a consistent "good run" list. But then, comparing consistent runs between the two, Eric sees a small excess in Stream B for the CMUP triggers, which should not happen -- Stream A CMUP is supposed to be exactly the same as Stream B CMUP. Kevin pointed out a mechanism for effects like this -- there were operational problems on the farms that led to duplicate events being written out. This is supposed to be fixed now, but we will need to check this again! Eric is still in the preliminary stages of looking at things. The hope is that between Eric and Michael's work, we'll be able to put together a good-run list for muons. We will put these results into the good-run database (and the ETF is doing the same). Then we want to make sure that there is an interface from AC++ to that database. If it doesn't exist, then at least we will give the list out to people. Un-Ki has been making his own good-run list, by binning the detector into 12 phi bins, and looking to see one good track, cluster, electron, and muon per bin per run. He eliminates low-luminosity runs before doing this. We agreed that this will be useful as a necessary but not sufficient condition for stating that a run is "good." Un-Ki Yang -- Resolving the apparent problem in L3 cross section ================================================== Last week, Un-Ki showed a plot indicating that the CMUP18 L3 cross section appeared to drop around the time that we started running all reconstruction in L3, and also the scatter of cross sections from run to run was reduced. The drop was a statistically-significant 12%. How could that be? Especially while the electron cross section remained flat? Un-Ki showed that it's not a luminosity problem; if you normalize to the W rate, it's still there, although not as obvious. It's also not due to changes in the L1 trigger rate, and it's not associated with specific regions of the detector. It turns out that Un-Ki had cosmic-ray contamination; he wasn't removing them efficiently. One can see that the cross section falls with increasing instantaneous luminosity, implying an effect due to the constant flux of cosmics. With tighter cuts (requiring five tracks per event), the cross section flattens out again. But why did things change when they did? Why when all-reconstruction was turned on? That's when luminosity went up, and stayed up, is the claim. David Dagenhart -- Checking the CMX drift velocity =============================== Last time, we saw indications that the CMX reconstruction efficiency appears to be low, so why? Could we be losing stubs? David looked at whether the drift velocity, which were estimated a year ago on events that were probably background, could have some effect. If it was very wrong, we could lose stubs. David looks at the CMUP4 + SVT sample, to get J/psis where the second leg is unbiased. He asks for a second leg is CMX, |dx| < 30, and various other sensible quality cuts. Looking at the dz distributions for the resulting CMX muons, David sees results that are consistent with Run 1, although maybe shifted a little to the high side. The dz distribution must be used for a drift-velocity measurement, rather than more conventional methods, because the chambers are not parallel to each other. However, the statistics are limited -- 31 events. So this is probably not the source of a muon inefficiency. Brief discussion of primary-vertex finding ========================================== Right now, the primary vertex looks like big trouble for an analysis for this summer -- Eric found that the efficiency is only 66% in W -> mu nu events. This really has to be fixed. Ken stomped into the tracking meeting earlier in the day to present a solution of his own, based on z0 values for COT tracks, and asked that a uniform recommended solution be constructed. He was assured that some good work on this is being done, and that a recommendation, all packaged into code and everything, should be available on a two-week timescale. If it isn't, we'll revisit the issue then.