Talks

• Comparison of track-based and hit-based primary vertexing in z: Chris Barnes.
  Chris compared the performance of the p12 version of the track-based primary vertexing in z with that of the hit based vertexer. The bottom line appears to be that the track-based vertexer has substantially higher efficiency and purity for all the classes of events studied. Discussion:
  • Could we run the hit based algortithm on events where the track based algorithm fails to find a vertex?
  • What are the prospects of extending tracking into the "overlap" and forward regions? We would need to investigate new tracking algortihms (e.g., histogramming) in order to get tracking coverage extended.
• Technical issues and tau studies: Yann Coadou
  • Using the new facility to make comparisons of on- and off-line results in l3fanalyze, Yann finds discrepancies in, e.g., E_tau, of order 10^-5 level. (This is rather less significant than his comparisons on older data done some months ago. Will be followed up.)
  • l3muon crashed in p11.10. Thought to be due to a fix that was not propagated to the test release (again)! Also, p11.10 changes for muon reco went in without Martijn being alerted and therefore without explicit checking/approval by L3 muon group. This is contrarary to our agreement with the offline muon guys.
    Action item: Martijn will make sure this doesn't happen again.
  • Running L3 tracking on MC or data "is a pain".
    Action item: In the short term we need documentation on the steps necessary to get correct L3 tracking results on MC and data so that idiots can use it. Daniel Whiteson will provide this.
    Action item: Actually, we need web pages that describe the 10 most frequently made trivial mistakes that catch people out when trying to run L3 trigsim. PLEASE send Terry Wyatt items and he will put them together. Just a one-liner to point out a problem would be better than nothing, but a more detailed explanation of how to avoid it would be very much more useful!
    (In the longer term we need more and more of this technical trivia, which causes endless grief even for experts at the moment, to be handled automatically (d0tools, runtime environment, etc).
  • Tau studies: Plots showing a large number of tracks with no stereo information were inconsistent with Daniel's results. After meeting this was shown to be due to somehow incorrect running of the simulator. The conclusion we came to in the meeting of the need for a p12 code change to allow phi-only matching in the tau tool is suspended, pending further investigation.
  • Some new Monte Carlo files with p11.09 d0sim are now available that include simulation of calorimeter non-linearity and more realistic simulation of noise. Comparisons with old MC and data have just started.

Discussion Items

• Terry Wyatt and Elizabeth Gallas have been putting together the new trigger list, including standalone L3 tracking filters. This means that L3 tracks need to be promoted to be physics objects rather than data objects, so that they get stored as physics results. Some discussion ensued about how best to achieve this technically.
  Action item: Daniel to discuss this further with Jon and then either to implement a physics tool wrapper around the currently existing tracking tool or to convert the global tracking tool to be a physics tool and ensure the tracks are stored.
• The dip in the phi distribution of L3 tracks seen in the vertex examine program will be investigated by Michiel Sanders. Information from Mike Hildreth obtained after the meeting is that there has been no change to the cft hit maps in over a month (and even those affected only stereo, which are not relevant to the problem).
• L3 thumbnail:
  Peter Tamburello has volunteered to design and implement the L3 part of the thumbnail. He has started to ask us a lot of awkward questions! For example:
  • The previous official design calls for typically 4 or 5 16-bit words for each L3 physics object. This is almost certainly grossly inadequate for detailed technical studies and precise (per mille level) estimates of trigger efficiencies. For example, consider electron candidates; they have E, eta, phi, emfrac, three transverse shower shape measurements, track match information (track id?, p_t, match chi_squared), preshower match information. We need to think carefully about whether or not we need all this information on the thumbnail, how much precision is needed and how efficiently it can be packed.
  • Should people doing detailed technical studies and precise estimates of trigger efficiencies be expecting to use DST rather than thumbnail? (This would be particularly bad for those of us working outside Fermilab.)
  • Items that came up in the discussion that have a wider relevance than just the thumbnail:
    • One particular feature of the current electron filtering is that we define new instances of the electron tool to correspond to different cuts on emfrac, shower shape, track match, etc. Although there is some motivation to do it this way it looks like it would be better to have only one electron tool which calculates all the relevant quantities, which are then cut on in the filter. In this way we would avoid unnecessary duplication of L3 physics_objects corresponding to the same electron.
    • How do we most efficiently associate physics objects in the data structure, e.g., central tracks to lepton candidates?
    • How do we most efficiently associate filters and scripts that are satisfied to the physics objects that caused them to be satisfied? Do we need filter_results objects?
  In addition to thinking about these difficult questions, Peter will start to implement the basic framework and store the bare minimum information for each physics object.
  ACTION ITEM FOR ALL TOOL AUTHORS: HE NEEDS YOUR DOCUMENTATION OF THE L3 PHYSICS OBJECTS NOW !!!

Scribe: Terry Wyatt.