SWGuideLHEInterface

Complete: 3

A guide to the CMSSW generic Les Houches Event interface.

Support for LHE text files, LHE EDM products and the MCDB database, as well as showering generators.

Introduction

The Les Houches Event file format (LHE) is an agreement between Monte Carlo event generators and theorists to define Matrix Element level event listings in a common language. HEP event generation can typically be split into the following steps: Matrix Element calculation, Parton Shower, Underlying Event and Hadronisation. Usually the physics event of interest, as well as the cross-section information is done with the computation of the Matrix Element (PDF evaluation, phase space, amplitudes, spin correlations, etc...) and the remaining steps are used to evolve the parton-level event to its final state. All these secondary steps rely heavily on models and are generally independent from the Matrix Element calculation. Therefore only few, typically multi-purpose event generators, implement those additional steps. Examples are Pythia (6 and 8), Herwig (Fortran and C++ versions) and Sherpa.

Most of these multi-purpose event generators provide a limited set of Matrix Element (ME) processes, and often only in LO. Alternative Matrix-Element-only Monte Carlo event generators exist, like MadGraph, ALPGEN, HELAC, and so on, that provide more flexibility in Matrix Element calculations, like e.g. being able to generate additional hard emissions on Matrix Element level, that would otherwise have to be approximated by the Parton Shower in a less precise way (typically the Parton Shower (PS) underestimates additional hard emissions and should preferrably be used only the soft and collinear case, whereas the (LO) Matrix Element calculations can describe those better taking into account all possible Feynman diagrams int the hard process). If such higher-order Matrix Element calculations are to be combined with Parton Showers of any multi-purpose event generator, a matching procedure has to be performed in order to avoid double-counting of emissions between the ME and the PS. Generators like MadGraph/MadEvent or ALPGEN come with their own preferred matching prescription (MLM-style jet matching), which should be used preferrably. Also more recent Parton Showers come with an alternative matching procedure called CKKW reweighting which exploits knowledge of the Sudakov form factors during the Parton Shower evolution to reweight the events.

Another big use case for alternative Matrix Element generators is to obtain calculations processes that are not covered by the multi-purpose generators, like new physics (anomalous couplings, exotics, ...), where the primary decay of the new particles is done inside the ME generator into known standard model particles, so that the Parton Shower can take over (or into invisible particles). Alternatively, the SUSY Les Houches Accord (SLHA) definition allows to feed information about handling of the additional particles into the multi-purpose generator (supported by e.g. Pythia 6).

LHEInterface provides a general approach to the handling of LHE files which allows to use arbitrary combinations of ME and multi-purpose generators. Most ME generators nowadays speak the LHE dialect, meaning that their output can done as a standardized text file. This LHE text files contains some arbitrary headers and comments to conduct the matching correctly), information about the run (processes, cross-sections, PDFs, beam type, beam energy) and a per-event parton listing with incoming particles, outgoing particles and optionally decays of those particles (like e.g. top quark and W boson decay including spin correlations). This standardized run and event information is closely modelled after the HEPRUP and HEPEUP Fortran Common Blocks found in Pythia6 and Herwig6. All multi-purpose generators typically have a way to either read an LHE file directly and/or to feed information at runtime through definitions following the Common Block standard.

The LHEInterface focusses on integrating the LHE file standard in a general way into CMSSW. It provides persistency of LHE run and event information inside the EDM format (basically an EDM product or ROOT branch represenatition of the exact LHE file contents). There is the class definition of the LHE file contents for EDM persistency. The according ROOT Reflex DataFormats are defined in the SimDataFormats/GeneratorProducts package. As a user you shouldn't need to care about that. This information is used in the CMSSW interfaces of the type HadronizerFilter to the general purpose generators that perform hadronization and the parton matching.

General LHEInterface layout

The main module of the LHE interface is LHESource. It is an EDM source and behaves similarly as PoolSource in that it provides a stream of events to the EDM main loop. In contrast to other generators it does, however, not provide an edm::HepMCProduct but rather an LHEEventProduct per event and a LHERunInfoProduct for the run. The result can be stored in a ROOT file using the PoolOutputModule and read back in a later step before passing it on to a shower generator (or analyzed directly).

The package also contains a few additional modules:

  • The LHEWriter module can be put in an outpath and writes out the LHE branches to a standalone LHE text file. Except for whitespace and number formatting differences, the output should be identical to the LHE file before reading it into EDM. Combining an LHESource and an LHEWriter, CMSSW is able to merge different LHE files (only containing the same process).

