Introduction
The AlpgenInterface is undergoing a complete restructuring, according to the
new guidelines for GeneratorInterfaces
.
This page documents this restructuring
New Features
Validation
- What with using the SLHA mass line? Is this doing something bad? Not at all up till now. However, from the update notes from Pythia 6.420:
PYSLHA: protected some internal PYTHIA particles from read-in of
SLHA mass and DECAY tables, in order to avoid incompatibilities with
Pythia's hadronization and hadron decay machinery. The SLHA interface is
intended for read-in of non-SM physics, so we do not consider it a
strong restriction to protect Pythia's special internal codes and
all SM particles with masses less than 20 GeV from being
overwritten by SLHA read-in. People who do wish to alter, say,
the decay tables of B mesons, should not use the SLHA tables to
accomplish this, but rather use Pythia's internal updating routine
PYUPDA. A modification of the b-quark mass, for example, would
need to be handled through the PMAS array.
- W + jets
- Basic mother-daughter relations validation.
- Basic INORAD validation.
- Z + jets
- Basic mother-daughter relations validation.
- Basic INORAD validation.
- Why do we get the complete event record seen by UPVETO?
- I don't know, but Alpgen correctly disregards the six initial particles before passing them to the calorimeter.
- It also correctly disregards the daughters of INORAD'd particles.
- ttbar + jets
- Basic mother daughter relations validation.
- Basic INORAD validation.
- Why is it freezing? Why does it stop freezing when I use FourVectors instead of doing calculations manually.
- Always bitten by FORTRAN/C-style array differences.
Issues
C...PYUPRE
C...Rearranges contents of the HEPEUP commonblock so that
C...mothers precede daughters and daughters of a decay are
C...listed consecutively.
In standalone Pythia, a call to UPEVNT is always followed by a call to PYUPRE. In order to mimic that behavior, we do the same in AlpgenInterface.
- What is the "phantom event" at the beginning of DBPART?
- Solved: it was an extra call of DBPART in a wrong place.
- How to make sure the PDF sets are chosen consistently in ALPGEN and PYTHIA?
- Answer: we don't. See what happened in the 2009 ALPGEN gamma+jets by Sushil.
- How to make sure the CM energy is consistently kept around?
- Answer: we don't. There is no way to access the CM energy from within the
JetMatching
class.
- What ALPGEN uses for the jet clustering is the HEPEVT common block, NOT the HEPEUP.
FORTRAN routines
Here we describe the FORTRAN routines responsible for the matching in standalone matching.
UPINIT routine
- I/O
- Call ALSHCD - returns "PYT"
- I/O
- Read until "****"
- Read IHRD
- Read six masses (mc, mb, mt, mw, mz, mh)
- Read key-value pairs (PARVAL[NTMP] array)
- Read until "****"
- Read xsec, xsec_error, number of unw events, luminosity
- Call AHSPAR to setup parameters - this sets EBEAM.
- This sets every parameter except IHRD, the masses and the jet clustering parameters.
- PBEAM1=DBLE(EBEAM), PBEAM2=DBLE(EBEAM), IH1=1 --> these are tramp variables to set up HEPRUP later.
- Call PDFCONVH (what does it do?)
- Call ALSHCD
- Prepares INORAD
- Gets jet matching criteria
- Sets up the HEPRUP
- Calls ALSHIN (passes the six masses to PYTHIA)
- Sets LPRUP (originally it was 661, now it has a meaning).
The HEPRUP has to be setup as:
Parameter |
Value |
BEAM |
p,p,energy of CM |
PDFGUP(1,2) |
-1 |
IDWTUP |
3 |
XSECUP(1) |
AVGWGT |
XERRUP(1) |
ERRWGT |
XMAXUP(1) |
AVGWGT |
UPVETO routine
--
ThiagoTomei - 20 Mar 2009