Minutes of 01-Mar-2006 Telephone Meeting

• Notes from 07-Feb meeting

• Test Beam / Data
  1. Progress on Task List
     Had received replies from Erika Garutti (DESY), encouraging discussion at the UCL meeting + integration of ECAL/HCAL aspects (e.g. logbook, monitoring, understanding beam conditions), and from and Zhiqing Zhang (Orsay), noting areas in which Manqui Ruan (LAL student) was working. These have been added to the list. Hope for more news on readiness for TB itself at UCL on Monday, expect Goetz Gaycken will talk there.
  2. monitor application - George
     New version of his monitoring suite available for download. Has changed naming of client/server to gui/sender to avoid ambiguity. Can have multiple senders to single gui, therefore could integrate data from ecal/hcal/daq in single panel if thought generally useful for shifts. Details of the new code see his email to UK SW list. Will present this at the UCL meeting on 6-Mar. He needs latest version of DAQ "offline" code, Paul will arrange this.
  3. Position resolution study - Anne-Marie (LPSC pages)
     Discussed Anne-Marie's study which will be presented also at UCL on 6-Mar. Still difficulties for most in the choice of coordinate system for the test beam prototype in mokka (z=0 plane is the module 3, thickest W plate, carbon fibre exit face). Looks difficult to change this now...
     Some differences seen in the position resolutions for configurations of ECAL+ air/drift chambers/scintillators may arise due to multiple scattering in air being distributed along entire path length so may have larger effect than its integrated X₀ would indicate relative to that of the drift chambers, as beam starting point was in some cases ~10m upstream of ECAL. (z=-200mm beam starting point is just in front of ECAL front face.) Also, discussion about what (x,y) was correct to pass through full acceptance of the drift chambers in Mokka (in absence of recent steering commands in Mokka which allow arbitrary transverse movement of drift chambers so that user can ensure dch hits available for any beam position).
     George noted that when he used 1 GeV e^-, he found position resolution of 2.5mm, in agreement with Anne-Marie's "only ECAL+air" configuration.

     Fabrizio has many hits generated in scintillator and drift chambers, mostly at very low energies, and has increased thresholds above which these will be stored such that only primary hits generated by the beam itself are recorded. Seemed acceptable in terms of data size and quick study by DRW, therefore Fab. will commit to HEAD of Mokka. Had stored the hits in scintillators as SimTrackerHits to allow 3-momentum of MC particle which generated the energy deposit to be available in LCIO, but now that a new "pseudo detector" was implemented immediately in front of the ECAL which would allow this same information to be saved, it might be more appropriate to revert to SimCalorimeterHits instead.

     With his recent work, items 1 and 2 on the "Simulation" Task List would now be completed.

     Follow-up on thresholds in committed code, 03-mar-2006

• Simulation / Physics Studies
  1. ECAL energy resolution
     Mike reported that a brief note was in preparation on the RHUL physics studies (NKW - would be helpful to have this soon as input to WP5 report to Oversight Committee). On energy resolution studies, he had found ~12% difference in ECAL calibration between geant 4.7 and 4.8 as per recent emails. He found tha LDC01 energy resolution was ~16%/sqrt(E) compared to 12%/sqrt(E) for LDC00.

     Michele had studied pions in LDC01, and found energy resolution of 42%/sqrt(E) +8%; and found the mass resolution in ZHH events was poorer in LDC01 than LDC00 (presumably due to smaller number of layers in ECAL?).

     Fabrizio reported on the SM background event samples which he had looked at in the latest version of mokka. Previously he had problems reading the (stdhep) event samples from SLAC. Has now been able to read the stdhep files from SLAC using revised version of libstdhep (c/o Willy Langeveld) which should be in the HEAD of mokka. He had processed 1k events (of 1M) in each of LDC01/LDC00 as a test, using e⁺e^-- > llbb and ll4b events, and starting to look at mass distributions for reconstructed Z's. Also looking at performing lepton-id before jet finding in these events.

     Michele had tried using information from both TPC and calorimeters in LDC00 for Z->e⁺e^- channel of ZHH events, found a better mass resolution using the calorimeter than TPC in LDC00, and the reverse with LDC01. Wenbiao and David W. had also found significantly poorer resolution in LDC01 (~14%/sqrt(E)) than LDC00 (~10%/sqrt(E))(see their contribution to LDC Detector Outline Document) for single electrons. The difference between their results and those of Mike et al are likely to arise from different method used to define resolution, e.g. DRW/WY use fit to peak position, they will follow up for completeness.

  2. MAPS simulation in Mokka, incl. LCIO CellID0/CellID1 (.pdf) - Nigel
     Summary of some recent discussions on how to implement MAPS pixels in Mokka, with Anne-Marie, Paul and Yoshi, see slides for details. Issues include that single int CellID is not sufficient to store unique value for each of ~10¹² pixels; that to apply efficieny mapping/digitisation (in Marlin/LCIO analysis, outside Mokka), would need to have positon of individual energy deposits in transverse bins of 5x5microns²; that the angle of incidence is also a factor, so need ideally need momentum vector as well. Noted also that Yoshi checked driver code Ecal02/SEcal01 to verify detailed structure of alveolus layer structure in ECAL for LDC01 is same as in TESLA TDR model D09, i.e. each alveolus layer is (without changes to defaults in steering file) 2.1mm thick, consisting of 0.5mm Si sandwiched between two 0.8mm layers of PCB, as described in Mokka notes).

     Paul noted separate but related problem with random numbers in Marlin - we would have to ensure that every event could be reproducibly seeded with its own sequence (not necessarily unique...), and have to consider that events would not always be read in order, may be analysed in different files, etc., so need specific property of an LCIO event, e.g. combination of event number +...
     Also need a high quality random number event generator which can access probabilities at the level of 10^-13. (NKW: In CLHEP, Random, there are many random number generators available, Ranlux, Ranecu, etc. - looks like there are several choices and many validations of quality, etc., e.g. ZOOM @FNAL.)

• CALICE ECAL meeting, UCL, 6-Mar
• 04/06-Apr-2006, ILC European s/w+physics meeting, Cambridge.

  Please register now for this if you have not already done so, accommodation becomes difficult to arrange at short notice!