Running the examples

Check out the examples in the test directory: addpkg GeneratorInterface/LHEInterface

(or if you want to use Herwig++ as shower generator: addpkg ThePEGInterface)

Note that at the moment, you will find both old-style CMSSW config files as well as the new Python config files in the test directories (*.cfg and *_cfg.py respectively), the former will go away at some point.

Here a small description of what each file does, and a more detailed look later:

config file description modules used
testReader_cfg.py reads an LHE files and stores LHE information in an EDM file LHESource
testWriter_cfg.py reads an EDM file and stores the LHE product contents back into an LHE text file LHEWriter

Most of the config files contain additional modules like printTree and printList which are used for debugging the HepMC output and not activated by default. They can be removed if the config files are used as template. In case an external config file containing default settings (like PDFs, underlying event, ...) one has to make sure that the correct config file corresponding to the generator is used. For documentation of the generator specifig settings, you should consult the manual and/or Wiki page of the corresponding standalone generator source.

All config files read the Les Houches Events file ttbar.lhe. The EDM output file containing HepMC output is called test.root, if it contains only LHE output (like from testReader.cfg), the output file is named lhe.root. The simulation and reconstruction test files produce raw.root and reco.root respectively. Converting lhe.root back to an LHE text file using testWriter.cfg produces the file writer.lhe.

Module documentation

In the following all provided CMSSW modules and LHE interface plugins are described. Each module is introduced and followed by an example configuration snipped with documentation of the parameters in it. Parameters that are commented out are optional.

LHESource

