• Archive code from note and paper.
• Sarah has put her code on her public afs area.

• Shared code repository which allows us to to co-develop in reasonable privacy but also allows the checked out version to build/link against the ATLAS code. This is documnented in more detail below.

* Mailing list:* atlas-ww@hep.ucl.ac.uk You can browse the archived mails (but at the moment only from UCL machines).

ATLAS note

atlas_ww.ps: Latest draft 5/11/05

Outstanding issues

• The AtlFast data was lost in a disk crash, but can be regenerated. This should be without pileup, since the pileup is unofficial/undocumented, and not a big effect anyway. We can just make a comment in the text.

• The pileup we used is not a big effect as long as a cell threshold of 1 GeV for low luminosity and 2 GeV for high luminosity is applied. Without these it is a big effect. This is now stated in the text. I guess though we should apply the threshold at 2 GeV for all the data.

• The smearing will be done on towers. We can't completely correctly reproduce smearing on jets by smearing towers whatever we do. And in fact, smearing cells is a better approximation to reality. If we take the radius-proportional term (by the the way, this proportionality seems to be based on a straight line drawn through two points, see page 272 of the TDR) and apply it to the tower radius, that should get the noise etc ok in that twoer, but it will neglect the noise in other towers with no true energy which may have contributed to the jet. I think the noise suppression threshold saves us - it should remove this as wellas the constant term. And Sarah has also tried increasing the constant term and shown we are insensitive to it. So I think this argument and holds and is the best that can be done at present, until there is an approved cell smearing in ATLFast.

• Underlying event model: should we use the same parameters as in the Rome samples? Or our own? Reply from Jon (second attempt, 22 Oct) I think we should use the same as the Rome sample; this is a reasonable set of parameters which was derived from Tevatron data. Other sensible options would be to use whatever is approved for the new production (is this decided yet?), or to use PYTHIA Tune A from Rick Field (as described in the HERALHC TeV4LHC workshops. The reason I say go with the Rome parameters is that is will facilitate comparison between ATLFast and full simulation results, and yet we don't have to wait for the new DC3 parameters. If the new DC3 parameters are already known, I would suggest using them, for the same reason. (Rome used: the parameters given on this page)

• Efficiencies and purities were discussed in the meeting on Thursday by Jon, Sarah, Stathes & Simon. Propose a two stage "measurement". First define a cross section which is (a) physically well defined and (b) in a kinematic region where ATLAS has reasonable acceptance. Then, once this is measured, correct it back to the inclusive WW rescattering cross section. The reasoning is described in the 5/11 version of the note (above) section 4. The physical cross section should be defined by the pT and eta of the W's, the fact that one is leptonic and the other hadronic, and by the kinematics of the tag jets. Note this is different from what we proposed on Thursday. I think we can use the W kinematics rather than the leptonic ones because the W decay is very well understood. And I think we need the tag jets in the cross section definition because otherwise the cross section would also include Drell-Yan type events. (We can't define the physical cross section in terms of an incoming W!).

• Text to be checked and finalised ACTION Jon, Erckan, Stahis and Sarah

Theory

We need to check that we are generating W+W-, W+W+. Sarah did this check. We are. We would also like to generate WZ and ZZ

ACTION Brian to document how to do this, and also the W decay flags.

We would also like to cross check with the Montreal code.

Trigger

(FLT, HLT, offline selection) Document which trigger chains the signal should get through etc here. ACTION Stathes

Selection cuts

The code is in ... . It started from the AnalysisExamples package.

electron

here

• ET>10GeV,
• isolation cut of 5GeV in dR=0.3
• isEM() & 0x07FF == 0

muon

To be selected, a muon must be highPt and have

• chisquared < 20.0,
• Muon Isolation cut of 5GeV.
• pT > 5GeV
• eta < 2.7

missing ET

Hadronic W mass resolution

pile up, jet finder dependence.

subjet cuts

top mass resolution

pileup and jet finder dependence This works in AtlFast & at hadron level. Not yet working in full simulation.

tag jets

how well are they modelled? how well is the rate known? How can it be checked?

hard pt

how well is it modelled? can it be checked?

minijet veto

is it really useful? how well is it understood? use new underlying event models/tunes.

background generation

what samples do we need? which generators? we need W+jet and ttbar samples with a ptmin of about 250 GeV. However, to get decent luminosity will require a lot of CPU so we should put this in as a standing request to the SM and exotics groups, but not sweat about generating it ourselves just yet - there is a lot of work to do on the signal.

detector simulation

how much with AtlFast, how much needs full simulation?

Signal Generation

PYTHIA Signal Production:

• Stathis has produced 60K events of the 1 TeV Scalar and Continuum Signal channels.
• The evens were generated using PYTHIA and the modified FORTRAN routine.
• There are 15 files of 4K events each in pool format. There can be in simple ntuples. If someone needs it let Stathis know.
• The files are located at UCL under: /unix/atlas1/sstef/wwScattering/Gene/ We must decide a common place to store them together with the Manchester samples.
• In the same directory you can find the jobOptions file (sampleJobOptions_pythia.py) for generating these events.

We'd also like some high PT hadronic Ws Foundation samples Action: Sarah to ask SM and Exo convenors

Stathis is looking at it. Will report on that as soon as there is an action.

Maybe we should we aim for someone to give a talk at next UK SM meeting (November 30).

Code Repository

recipe:

setup.sh your home requirements file.

alias gpcmt="export CMTCVSOFFSET=groups/WWscattering;cmt" alias offcmt="export CMTCVSOFFSET=offline;cmt"

to check-out a tagged version:

to check-out the head version gpcmt co WWscattering

to check-out from the offline packages: offcmt co

*********Guidelines for handling the CVS repository of the package

1. source setup.sh in your working area

2. alias gpcmt="export CMTCVSOFFSET=groups;cmt"

3. gpcmt co WWscattering (if you want to check out the head version) or

gpcmt co -r WWscattering-XX-XX-XX WWscattering (if you wanna check out the XX-XX-XX tag)

4. Make the changes/fixes. Say for example that you have fix something at src/wwFrameAnalysis.cxx and add a new file src/aNewFile.cxx

At one level up of the cmt directory:

5. Update the Log File of the changes you've made.

6. cvs add src/aNewFile.cxx (do that for all your addings!)

7. cvs update -A (to update the fixes...)

8. cvs commit -m 'A message to describe the main change'

If you want furthermore to give a tag, go one level up of the tag that is being used (WWscattering-XX-XX-XX) and do:

9. cvs tag WWscattering-YY-ZZ-XX

Useful Links and Papers

• ATLAS UK Standard Model discussion page
• 2002 WW Paper
• ktjet
• Interesting papers... * Soft-gluon effects in WW production at hadron colliders * http://www-spires.dur.ac.uk/cgi-bin/spiface/hep/www?rawcmd=FIND+EPRINT+0608019+AND+EPRINT+HEP-PH
• Montreal Wiki page.

Meetings.

• • Thursday 3rd Nov at 3pm UK
  • Thursday 14th Nov at 12 noon UK