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.
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.
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.)
Please register now for this if you have not already done so, accommodation becomes difficult to arrange at short notice!