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 allowed values are currently “veto” for a veto scale for a parton shower emission, and “start” for the starting scale of the parton shower.
• p specifies for which particle the scale applies, given by an integer where “1” is the first particle in the HEPEUP block. If two integers are given it should be interpreted as the emission from the first in a “dipole” connecting to the second. 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 the end of the file, since when starting writing the 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. To accommodate for this, there was two solutions.

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.

Both these changes can be introduced simultaneously.