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 discussions 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> tags (not enclosed in an <LesHouchesEvents> tag). 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. For the <eventfile> tag the following attributes 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).

Question: Should not we allow events to be provide as .tar.gz and in that case have a conventional name (like banner.lhe) for the banner file?

As noted above some ME generator needs to report the number of attempts needed to generate the <event>s in the LHE file, to get the proper statistics. In addition the for LHE files with weight variations, the cross section information may be needed for each weight variation. To handle the we propose additional attributes for the <xsecinfo> tag and that several <xsecinfo> tags may be given in the <init> block. The previously defined attributes were

• neve (mandatory) is the number of events in the file.
• totxsec (mandatory) the total cross section of all the processes in the file.
• maxweight the largest of the weights of the events in the file.
• meanweight the average of the weights of the events in the file.
• negweights is set true if the file contains negative weights.
• varweights is set true if the file contains variable weights.

It is now suggested to add the following attributes

• ntries is the number of attempts made before accepting the neve events in the file.
• xsecerr is the estimated statistical uncertainty on totxsec.
• weightname the name of the weight variation to which this <xsecinfo> tag corresponds. If not given, the default XWGTUP weight is implied.

It was agreed that the changes proposed are significant enough to bump the version number of LHE to 4.0. It was also agreed that the LHE accord must be better documented and that there should be one well-defined place to find this documentation.

Since version 3 of the HepMC event record now comes with sample LHEF code and the option of including LHE information in the HepMC files, it is natural to keep this code up-to-date, and that documentation also is distributed with HepMC3. HepMC3 can be obtained from https://hepmc.web.cern.ch/hepmc/. The modifications suggested here has been implemented in the sample LHEF code available from https://gitlab.cern.ch/hepmc/HepMC3 in the LH17 branch of the HepMC repository.