Minutes of CDF Monte Carlo Workshop (25 April 2002) *************************************************** ------------------------------------------------------------------------- (7) Status of COT simulation (Kristian Hahn) Comparison of data/simulation done with: Data 4.4.0 J/Psi-> mumu, 167 events-> 20 k tracks (run# 138425) Sim: Pythia+QQ->cdfSim->ProdExe drift-model Penn& default ("Garfield") 450 events-> 20k tracks B -> Phi Ks0 Garfield is default in cdfSim, it is entirely parametrised (note 5050)-> Penn 5 x slower than Garfield. 1) First comparison plot: d0 (w.r.t 0,0, and not w.r.t beamspot)-> see beam-offset). As it is possible to move the beam position in cdfSim that would be a good thing to do- also correct for it in data to see actual width of d0. There are some spikes in data and Penn not seen in Garfield, not clear where they come from. Marjorie suggests that it might be track duplicates although deftracks (which were used here) should not contain any duplicates. (later plots enforces that idea) 2) Drift distance vs start time. Penn uses Garfield start time so as expected from that the plots look very similar. There is however a 150 ns offset in data which the simulation doesn't know about. Drift-time comes out as 15 mu/ns 3) Truncated mean width vs cot(theta) expected correlation: as dip angle increases path length increases, expect to see more charge on the wire. p>2 shows that effect more clearly in data. the slope of the "v" should be about 1, not checked. This correlation does by construction not show in the Garfield model (it is simply not put it) while it does show clearly in the Penn model. 4) sin aspect: There is an offset visible maybe because radial tracks are not exactly perpendicular to the cells driflines. (should be 0 if track is perp.) More positive tracks in data-> need expert to tell why we have that shift. 5) Width truncated mean vs log10p-> spikes show up Again, looks suspiciously like multiple tracks. There is a shape to the Garfield model that does not show up in data and Penn. 6) Drift distance Drift models are very similar as expected. Data has a slope to it, slopes down toward 1. However, there was a comment that usually they look flat and this must just a feature of that particular run. 7) Residuals Cut-of at abs(0.1). There is noise in data that is not reproduced in MC. Marjorie adds that we must understand multiplicity and occupancy before we will ever reproduce hits. Suggestions, comments: - pick W's as sample, to start with high momentum clean tracks. - right width might determine your two track resolution once tracking becomes more sophisticated - on to do list run stage0 on MC ------------------------------------------------------------------------- (2) Status of Time-of-Flight simulation (Bockjoo Kim) Comments: so far the data tuned parameters are read from files. Ideally (or necessarily) they should be read from the DB though, to allow smooth processing on the farm. Things are in offline already though so can be used. The simulation code has 3 levels . simple . moderate <- not so well developed yet . USRTuned TOFSimConfig.cc initialization and configuration TOFEventdata.cc parametrisation TOFSimAnalysis.cc check simulation results. examples/tcl in TofSim/test. Runs fine with 4.4.0int6. For comparison data are taken from a 2bar sample; MC from a 1bar sample. ADC distribution: some discrepancy, but do we expect them to be the same? with 2 different samples (2b,1b) shouldn't be too concerned that things are a little bit shifted. Marjorie suggests to start with min bias data to have low p tracks. see slides for more plots etc Action items: A run on farms (need parameters in DB) B need good size min bias data sample (good size being about 100.000events) ------------------------------------------------------------------------- (3) Silicon simulation: Physical CDM (Patrizia Azzi) See slides for an explanation about the model basically it means: implement the charge deposition from first principles- what happens in the silicon- thus it is supposed not to need not much tuning. Plot showing the hall effect shift (12mum)- we see two peaks in L00, which we wouldn't see if correcting for that effect. Sanity check plots: residual vs strip number. Geom. model shows two peaks. The physical model has floating strip description, more realistic and flat. can accommodate for N floating strips. 2 for now. SVX everything looks very good (both in L00 and SVX) ISL still problems. It worked at some point last autumn, but then the geometry description was corrected and things started to look strange (after implementing things like the zigzag bonds in layer 7 etc.) it talks to the geometry in a not very natural way, needs to be fixed still. We can use ISL to some extend but it needs fix (as Patrizia points out: we will fix it before we need it) Some plots show that the cross-talks doesn't seem to be quite right. (and she is not sure the number given in the talk-to is actually used later on) in a plot showing Nstrips/cluster the data clusters are wider than the model (for well defined regions phi<4deg and theta < 4 deg), this effect is smaller at larger angles as then we are dominated by geometry and not cross talk. (SVX4 chip dominates cross talk?) Cluster charge: Simulation lower than data. Could be absolute gain that is in the model, more likely the real culprit is however that the noise simulation simulates noise from a Gaussian around three ADC counts. In data the value can be much larger (or smaller) though. --> under investigation Q is noise Gaussian? A yes, looks good. Unbiased residuals phi side: -> go to tracking group, MC cluster are usually flatter, not Gaussian and the width should be about pitch/sqrt(12) However the two strip cluster seems to have rather 1 strip resolution and looks very Gaussian, should that be? check with higher pt. To do: ISL needs fix, fine tune cross talk, get noise from DB, understand unbiased resolution. ------------------------------------------------------------------------- (4) Silicon simulation: Parametric CDM (Susana Cabrera) Designed to be fast, main difference: delta rays are parametrized So far there is an upper cut off for using the restricted energy loss formula (Bethe-Block) at 10keV. Above that (10-500keV) the charge deposition is due to delta rays, done by Geant. (notes 4914,5069) However Susanna found that delta rays only really start at 30 keV which accounts for some oddities seen in plots earlier, so this will be fixed. Plot trackQC wedge: (about the same region in eta and phi is used for data/simulation) entrance angels<- more or less the same entrance angle-phi<- don't agree well. Maybe because of pt cuts (and the fake event generated pt spectrum does not match the one from data, maybe try pt(-4) instead) however Marjorie points out that the data don't look convincing either... need to understand that. They show a shorter range. z clusters ok, phi clusters: data flatter than MC unbiased residuals- same as physical model phi cluster: again x talk. To do: fix delta rays, x-talk, geom in L00 ------------------------------------------------------------------------- (5) Merits of stand-alone MC generation: Status of MCDB Project (Henry Frisch) Tradition: generate MC in the same job in which simulation and production are performed. Alternative structure: 1) new tools, techniques - LO generators - 1 loop on horizon 2) Simple and robust interfaces Les Houches#1 parton level generators to shower MC interface. Les Houches#2 STDHEP (now maintained!!!) not quite ready yet, interface shower MC and det. 3) Add manpower, work closely with theorists. 4) many people can validate things. 5) well documented from beginning 6) code maintained by authors 7) can run same events through cdfSim over and over Planning - precision comp. many channels. - need several generators - want to be able to interact with theorists 1) how many people are needed if we embed generators all the time? 2) do we have these resources? 3) what are benefits proposal 1) simple estimate of tasks, resources by physics groups. move to 2) hybrid scheme, Pythia, Herwig available. Also work on stand alone new generators, library of datasets. MCDB (Monte Carlo data base) * list of names of people working on that * get SM predictions in place now, then focus on simulation * have gamma/z interface (VecBos doesn't have that!) * tt= correlated spins (doesn't make much of a difference but still want to have that) * W+ large number of jets, large= up to 8 * get set for NLO studies-> get LO in shape first. Status: only few months old 1) have commitment from CD and Mrenna (STDHEP) 2) have 1.2 TB on STKEN 3) CompHep now has batch mode, help pages, more libraries 4) infrastructure for documentation well done, being used To do: interface to Tauola (working, needs cleanup) * MadGraph interface (security issues)- very close * Herwig&Les Houches? try out, doesn't obey HEPEVT * NLO generators * STDHEP-HEPG-Farm by pushing a button * run elsewhere (for example, Liverpool PCs) Structure of MCDB: code for CompHep, MadGraph, Pythia on formula public machine.-> stored in Les Houches format -> Pythia Herwig Isajet-> STDHEP (= flat ascii file, code how to read in generatorMods, HepEvt tools) after these steps comes the CDF internal part. Q: how to use own decays? if not too many: just re-decay using QQ, but for larger files problem due to correlations. (in the long run: get rid of HEPG bank and STDHEP and replace that with new things) there is a web-page where you can see what has been done-> all with CompHep so far, but CompHep is limited to W+4 jets-> MadGraph will take over from there. ------------------------------------------------------------------------- (6) Si simulation: Dead channels, noise, misalignment (Satyajit Behari) see transparencies (7) see above ------------------------------------------------------------------------- (8) Status of muon simulation (Michael Gold) Please see slides. Main point: want to understand data better before tuning the Monte Carlo- to prevent tuning the Monte Carlo to oddities in data ------------------------------------------------------------------------- (9) Grappa, a new MC generator for CDF (Soushi Tsuno) Grappa stands for Grace system and p p Anti p Based on the Grace system matrix element generation program Status can be seen at hep-ph/0007053 Manual: KEK report 92-19 Was developed for lepton physics and widely used at LEP. grc4f for 4 fermion processes and susy23 for supersymmetry. 1loop, R-parity also used at Hera: Grape, for dilepton processes. since 1999 there is Grappa_4b for 4 bottom processes: hep-ph 0204222 for CDF this is expanded: see note 5932 What is Grappa: Event generator based on automatic amplitude calculation program like CompHep , MadGraph. using Pythia and Herwig facilities for parton shower and fragmentation etc. Current process: specific generator processes are classified by subprocess number (ISUB) Takes helicity amplitude method while CompHep takes quared matrix element method averaging over spin --> good to x-check results with CompHep Most processes have a high generation efficiency and high generation speed. Grappa is available from the offline code from the header: addpkg -h grappa gmake grappa.lib, gmake grappa.tbin (note 5932!) Comparison plots with other generators: 6-body ME calculation allows to trace down to spin information of final state particles. not in pythia. Provides also helicity information you can call Tauola from Grappa (usually Tauola tends to need more information than generators generally provide) For more details and plots see transparencies ------------------------------------------------------------------------- (10) Calorimeter simulation: Gflash intro & PHA (Charles Currat) Please see transparencies ------------------------------------------------------------------------- (11) Calorimeter simulation: CHA (Soon Jun) Please see transparencies ------------------------------------------------------------------------- (12) Status of CLC simulation (Dmitri Tsybychev) See transparencies, remarkable agreement data/simulation, -->Q is it tuned/ how ? A: not really tuned, only the thickness of the beam pipe is increased a little. The normalized ADC looks a little bit worse but still good. NBR better than Pythia. ------------------------------------------------------------------------- (13) First experience with TrigSim on simulated data (Alex Cerri) I missed half of that, some notes: Use: want to simulate B-physics biases (life time, momentum) of SVT based triggers Still missing: decision bits for level 2. If you want to kill Silicon (not all of it of course) you need to pick a calibration run for the SiStripCorrector it is not sufficient just to provide a run number ------------------------------------------------------------------------- (14) Preview on MC production on the CAF (Frank Wuerthwein) CAF=Central Analysis Facility Main message: look into CafUtil/doc/UserGuide.ps which is regularly updated and contains all further information given. If you want to use the CAF you need to send email to Frank to be added to the userlist. He also will give another talk about usage and have a question and answer session about it some time in the near future. ------------------------------------------------------------------------- (15) Validation of electron simulation (Greg Vermandi) See slides for details, additional things. One of the plots that did not agree was the local Z for tracks/CES clusters. Marjorie reckons that should be fixed as there was a bug in the extrapolation of tracks to the CES. Should be fixed after 4.4.0 and might explain this. E/p also looks strange and data and MC don't agree. They might fit better if considering a fix from the MIT group/ Andreas. They find that there is about 30% of material missing in the tracker which Andreas added as an extra cylinder of material at the cot. That might make things look better here also. ------------------------------------------------------------------------- (16) W+bb= with different generators (Christopher Neu) See slides for details Note: HEPG bank only contains all short lived particles. If running cdfSim creates secondaries QQ didn't create this will not be appended- final state particles are then found in OBSP and OBSV (17) Recent issues with Isajet and PDF's (Carsten Rott) Carsten pointed to problems running Isajet. He tried running Isajet with an input file for light stop pair production and tried running on fcdfsgi2. He gets a core dump running RunMc on fcdflnx1 as well as fcdfsgi2 and his desktop. To Marjorie it looks like some other function overrides a common block- this bug might be the same seen in Pythia. It doesn't look like a genuine problem with the generators. Another problem mentioned is that sometimes the job becomes indestructible even with kill -9 (this problem remains to be solved rather by Liz Sexton-K. though. Carsten did manage to run a job with Isajet- however when requesting a specific PDF the job crashes again in the run II environment. Last problem mentioned is with Pythia: since version 4.4.0int5 there are no mother/daughter informations. Marjorie explained that this was supposed to be a fix to avoid a core dump, however it only moved the core dump. It should just be a switch to turn the info back on. Don't be surprised meanwhile if the info is missing. ----------------------------------------------------------------------- Tatjana Unverhau :) Dept. of Physics & Astronomy University of Glasgow Glasgow G12 8QQ U.K. -----------------------------------------------------------------------