News, Talks, Discussion Items

• Tracking.
  Robert Illingworth has successfully run with p11.06.00 and global_CalMuon-6.10 and sent this report.
  Daniel Whiteson gets essentially the same results with p11.06.00 and global_CalMuon-6.10 as he gets with his private executable. One problem is that with the pT cut of 3 GeV that was put into the global tracking tool for global_CalMuon-6.10 the tracking is less efficient (particularly in matching to stereo) than with the 0.5 GeV threshold Daniel used in most of his previous studies. This is thought to be due to the fact that narrower roads are used if the pT cut is higher. Under investigation. Memory usage needs to be checked too. The trigger board encouraged us to ask for a special run to test tracking when we think we're ready for it - i.e., we don't need to wait for next week's trigger board to do this. Gustaaf would be keen to run this too, in order to do some benchmarking in preparation for ordering new L3 farm nodes. Yann is currently unable to run global_CalMuon-6.10 to test tracking in the tau tool. He will consult with Robert or Daniel to sort out his problem.
• Examine: Michiel Sanders.
  Michiel has d0analyze running online under p11.06. He has made the following modifications to d0analyze:
  • read_event_daq used to take an event from the data distributor -> EDM.
  • rcp switch added to control how often (i.e., after how many events) the rootuple is updated.
  The problem of macro crashes when there is a conflict between rootuple writing and reading has been solved. An executable should exist on Michiel's private area later today. He has been in contact with Elliot Cheu and will provide some example root macros soon. Of course there are many additional features that we will want for the final system and technically a lot may change. For example, ideally we would like a single process to fill and display the histograms called from xgooey. However, having a simple system actually running online is a high priority and will not require us to do a lot of work that has to be thrown away when we implement the ultimate solution.
• Muons
  • Terry Wyatt showed some rejection factors for single muon triggers measured online for requiring a loose muon at L3. These and some more info on the new muon triggers can be found in a talk he gave last week at the W/Z meeting. Up till now L3 muon filters have been running with a Mark&Pass factor of 1. (That is, no rejection at L3). At the trigger board today it was decided to turn on L3 rejection on the four single muon triggers that already have L2 rejection turned on. Technically, this doesn't require a new trigger list; we just put the L3 Mark&Pass factors for these triggers to a number greater than 1.
  • Martin Wegner showed a comparison of local muon pT between L3 online and offline muon reco. The level of agreement was not as good as one would have hoped. It is thought the most important effect comes from the fact that the geometry is handled differently in L3TMuon and offline. We really need to get full offline-quality geometry for L3TMuon. Martijn and Martin will consult with Robert on how to use the newly implementet L3GeometryManager to achieve this. Martin also showed plots comparing offline track pT with L3TMuon pT.
  • For matching to central tracks (in p12) we need to set up a mechanism to handle solenoid/toroid polarity changes.
  • Martijn Mulders has made further progress in understanding the huge memory consumption we saw in p11.04. This was controlled by the .rcp mods we introduced into p11.05, but we want to make sure we understand exactly what is going on. For example, we want to make sure there is no residual memory leak or overwrite. The code has the feature that with the old .rcp parameters the code can find an almost infinite number of segments. In addition, Martijn has found a bug that appears only in L3TMuon. Multiple hits in the same layer are not supposed to be used to make a new segment. However, the code uses the local x coordinate to tell whether or not two hits are in the same layer. For reasons not understood, in L3TMuon the hits may have local x values that differ by ~1 mm. Martijn is putting in a check on the (integer) layer number.
• Jon Hays has modified l3fanalyze so that it will accept an ascii file that gives a list of tools and their reference parameter sets. He has also written code to take a trigger list and generate this tool list file. He has modified d0tools/D0TrigSim so that they will accept either the ascii file or the trigger list and do the correct thing.

Scribe: Terry Wyatt.