Les Houches

The latest version of the Les Houches file format was developed at Les Houches in 2013. Since then the format has been heavily used, and some deficiencies has been spotted. Here are the ones we have discussed.

It has been claimed that the shower starting/veto scales need to be more flexible. Something like that is already included in the Pythia8 which interprets eg. an attribute pt_start_3=“42” in a <scales> tag as the starting scale of particle 3. These attributes are in addition to the mups defined in the current version together with mur and muf.

After the discussions on Saturday it was agreed that much of the complications of scale settings for individual particles must in any case be handled through specialized hooks into the parton shower, the interface of which is determined by the individual parton shower, with different implementations done by the respective matrix element providers. For this to work smoothly there is nevertheless a need to formalise the information that goes into the event file.

The suggestion is to allow subtags named <scale> with the content specifying a special scale in GeV. This tag can have a number of attributes:

• stype (mandatory) specifies the type of scale intended. The onle pr-defined value is “veto” for a veto scale for a parton shower emission. The variable in which this scale is defined depends on the ME generator that produced the event file. A PS generator reading the file must work out from the <generator> tag exactly in which kinematical variable to veto. In addition stype may correspond to a starting scale of the evolution for the PS, which again is different for different programs. It is up to the authors of the individual PS programs to specify the name to be used. One could e.g. imagine that Pythia8 decides to recognise stype=“pystart”.
• pos specifies for which particle the scale applies, given by an integer where “1” is the first particle in the HEPEUP block. If more than one integer is given, it should be interpreted as specifying the emission from the first in a “dipole” connecting to any of the subsequent. If not specified this scale applies to all particles that do not have a specific <scale> tag.
• etype specifies the emission type for which the scale should be applied. This should be a list of integers corresponding to the PDG code of the emitted particle. Short-hands allowed are “QCD” corresponding to any quark or a gluon, and “EW” corresponding to any lepton or electro-weak gauge boson. If not supplied, the scale applies to any emission.

For any emission not matching a <scale> tag, the mups still applies, although whether this should be interpreted as a starting scale or a veto scale is not defined.

The current way of specifying the cross section is not sufficient for some matrix element generators. Requests has been made to be able to report the number of tried events in addition to the ones accepted and actually present in the file. Further more, for practical reasons, there was a request to have the possibility to report the cross section in a separate file, since when starting writing a file, the cross section is not always fully known (this is the case in HepMC where the current best estimate of the cross section is reported for each event. In addition, it is in some cases desirable to divide up a huge LHE file into several smaller ones containing equivalent events. It was therefore decided to allow to split up LHE files into one file containing the <init> with all information run information, and a list of files containing only <event>s. For this we introduced a new <eventfiles> tag which may contain an arbitrary number of <eventfile> tags. The <eventfiles> tag does not have attributes and must be in the <init> block. The <eventfile> the following may be specified.

• name (mandatory) is the name of the file containing <event>s. This would preferably be a relative filename with respect to the directory where the file containing the <init> block resides.
• nevent is the number of <event>s in the file.
• ntries is the number of attempts the ME generator needed to produce the events in the file. (see below).

The first is an ammendment to the <event> tag where an attribute ntries can be given to indicate the number of tries the matrix element generator used before producing the event. If absent, ntries=“1” is assumed.

The other suggestion is to allow for supplying <xsecinfo> tags inside an <event> block to indicate that the original <xsecinfo> (given in the <init> block) is updated. In addition the <xsecinfo> is given an new optional attribute ntries given the number of attempts used to produce the number of events indicated in the neve attribute.