LHEF for Matching

From Wiki Les Houches 09

Revision as of 14:39, 16 June 2009 by Lonnblad (Talk | contribs)
Jump to: navigation, search



The Les Houches Event File accord (LHEF) was introduced in 2006 and was meant as a standard way of representing in an ASCII file the information in the old Les Houches common block accord from 2001. LHEF was constructed using XML tags to be easy to extend (although some additional structure is assumed inside some tags which is not formulated in XML). The standard has been extremely usefull, and has been used a lot to interface matrix element generators and parton shower programs.

The standards are found here:

As the matching and merging of tree-level matrix elements and parton showers are now becoming the state-of-art, it is reasonable to let this be reflected in an updated file format to standardise how relevant information should be given by the matrix element generators (MEGs) in a usable fashion for the parton shower programs (PSGs). Furthermore, looking ahead towards the time when NLO matching and merging with parton showers hopefully will become the standard, it might be worth thinking about which additional information is needed for the parton showers in this case.

Below you will find a rough draft of additional XML tags suggested to be included in the new standard (version 2.0).

Note that the notation is that a tag may contain attributes in the following way:

 <tag attribute1="value" attribute2="value">things marked by the tag</tag>


 <tag attribute1="value" attribute2="value" attribute3="value" />

A number of example C++ classes for reading and writing Les Houches files according to the suggested standard can be found here.

Run information

This is information about all events in the file to be included inside the "init" tag after the compulsary block of parameters corresponding to the HEPRUP common block.

The xsecinfo tag (required)

The information in the HEPRUP common block is in principle sufficient to figure out the cross sections of the processes involved. However, the way things are specified is a bit confusing and complicated since it was assumed to be used to pass information between the MEG and PSG in both directions. For the event file, the communication is per definition one-way, and the information can be made more easily provided. The suggested attributes for the xsecinfo tag are as follows (R means the attribute is required. D= means a default is assumed if the attribute is absent).

  • neve (R): the number of events in the file
  • totxsec (R): the total cross section (in units of pb) of all processes in the file
  • maxweight (D=1): the maximum weight of any event in the file (in an arbitrary unit)
  • minweight: if the file contains negative weights, the minweight may contain the most negative of the negative weights in the file. If not given, minweight is assumed to be -maxweight.
  • meanweight (D=1): The average weight of the events in the file (same unit as maxweight).
  • negweights (D=no): If yes, the file may contain events with negative weights.
  • varweights (D=no): If yes, the file may contain varying weights (if no, all events are weighted with maxweight (or minweight)).

The information given per process in the HEPRUP common block can then safely be ignored and the cross section for each process is assumed to be the sum of all weights of the corresponding events multiplied by totxsec/maxweight/neve.

The cutsinfo tag (optional)

Here the MEG should supply information about the cuts used in the generation. Inside this tag any number of cut and ptype tags can be supplied.

The ptype

This tag can be used to define a group of particles to which a cut can be applied. Its contents should be a white-space separated list of PDG particle codes. The only attribute is

  • name (R): The string used to represent this ptype in a cut.

The cut tag

This tag has information of a particular cut used. The information needed is which particle(s) are affected, what variable is used and the maximum and/or minimum value of that parameter. The contents should be the minimum and maximum allowed values of this variable (in that order). If only one number is given, there is no maximum. If the minumum is larger or equal to the maximum, there is no minimum. The attributes are

  • p1 (D=0): The particles for which this cut applies. This can either be a number corresponding to a given particle PDG code or 0 for any particle or the name of a previously defined ptype tag
  • p2 (D=0): If cut is between pairs of particles, this attribute should be non-zero. Allowed values are the same as for p1
  • type (R): This defines the variable which is cut. The following values are allowed (the lab frame is assumed in all cases):
    • "m" the invariant mass of two particles (or, if only one particle type is given, the invariant mass of that particle).
    • "kt": the transverse momenta of a particle matching p1 (in GeV)
    • "eta": the pseudorapidity of a particle matching p1
    • "y": the true rapidity of a particle matching p1
    • "deltaR": the pseudorapidity--azimuthal-angle difference between two particles matching p1 and p2 respectively.
    • "E": the energy of a particle matching p1
    • "ETmiss": the norm of the vectorial sum of the pt of particles matching p1 and not matching p2.
    • "HT": the scalar sum of the transverse momentum of the particles matching p1 and not matching p2.
    • ...

The procinfo tag (optional)

