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.
-----------------------------------------------------------------------