Talks, verbal reports

• Update on tracking geometry for L3: Robert Illingworth.
  Full offline geometry is now available for the tracking detectors. Daniel Whiteson has checked that using this he gets the same results as if he uses the standard offline geometry.
• Using stereo SMT information on tracks that have only axial CFT: Daniel Whiteson.
  The global tracking has been updated so that axial-only CFT tracks are matched in r/phi only to SMT, but then stereo and z information in SMT is then searched for. Initially, the main motivation for this is to improve the performance of the track-based primary vertex finder. Chris Barnes will report on this at next week's meeting.
  Daniel also presented some timing information. Using the debug version on d0mino the time per event with the latest version of the code is 150 ms. It look like this will be fast enough, given that we'll be running the maxopt version on the L3 farm, whose nodes are 1 GHz Linux cpus. The unpacker time is thought to be 30, but in which units we weren't clear.
• Checks of data taken with p11.04 and processed on the offline farm: Yann Coadou.
  • Yann has found that the L3PhysicsResults are empty on reco output files produced on the offline farms. This problem was reported three months ago and a change expected to fix the problem was made. Obviously it didn't work. Yann will chase this with the reco experts. The fact that it took us three months to notice, clearly reminds us (the L3 algorithms group as a whole) that our monitoring leaves much to be desired.
  • Yann has found a new potential pitfall in running tsim_l3. He tried to use a level3.sim file that happened to have been created when the calorimeter was out of the run. In this case, the crate list in the level3.sim file doesn't have calorimeter, which means that no calorimeter data was unpacked.
    Short term solutions:
    • 1) Use a level3.sim file that is created during a normal global run.
    • 2) Just remove the crate lists from the .sim file completely; the L3Runconfig tool will then use the default initialisation, which will work fine.
    Medium term solution: Now that the muon and tracking unpackers are "dynamic" the only detector that needs the crate list facility in the .sim file is the calorimeter. Since this is anyway very stable perhaps we should dispense with this option or at least have a flag that can turn it off.
  • d0_analyze issues: (some of which comes from Yann's discussions with Dugan after the meeting):
    • event_info is now included in the executable and will be in the default rcp of d0_analyze in p11.05.
    • It is not understood why D0Analyze_x is present in some releases, but missing in most of them. Dugan will take this up with the release managers.
    • Getting d0_analyze running on the offline farm. We need to supply the list of tool names that have been active in a particular run. Our ideal solution would be for an automatic procedure to run on the farm:
      • Query runs database to get trigger name.
      • Query trigger database to extract relevant tool names and write a file containing this info.
      We should push for database manpower to be provided to do this. Some debate about whether or not we should in the meantime provide a fixed file containing the tools we are currently running.
• Analysis of test runs for L3Muon online: Christophe Clement/Martijn Mulders.
  • Christophe will complete work on the new unpacker by bringing together all the material he has presented in a Technical Note.
  • Timing per event (ms) for p11.04.01 (maxopt) on a 1 GHz clued0 node:
    • Unpacker. <2
    • Local muon tracker (default rcp). 70
    • Local muon tracker (+ Christophe's L3 tune of number of iterations and step size). 40
    • Local muon tracker (+ Martijn's tune of numbers of allowed segments). 25
    • Running full trigger list on a global_CalMuon dataset. 420 This is an overestimate: it needs repeating with the L1 trigger bits used to decide which L3 filters to run on each event.
  • Number of single muon triggers with at least one loose L3 muon goes down by 1-2% with Martijn's tune of numbers of allowed segments. This is probably a resonable estimate of the resulting loss in efficiency, but it would nice to check this fraction on the sub-sample of the events that have a tight offline muon?

Discussion

• How should we input to script-runner the various pieces of steering info that may vary run to run? These vary from very important pieces of information that need to be tracked: such as which geometry files should be used, to things that really don't affect performance at all and are just "administrative" details, such as which online machine the monitor data should be sent to. RCP is a bad place - change requires a new code release. Trigger list is where we currently do this, but this is not really appropriate either. Perhaps we should have (another) flat file that would be logged in the runs database?
• Other people are re-discovering our Mark&Pass bug in p11.01.00 data. The L3 bugs page has been updated with information provided by Yann. We should advertize this information more widely.
• L3 preparations for trigger workshop on 22nd-23rd April: We should use this opportunity to expose to the wider D0 audience our wilder ideas, things that we think may be controversial, appeals for extra help, worries, etc. Terry Wyatt will send around by email his list, but input is solicited from everyone on this.

Please let Dan and Terry know if you expect to present something.

Scribe: Terry Wyatt.