For each process number used in the NPRUP variable in the HEPEUP common block we can have additional information given in the following attributes:

  • iproc (D=0): The process number for which the information is given. 0 means all processes.
  • loops: The number of loops used in calculating this process.
  • qcdorder: The number of QCD vertices used in calculating this process.
  • eworder: The number of electro-weak vertices used in calculating this process.
  • rscheme: The renormalization scheme used, if applicable.
  • fscheme: The factorization scheme used, if applicable.
  • scheme: Information about the scheme used to calculate the matrix elements. If absent, a pure tree-level calculation is assumed. Other possible values could be CSdipole (NLO calculation with Catani-Seymour subtraction), MC@NLO, POWHEG and NLOexclusive (NLO calculation according to the exclusive cross section withing the given cuts).

The content of this tag is a string with arbitrary information about the process.

The mergetype tag (optional)

For some merging schemes (eg. for CKKW) it is possible to reweight the the events with Sudakov form factors already in the MEG. If this has been done the content of the mergetype tag for the corresponding process should give a name corresponding to the scheme used. The attributes are

  • iproc (D=0): The process number for which the information is given. "0" means all processes.
  • mergingscale (R): The value of the merging scale in GeV.
  • maxmult (D=no): If yes the corresponding process is reweighted as if it is the maximum multiplicity process (ie. the Sudakov for the last step down to the merging scale is not included.

Event information

This is information about a particular event to be included inside the event tag after the compulsory block of parameters corresponding to the HEPEUP common block.

The weight tag (optional)

An event can be associated with a number of different weights given in weight tags. The content of these tags are simply a sequence of weights corresponding to different PDFs, αS values, etc. The first weight in the first of these tags should correspond to the main weight as described in the xsecinfo tag. All weights should be given in the same unit as the maxweight attribute in the xsecinfo tag. For each weight tag, further information can be given in the following attributes

  • name: an arbitrary string describing this set of weights
  • born: the relative size of the tree-level cross section for this event if applicable. Summing born times the weight and multiplying with totxsec/neve/maxweight will give the Born cross section for this process.
  • sudakov (D=0): The sudakov form factor used to weight this event (see the reweightscheme attribute of the mergeinfo tag).

The relationships between these terms is typically born*sudakov=1.

The clustering tag

If an event has eg. been reweighted with Sudakov form factors, it is possible to specify how the current event has been clustered to find the scales involved. The contents of this this tag should be a series of clus tags. The clustering should be defined from the final state backwards in terms inverse time-like splittings, in the end defining a "bare" ladder diagram. This is then followed by a sequence of space-like splittings.

The clus tag

The contents of this tag is two or three integers. The two first indicates which particles entries are clustered. If a third number is given it should correspond to an actual entry which corresponds to the combined object (if eg. a decayed resonance is explicitly present in the HEPEUP common block). If no third number is given, the clustered object is in the following referred to with the first number. The attributes are

  • scale: The scale in GeV associated with the clustering if relevant.
  • alphas: If the event has been reweighted with an αS at the scale in this clustering, the value of this αS should be supplied here.

The pdfinfo tag (optional)

Here the MEG can supply information about the PDFs used for this event. The following attributes are available

  • p1: the type of the incoming particle 1.
  • p2: the type of the incoming particle 2.
  • x1: the x-value used for the incoming particle 1.
  • x2: the x-value used for the incoming particle 2.
  • scale (D=SCALUP): The scale in GeV used in the PDFs (default is the SCALUP variable in the HEPEUP common block).

The content of the tag is two real numbers corresponding to the values of the PDFs, xfp1(x1,scale) and xfp2(x2,scale).

Grouping of events

If we have a NLO calculation using eg. Catani-Seymour subtaction of a process with N particles in the Born level, each N+1 tree-level event will come with a number of counter events with N particles. For this reason there is a need to group events together. Such a group of events should be included in an eventgroup tag.

The eventgroup tag

The contents of this tag is a number of event tags which for some reason should be considered together. The main purpose is to allow an event generated according to the real contribution in an NLO generator, to be accompanied with a number of counter events corresponding to the subtraction terms. The following attributes are possible

  • nreal: the number of real events (ie. N+1 events, which should typically be 0 or 1).
  • ncounter: the number of counter events.

Note that if event groups are present, the neve attribute in the xsecinfo tag should count an event group as a single event, also it is the sum of the weights of the events in an event group which relates to the maxweight and meanweight attrributes in the xsecinfo tag. To be backward compatible with the previous standard, where the <event> and </event> tags are required to be alone on a single line, also the <eventgroup> and </eventgroup> tags are required to be alone on a single line.

--Lonnblad 13:46, 10 June 2009 (UTC)

Personal tools