This module is an EDSource and inherits from GeneratedInputSource, and therefore all the well-known source options here can be specified as well. Expected input files are LHE-formatted text files, which need to strictly conforming to the XML standard, as a real XML parser is employed for reading the files. (Crude XML violations have been seen mostly in the headers and comments, which can be easily fixed, if you encounter such a file don't hesitate to contact the developers of the MC generator about it.) The file names have to be specified in for of CMSSW URLs, meaning that plane files have to carry the file: prefix, otherwise the local file catalog will be consoluted. All CMSSW protocols like rfio:, dcap:, root:, and so on are supported. If you need access to single files which are stored in the MCDB (or now EOS) from outside, you can use the xrootd protocol ("root:"). As an example, the filename should look like root://eoscms.cern.ch//eos/cms/store/lhe/6719/WZJetsTo3LNu_8TeV-madgraph_166134011.lhe, while you can get the list of files stored in EOS as in the following

[local] ssh lxplus.cern.ch
[lxplus] eoscms ls /store/lhe/6719
...
WZJetsTo3LNu_8TeV-madgraph_166134011.lhe
...

#test if you can access the file:
[local] xrdcp -d 1 -f root://eoscms.cern.ch//eos/cms/store/lhe/6719/WZJetsTo3LNu_8TeV-madgraph_166134011.lhe  /dev/null

It is currently not recommended to use more than one input file at a time, because it has not been extensively tested.

This source produces two collections: LHERunInfoProduct in the Run collection, containing the LHE headers and comments, beam type, energy, PDF set, processes and cross-section information. In the Events collection the LHEEventProduct is stored, containing the parton-level event listing, Q scale and alphas to be used and optionally PDF information.

If the output is written to an EDM file, one has to take care to explicitly add keep statements to the PoolOutputModule, since currently none of the products in listed in any EventContent definitions. The example config files show how to do this.

Example:

process.source = cms.Source("LHESource",
    fileNames = cms.untracked.vstring("file:ttbar.lhe"),

    # and the usual optional stuff (refer to documentation/code of InputSources for more)

    # skipEvents        = cms.untracked.uint32(0),      # events to skip
    # firstEvent        = cms.untracked.uint32(1),      # event number to assign to first event 
    # firstRun          = cms.untracked.uint32(1),      # first run number
    # numberEventsInRun = cms.untracked.uint32(100000)  # number of events after which run number is incremented
)

LHEWriter

This module is an EDAnalyzer which can be set into any path and simply creates an LHE text file called writer.lhe containing the LHE information stored in the EDM file. Please keep in mind that if the file has already undergone a ME/PS matching procedure all the unmatched events will usually already been thrown away and will not be reproduced by this writer.

module writer = LHEWriter {}

LHEProducer

Warning: LHEProducer is depcreated in 3_1_X. Use the "HadronizerFilter" concept instead.

This EDFilter does the main interaction with the shower generators to fully evolve parton-level events as specified in the LHE input. The output of this producer is the HepMC event as used as input for the simulation or generator info products. It has to be combined with e.g. an LHESource to read an LHE file, or can run on a ROOT file which already contains LHE information. If the same settings and random numbers are used, it should be able to exactly reproduce the events. If jet matching is used, this module will at the same time act as a filter, telling EDM to drop events where the ME/PS matching failed. This means that this producer has to be specified as the first element in all the paths and that one of the paths should be specified in the PoolOutputModule so that it knows which events not to save. Please see the testPythia6.cfg or testStep2_GenSimDigiL1Raw.cfg example. This works in the same way as the AlpgenEmptyEventFilter. Also note that the LHEProducer is, as the name indicates, a producer. As a consequence the edm::HepMCProduct will not be available under the label "source" but under whatever the module is named in the config file. The name "generator" is used throughout the examples here. This means that for the full Generator.cff sequence and the simulation and so to find the event, a few replace statements have to be used to change the InputTag of those modules. An example can also be found in the config files listed above.

The LHEProducer produces an edm::GenInfoProduct in the Run information containing computed cross-sections (and also a copy of the external filter efficiency and external cross-section provided in the config file). Each event contains an edm::HepMCProduct. In case matching was used, two additional per-event products matchDeltaR and matchDetaPRel will be produced, containing a std::vector with the per-jet matching information useful for debugging. Note that unless explicitly specified to be kept, these products will not be written to the output EDM file when the default EventContent definitions are used. This is currently an issue anyway, since only the "source" labels are kept by default and an eye should be kept on the contents of the ROOT file.

The interface tries to do its best to fill as much information as possible into the products. Information is collected from the LHE file and generator e.g. to fill the PDF and cross-section information, the scales and alphas used.

The most important part of the LHEProducer is the configuration of the shower generator to be used. This is called "hadronisation" in the context of the producer, but it actually refers to all the secondary steps provided by the generator (Parton Shower, Hadronisation, Decays, Radiation, Underlying Event, ...). The hadronisation ParameterSet is mandatory. This PSet has to contain a string option specifying the generator to use. Internally the string "Hadonisation" will be appended to that name and a EDM plugin of that name searched. Currently available are Pythia6, Herwig6, Pythia8 and ThePEG (for Herwig++). All other parameters in the hadronisation PSet are specific to the generator used and closely follow the configuration settings of the sources if the generators are used standalone (please have a look at the SWGuide pages of those generators, you can find the links in the introduction). What all modules have in common is that they usually contain a vstring parameterSets where a list of ParameterSets can be given containing configuration lines. Default configuration lines can then be included from an external file (like Pythia UE settings). Please the the examples and standalone generator source for more details. Also note that you should not randomly choose settings, they should match the ME generation process in the LHE file, if applicable. For instance, Pythia6 does not take the alphas and scale from the LHE information, but computes it from the parton level event listing. It has a bunch of settings to select the strategy for obtaining the Q scale, also the correct PDF set should be chosen.

A word of warning: Please check that the generator you intend to use correctly supports the process you are feedint it. The ParticleTreeDrawer that can list you the HepMC event tree is very useful for that purpose, also the eventsToPrint parameter directly in the producer. For instance, Herwig6 has issues with vector boson fusion events (kept adding the scattered forward jets twice), and others have not correctly propagated lifetime information in exotics events. Sometimes you also need to make the generator aware of the particle IDs used in the LHE input (which is a generator-specific issue). Most of the times, Pythia6 seemed to be the most universal generator, but also often just evolves physics-wise nonsensical events without warnings. Also have a look at the colour flow before and after the Parton Shower.

The jetMatching ParameterSet is optional and its use currently discouraged. Details can be found furhter below nonetheless.

Example:

include "Configuration/Generator/data/PythiaUESettings.cfi"

module generator = LHEProducer {
        # untracked uint32 eventsToPrint = 1    # print HepMC debug

        PSet hadronisation = {
                string generator = "Pythia6"
                # string generator = "Herwig6"
                # string generator = "Pythia8"
                # string generator = "ThePEG"

                # untracked int32 pythiaPylistVerbosity = 2
                # untracked int32 maxEventsToPrint = 1

                vstring parameterSets = {
                        "pythiaUESettings",
                        "myPythiaSettings"
                }

                vstring myPythiaSettings = {
                       # individual Pythia settings
                }
        }

        # optional:
        # untracked PSet jetMatching = {
        #         # select the jet matching implementation
        #         scheme = cms.string("Madgraph"),
        #   (or) scheme = cms.string("MLM"),
        #         # ... jet matching settings
        # } 
}

ME/PS jet matching

The optional jet matching is implemented as plugins, so that one can choose between the implementations. Currently supported are legacy MadGraph matching (the Fortran implementation from the MG/ME authors) that currently works only on MadGraph LHE files together with Pythia6 showering, or an experimental from-scratch C++ generator-independent reimplementation of the original Alpgen MLM matching scheme (intended to combine Alpgen ME input with arbitrary showering generators). Only the MadGraph scheme is currently officially supported.

MadGraph ME/PS jet matching

3_1_X warning: This code has not been ported to the new "HadronizerFilter" concept. The MadGraph and Alpgen code is available with the "HadronizerFilter" concept for Pythia6.

This matching module is activated by putting scheme = cms.string("Madgraph") into the jetMatching PSet inside the LHEProducer configuration. This produces the physically same output as the old MadgraphSource and is the one validated from the MG/ME authors. It therefore only runs on LHE files produced by MadGraph/MadEvent in combination with Pythia6 showering. In analogy to MadgraphSource it takes the following parameters:

        jetMatching = cms.untracked.PSet(
                scheme = cms.string("Madgraph"),

                mode = cms.string("auto"),
                etaclmax = cms.double(5.0),
                qcut = cms.double(30.0),
                minjets = cms.int32(0),
                maxjets = cms.int32(3)
        )

Where mode can be either "exclusive", "inclusive" or "auto". The first two options are to be used on non-soup LHE files, where the highest jet-multiplicity bin is done in "inclusive" matching, and the other ones with "exclusive" matching. Four soup LHE files, containing a mix of additional light jet multiplicities, the matching is determined on a per-event basis and the minjets and maxjets parameters have to be set accordingly. The maxjets parameter takes the number of light jets in the highest-multiplicity graphs. The etaclmax should probably stay at 5.0 (to be consistent with generation, the maximum pseudorapidity for jet clustering), and for qcut one should refer to the MadGraph/MadEvent documentation for the best matching scale. A good value is usually 50% above the xqcut used for generation, but the value should better be officially validated and not be set blindly.

MLM-style ME/PS jet matching

3_1_X note: This code has been ported to the "HadronizerFilter" concept when used with Pythia6.

Note: This code is currently being tested and validated. Using it is therefore strongly discouraged. It is only to be used for generators that can produce ME files suitable for MLM matching, like ALPGEN or HELAC. For the first, AlpgenInterface should be preferred. Seems to work well though with Pythia6 and Herwig6, but serious issues are currently known with other generators. The code is currently not compatible with the MadGraph modified MLM scheme. Also, Herwig++ in principle provides the alternative CKKW matching, which is also not interfaced yet.

In contrast to dedicated interfaces like AlpgenInterface or MadGraphInterface where the matching almost works automagically (because important information is extracted from the headers), the matching in the LHEInterface has to be set up manually for the process. This requires intimate knowledge of the procedure. The LHEAnalyzer can be used to test the matching transition region.

In order to proceed with the matching procedure, first the partons and jets that are to be matched, have to be precisely defined. The LHEInterface can in principle identify all partons after the Parton Shower, but before the hadronisation (including ISR and FSR from the hard process, but excluding UE/MPI) from the final HepMC event, but tries to exploit a matching callback from the generator if available, that provides the naked event with only the parton shower applied. The minor discrepancies (which mostly arises from a slight boost of the hard process vertex from added kinematics) between both approaches are in the sub-percent region, which can be observed using the LHEAnalyzer.

Also, matching has often only to be applied to the additional light jets in the event and not to the "primary" (the one in the lowest multiplicity bin) particles. Usually, heavy flavour jets or W/Z decay products are therefore excluded from the matching. It heavily depends on the ME generator and its settings used. I here refer to the documentation and existing jet matching code. These radiation vetoes can be configured manually in the jetMatching configuration PSet.

Then, the jet clustering algorithm, separation settings (delta R in case of MLM) and phase space cuts (min Et and max |eta|) have to configured. These settings have to match the ME generation. Usually all necessary information is provided in the headers. It is often necessary to slightly increase the cuts to avoid edge effects. There is no general recipe here, mostly results from optimisation and experience. Again, please refer to well-tested settings or contact experts (or don't try to set it up by hand). And finally the settings for the matching, i.e. maximum distance, exclusive or inclustive (highest multiplicity sample) matching have to be given. AlpgenInterface derives those from the clustering settings (same Pt cut, maxDeltaR = jetConeDeltaR * 1.5) which is reasonable, but sample-dependent validation should be done nonetheless.

The LHEAnalyzer uses almost the same settings as the jetMatching PSet and will produce plots for the differential jet rates (maximum number to be specified in the config). A TFileService needs to configured to set up the storage of the ROOT files with the plots. The resulting histograms then need to be overlaid and scaled with the respective sample cross-sections and summed up.

Using LHEInterface with cmsDriver.py

In the cmsDriver python generator frament, one needs:

  • the LHESource (cmsDriver only supports PoolSource natively so far, so this or MCDBSource has to be put it in by hand)
  • the LHEProducer
  • a "ProducerSourceSequence"
like in the example below. The snippet needs to be in some python subdirectory (like for instance GenProduction/python or any other package)

Then one can run cmsDriver.py with (for instance running simulation and HLT, creating RAW output):

cmsDriver.py \
        Configuration/CMS.GenProduction/test.py
        -s GEN:ProducerSourceSequence,SIM,DIGI,L1,DIGI2RAW,HLT \
        --eventcontent RAWSIM \
        --datatier GEN-SIM-RAW \
        --conditions FrontierConditions_CMS.GlobalTag,IDEAL_30X::All \
        -n 100 \
        --customise=Configuration/CMS.GenProduction/generatorProducer.py \
        --no_exec

For the conditions and other parameters, please refer to the official cmsDriver documentation.

The first parameter refers to the generator fragment (without the /python/ in it). So the differences with respect to e.g. Pythia are the fact that one has to put the LHESource inside the snippet, add :ProducerSourceSequence after GEN on the command line, as well as the --customise parameter. For the RECO step after that, this one works as usual.

Note: If you are planning on using this with FASTSIM, check out the HEAD of GenProduction for now ( cvs co GenProduction in src/) to get an up-to-date generatorProducer.py. Do not forget run scram b python after checking out new python config files.

Example snippet:

import FWCore.ParameterSet.Config as cms

source = cms.Source("LHESource",
    fileNames = cms.untracked.vstring("rfio:///castor/cern.ch/sft/mcdb/storage/187/events_12k_10TeV_STsch.lhe")
)    

from Configuration.GenProduction.PythiaUESettings_cfi import *

generator = cms.EDProducer("LHEProducer",
        hadronisation = cms.PSet(
                pythiaUESettingsBlock,
                generator = cms.string('Pythia6'),
                parameterSets = cms.vstring(
                        'pythiaUESettings',
                        'pythiaCMSDefaults'
                ),
                pythiaCMSDefaults = cms.vstring(
                        'PMAS(5,1)=4.4    ! b quarks mass', 
                        'PMAS(6,1)=172.4  ! t quarks mass', 
                        'MSTJ(1)=1        !...Fragmentation/hadronization on or off', 
                        'MSTP(61)=1       ! Parton showering on or off', 
                        'MSEL=0           ! User defined processes/Full user control'
                )
        )
)

ProducerSourceSequence = cms.Sequence(generator)

More details about creating config files for simulation can be found in the description of generating the config files using cmsDriver for the Summer2008 / Winter 2009 production.

Source code structure

The GeneratorInterface/LHEInterface package is split into a src part containing a reusable library and a plugins part (two subdirectories) containing the EDM plugins mentioned so far. The public headers for users that want to make use of the services provided in the LHE interface library can be found in interface. In order to use this library, a in the CMS.BuildFile should do the trick.

If a generator wants to implement a "Hadronisation" plugin to be used with the LHEProducer, it has to define a new EDM plugin that derives from lhef::Hadronisation (header file GeneratorInterface/LHEInterface/interface/Hadronisation.h). For example the CMS.ThePEGInterface provides a ThePEGHadronisation plugin this way. It is then registered with the CMSSW plugin manager using the line DEFINE_LHE_HADRONISATION_PLUGIN(XXXHadronisation); in the source file and in the CMS.BuildFile. For virtual methods to be implemented please consult the header file and existing examples for the moment.

Other facilities provided by the library are:

  • LHEEvent.h - container for LHE event information (used for instance in the Hadronisation plugins)
  • LHERunInfo.h - container for LHE run information (also collects event statistics), read/write access to an XML DOM (Xerces-C) representation of the LHE
    ...
    block is available too.
  • LHEReader.h - skeleton for implementing an LHE text stream into C++ parser
  • LHEProxy.h - tool to provide access to the current event object in case pointers cannot be passed down to the generator
  • JetClustering.h - interface to the jet algorithms used by the matching
  • JetInput.h - jet input particle selector (including subtree veto, PS parton detection, etc...)
  • CMS.JetMatching.h - the core MLM matching algorithm

the LHE Data Formats

The definition of the persistent LHE data formats can be found in the package SimDataFormats/GeneratorProducts. There are the following parts to it:

  • the core definition of the LHE data corresponding to the original Fortran Common Blocks (in interface/LesHouches.h) The two classes lhef::HEPRUP and lhef::HEPEUP= for run and event information are defined here.
  • a class with static helper methods to facilitate transfer of the above two C++ classes from/to the Fortran Common Blocks, to be used with Fortran generators like Pythia6 and Herwig6 (in interface/LHECommonBlocks.h)
  • the EDM product container for run information (in interface/LHERunInfoProduct.h) Additionally stores all LHE headers and comments.
  • the EDM product container for event information (in interface/LHEEventProduct.h) Can additionaly contain per-event comments and PDF information.
The latter two classes are available for persistent storage. Additional convenience iterators are available in both of them:

  • in LHERunInfoProduct.h:
    • The LHERunInfoProduct::comments_const_iterator can be iterated from LHERunInfoProduct::comments_begin() to LHERunInfoProduct::comments_end() and when dereferenced returns all additional comment lines as STL strings found at the end of the <init>...</init> block.
    • The LHERunInfoProduct::headers_const_iterator returns all header XML objects found in the header of the LHE file before the <init> block. This can be <!-- ... --> comments or XML elements (like the <header>...</header> block). The iterator will return instances of the LHERunInfoProduct::Header class, which in turn has a const_iterator and begin() and end() method to iterate over the individual lines, returned as STL strings. The method tag() returns the qualified name of the XML tag, and en empty string represents an XML comment block.
    • The LHERunInfoProduct::const_iterator returns the complete LHE header, starting with <LesHouchesEvents> as individual lines. The methods LHERunInfoProduct::begin(), LHERunInfoProduct::init() and LHERunInfoProduct::end() return iterators that point to the beginning of the file, the <init> block and to the end of the header (i.e. first <event> block). If just the additional header information, e.g. for MadGraph-specific information is needed, it is sufficient to iterate from begin() to init() or to use the headers iterator above and look explicitly for the <header> block contents. The part between init() and end() is only useful if the LHE information is needed to be converted back to text format, because otherwise a C++ representation of the contents is available in the HEPRUP class via the LHERunInfoProduct::heprup() method, which can be filled directly into the Fortran Common Blocks using the LHECommonBlocks helper class.

  • in LHEEventProduct.h:
    • The LHEEventProduct::comments_const_iterator, iterable between LHEEventProduct::comments_begin() and LHEEventProduct::comments_end() returns all additional comments found at the end of the <event>...</event> block as STL strings.
    • The LHEEventProduct::const_iterator, iterable between LHEEventProduct::begin() and LHEEventProduct::end() returns the whole <event>...</event> block in text format as individual lines in STL strings. This is only of interested, if the text format representation of the LHE contents is needed, otherwise the LHEEventProduct::hepeup() method will return a reference to the C++ representation of the LHE event contents, which can be passed on to the respective Fortran Common Block using the LHECommonBlocks helper class if necessary.
Both classes also contain all necessary constructors and methods to fill these classes from scratch (see for example the LHESource code for reference, which uses the LHEReader class to obtain the information from an LHE text file).

Links

Contacts

Review status

ChristopheSaout - 10 June 2008 first draft
ChristopheSaout - 5 Februrary 2009 state of the art in CMSSW_2_2_X

Responsible: ChristopheSaout

Edit | Attach | Watch | Print version | History: r23 < r22 < r21 < r20 < r19 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r23 - 2018-06-06 - LaurentForthomme
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback