Running EvtGenLHC with MC-TESTER

Running EvtGen

EvtGen is a B decay Monte-Carlo Program by David Lange and Anders Ryd. Although I did not test it, I believe running MC-TESTER with it should be quite straight forward. EvtGen has an internal data structure which contains the event information (EvtStdHep). This structure is a C++ representation of StdHep When an event is generated with the EvtGen::generateEvent() method, the contents of EvtStdHep is dumped to StdHep. The StdHep event record standard is built on the HEPEVT common block (to my understanding). So once the record is in this format it is readable by MC-TESTER. The only configuration for MC-TESTER is to set the record type to HEPEVT with Setup::EVENT=&HEPEVT. The MC-TESTER methods MC_Initialize(), MC_Analyze(int pgd_code) and MC_Finalize(); should be called in the main loop.

Running EvtGenLHC

EvtGenLHC is a version of EvtGen installed on afs at CERN by the GENSER LCG group. Is it a little different to the version of EvtGen from David Lange and Anders Ryd because it's been modified for pp collisions at 14 TeV and because it is used in environments where HepMC handles event records rather than StdHep. In particular, I found that the EvtGen::generateEvent() methods had been labelled as obsolete and the line of code in this method which dumped the event record to StdHep had been removed. Perhaps this is because in the environment of the LHC experiments, event records are never stored as HEPEVT or StdHep. I looked at how ATLAS uses EvtGen (It uses EvtGen currently, not EvtGenLHC). It basically looks for Bs inside a HepMC event. It then generates a decay with EvtGen and copies the new information from EvtStdHep to HepMC using a simple interface which is part of the ATLAS code.

To get EvtGenLHC running with MC-TESTER I copy the StdEvtGen event record into StdHep in the main method. To do this I needed to use the StdHep libraries. (I included stdhep.h from /cern/pro/include/stdhep). EvtGen's event record class, EvtStdHep, follows the HEPEVT common block structure so it was simple to copying each element of the data structure. For example if we have an instance of EvtStdHep called "evtstdhep", the number of particles can be copied to "hepevt_", the HEPEVT block using:

hepevt_.nhep = evtstdhep.getNPart();

To see how the other the fields (such as mother/daughter points and 4 momentum were copied see this file from the following example.

Example

This example is in MC-TESTER-1.21 (along with some bug fixes listed here and on savannah).

Here is an example of the code and output for running MC-TESTER on the B-decay package EvtGenLHC (version 5.15) as described above. 500,000 B- decays were compared to B- decays in PYTHIA 8.1.

Output Files Produced by MC-TESTER

pdf comparison booklet - tester.pdf
root file from generation step of EvtGenLHC - mc-tester_evtgenlhc.root
root file from generation step of PYTHIA 8.1 - mc-tester_pythia_8_B.root

Input Files

code with main method to generate B-decays in EvtGenLHC - evtgen_test.cc
MC-TESTER configuration file - SETUP.C
My Makefile - Makefile
DECAY.DEC
evt.pdl

I linked with clhep 1.9.3.1, photos 215.5, pythia 6.227.2 in /afs/cern.ch/sw/lcg/external/

Modifications Needed to MC-TESTER

Because of the large number of B-decay modes in the above example, some modifications to MC-TESTER were made in order to reduce the memory usage and amount of output. Without this, I could not run for more than O(10000) events before running out of memory in both the generation and analysis steps.

I added a cut-off for the maximum decay modes in the TDecayMode.cxx file ("MAX_MODES"). This was set to 200 for the example above, so only histograms were generated for the first 200 decay modes. Others were still kept in the branching fraction table. For the analysis step I also altered BOOKLET.C as modes without histogram were previously listed in the contents page and given an (empty) section in the histograms part of the booklet (which takes up a lot of room for several thousand decay modes).

I also discovered some bugs with the latex formatting of particle names. HEPParticle.cxx was changed to fix this.

Another bug uncovered during these tests was the lack of conflict checking for decaying particle pdg ID between SETUP.C vs. MC_Analyse(int pdg_id). This type of error can result in the decay channel listed on the front of the booklet not matching what was actually analysed. Two fixes were added to Generate.cxx and Generate.h:

Print error message and exit if conflict is seen.
Added method MC_Analyse() to avoid confusion about having to define the decaying particle twice. This method assumes the id from SETUP.C.

Unfinished Business. Unknown Errors. Extra Comments etc.

It was not clear to me which versions of photos and pythia were compatible with the EvtGenLHC versions installed on afs. I suspect that this could be the cause of some complaints I get when I run the example above. For example:

Advisory warning type 7 given after 0 PYEXEC calls:
(PYUPDA:) Kinematically unallowed decay of KF = 18

I also get an error when I try to decay an Upsilon(4S):

EvtGen:Asking to make a different number of daughters than what was previously created.
Will terminate.

I asked Anders Ryd about this and he said the error message was produced when BBbar coherent states were produced and one of the B decays needed to be regenerated. He had one suggestion that maybe some changes were made in the LHC version and coherent states like BBbar are not taken care of because it's not important, unlike the B factories.

I have asked the LCG group about these, so maybe there will be some answers coming soon.