User Tools

Site Tools


2017:groups:tools:lhe

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
2017:groups:tools:lhe [2017/06/10 14:54]
leif.lnnblad
2017:groups:tools:lhe [2017/06/21 22:49] (current)
leif.lnnblad
Line 1: Line 1:
 ===== LHE v3 (and MC technicalities) sub working group ===== ===== LHE v3 (and MC technicalities) sub working group =====
  
-The last version of the Les Houches file format was developed at [[https://​phystev.cnrs.fr/​wiki/​2013:​groups:​tools:​lhef3]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. +The latest ​version of the Les Houches file format was developed at [[https://​phystev.cnrs.fr/​wiki/​2013:​groups:​tools:​lhef3|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. ​
 == Scales == == Scales ==
  
 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''​. 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.+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: 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+  * ''​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"''​
-  * ''​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.+  * ''​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 givenit 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.   * ''​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. 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.
  
-== Cross section information ​==+== Splitting up the LHE file ==
  
-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 thisthere was two solutions.+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 ​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 additionit 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).
  
-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 eventIf absent, ''​ntries="​1"''​ is assumed.+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?
  
-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.+== Cross section information ==
  
-Both these changes can be introduced simultaneously.+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.
  
 +== Documentation and sample code ==
  
 +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.
  
  
  
2017/groups/tools/lhe.1497099240.txt.gz · Last modified: 2017/06/10 14:54 by leif.lnnblad