#scaleShowers scale1 scale2 can be 
attached after the event proper, where the starting shower scale can be 
defined for each scattering separately; if not present both scatterings 
evolve down from the standard scale value. The LHAup 
method bool scaleShowersIsSet() tells whether such information 
has been set for the current event and, if so, 
double scaleShowers(int i) return the two scale values for 
arguments 0 and 1. 
 
 
TimeShower:pTmaxMatch 
and 
SpaceShower:pTmaxMatch 
modes. If you want to guarantee that the input scale value 
is respected, as is often the case in matching/merging procedures, you 
should set both of these modes to 1. That only affects the hard process, 
while resonance decays are still processed using the resonance mass to 
set the upper limit. However, the optional 
Beams:strictLHEFscale = on 
setting restricts also resonance-decay emissions to be below the input 
scale value. 
 
 
As a further non-standard feature, it is also possible to read in the 
separate scale values of all final particles. Such scale values could be used 
e.g. to restrict the maximum scale for shower evolutions for each parton 
separately. This reading will only be applied if the  
Beams:setProductionScaleFromLHEF switch is true (see  
Beam Parameters for details). 
This information is returned by the method 
double LHAup::scale(int i). When no such information 
has been read from the LHEF, the scale defaults to -1. 
 
 
The LHA standard only allows for one hard subcollision in an event. 
Further multiparton interactions are supposed to be handled by the 
internal MPI machinery. As a nonstandard feature, it is possible 
to input two hard subcollisions in the same event, to match the internal 
second hard process machinery. 
In such cases two partons are extracted from each of the two incoming 
hadrons. A restriction is that, unlike the single-subprocess case, 
it is important that the partons are input in the order that PYTHIA 
later would need. That is, the two subcollisions should follow each 
other, with instate preceding outstate. Any resonance decay chain 
should be put at the end, after both interactions. As illustration, 
consider double W production. With 1 and 2 
labelling the two subcollisions, and A and B the two 
incoming hadron beams, the event record ordering should be 
in_A1 - in_B1 - W_1 - in_A2 - in_B2 - W_2 - f_1 - fbar_1 - f_2 - 
fbar_2, where f fbar is the fermion decay products of 
the respective W. A limitation is that currently only one 
input scale is used, that thereby limits all further partonic activity 
in the same way for both processes. 
 
 
process 
event record, but leaves the LHA event record itself unchanged. 
 
mode   LesHouches:idRenameBeams   
 (default = 1000022; minimum = 0)mode   LesHouches:setLifetime   
 (default = 1; minimum = 0; maximum = 2)VTIMUP 
when the Les Houches event record is stored into the PYTHIA 
process one. The reason is that some matrix-element 
generators (like POWHEG) do not set decay times, so that it is up to 
PYTHIA to make that selection. This is particularly important for 
the tau lepton. 
option  0 :  all decay times are taken from the Les Houches input. 
   
option  1 :  the decay time of tau leptons is generated 
like for internal PYTHIA taus, whereas all other decay times 
are taken from the Les Houches input. 
   
option  2 :  all decay times are generated by PYTHIA, thus 
completely disregarding the Les Houches values. This option could 
go wrong in BSM scenarios with long-lived particles, if PYTHIA 
has not been provided with the information to select those lifetimes 
correctly. 
   
   
 
mode   LesHouches:setLeptonMass   
 (default = 1; minimum = 0; maximum = 2)option  0 :  all lepton masses are taken from the Les Houches input. 
   
option  1 :  if the input lepton mass deviates by more than 10% 
from the PYTHIA (data table) mass then its mass is reset according to the 
PYTHIA value. This should catch weird masses, while allowing sensible 
variations. 
   
option  2 :  each lepton mass is reset according to the PYTHIA value. 
   
LesHouches:matchInOut = on, but not 
always perfectly. One possibility then is to change the 
tolerance to reduce such errors. 
   
 
mode   LesHouches:setQuarkMass   
 (default = 1; minimum = 0; maximum = 2)option  0 :  all quark masses are taken from the Les Houches input. 
   
option  1 :  if the input c or b mass is 
more than 50% away from the PYTHIA (data table) mass then its mass is 
reset according to the PYTHIA value. 
   
option  2 : if the input mass, for all quarks except the top, is 
more than 50% away from the PYTHIA (data table) mass then its mass is 
reset according to the PYTHIA value. 
   
LesHouches:matchInOut = true, but not always perfectly. 
One possibility then is to change the 
tolerance to such errors. 
   
 
mode   LesHouches:smearHadronMass   
 (default = 0; minimum = 0; maximum = 2)option  0 :  all hadron masses are taken unchanged from the 
Les Houches input. 
   
option  1 :  the hadrons listed in the 
LesHouches:idSmearHadrons vector below are assigned a new 
mass according to the internal PYTHIA prescription. A warning is issued 
if the original mass lies outside the mass range set in PYTHIA, and then 
nothing is done. 
   
option  2 :  as option 1, but there is no mass range check, so 
relevant hadrons will always receive a smeared mass. 
   
LesHouches:matchInOut = true, but not always perfectly. 
One possibility then is to change the 
tolerance to such errors. 
   
 
mvec   LesHouches:idSmearHadrons   
 (default = {113,213}; minimum = 0)LesHouches:smearHadronMass > 0, see above. Only 
(positive) particle codes should be given, with their antiparticles 
automatically included. It is assumed that the hadron to be smeared 
has not yet been decayed. 
   
 
parm   LesHouches:mRecalculate   
 (default = -1.)flag   LesHouches:matchInOut   
 (default = on)Beams:frameType = 4 and Beams:LHEF to be the file 
name, see Beam Parameters. Internally 
this name is then used to create an instance of the derived class 
LHAupLHEF, which can do the job of reading an LHEF. 
 
 
As some information in a Les Houches Event File init block is only known 
at the end of generation, some programs choose to output this as a 
separate file. If so, the name of this file can be specified by 
Beams:LHEFheader. 
 
 
The two key compulsory parts of an LHEF is the initialization information 
stored in an init block, enclosed by a matching <init> 
- </init> pair of lines, and the event input, with each 
event enclosed by a matching <event> - 
</event> pair of lines. In the case of the no-beams 
extension the init block may be empty, but the <init> 
and </init> lines must be included for the file parsing 
to work as expected. It is also possible to have a non-empty init block, 
with the beams assigned code 0, and optionally a number of specified 
"processes". 
 
 
The latest update of the LHEF format [But14] introduced a 
multitude of different optional features. This means that apart 
from the <init> and <event> 
tags, a plethora of new, optional information is available. 
Furthermore, the inclusion of an arbitrary number of attributes into 
the tags should be supported. The LHEF reader in Pythia adheres to 
the updated LHEF format without any restriction. The new generation 
information available through the updated LHEF format can be 
retrieved by using Pythia's Info class. For a detailed 
description, please consult the section "Les Houches Event File 3.0 
information" in Event Information. 
 
 
The LHEF reader can also read in and store header blocks. By default 
this option is switched on, but may be controlled through the 
Beams:readLHEFheaders 
flag if necessary. The information can later be read out through the 
Info class for further processing. 
Due to the non-standard nature of the information in these blocks they 
are stored whole, and PYTHIA itself makes no further attempt to process 
their meaning. 
 
 
Because Les Houches Event files tend not to adhere strictly to XML 
conventions, to consistently read in header information, certain 
choices must be made. The primary goal is to make as much information 
available as possible. First, information sitting directly in the 
<header> block is stored under the key "base". Second, the tags 
starting and ending each sub block must be on their own line. Finally, 
the contents of comment blocks, <!-- -->, are still stored. The 
header keys are formed hierarchically from the names of the header 
blocks. This behaviour is illustrated in the following example: 
 
  <header> 
    BaseA 
    <hblock1> 
      1A 
      <hblock11> 
        11A <hblock111> 
        </hblock111> 11B 
      </hblock11> 
      1B 
    </hblock1> 
    <hblock2> 
      2A 
      <!-- 2B --> 
    </hblock2> 
    BaseB 
  </header> 
 
which would lead to the following information being stored in the 
Info class: 
| Key | Value | 
|---|---|
| base | BaseA BaseB | 
| hblock1 | 1A 1B | 
| hblock1.hblock11 | 11A <hblock111> </hblock111> 11B | 
| hblock2 | 2A <!-- 2B --> | 
README file in the main directory for details 
on how to do this. 
 
 
An example how to generate events from an LHEF is found in 
main121.cc. Note the use of 
Info::atEndOfFile() to find out when the whole 
LHEF has been processed. 
 
 
To allow the sequential use of several event files, the 
Beams:newLHEFsameInit 
can be set true. Then there will be no 
initialization, except that the existing LHAupLHEF class 
instance will be deleted and replaced by one pointing to the new file. 
It is assumed (but never checked) that the initialization information is 
identical, and that the new file simply contains further events of 
exactly the same kind as the previous one. An example of this possibility, 
and the option to mix with internal processes, is found in 
main122.cc. A variant, based on input in a command file, 
is given in main123.cc. 
 
 
In C++, real numbers are printed with an 'E' to denote the exponent part, 
e.g. 1.23E+04, and are read in accordingly. Other languages may use other 
letters, e.g. Fortran allows either 'E' or 'D'. A file using 
the latter convention would not be readable by the standard routines. 
In case you have such an "incorrectly formatted" file, a conversion to 
a new corrected file could be done e.g. using sed, as a 
one-line command 
 
  sed -e 's/\([0-9]\.\{0,1\}\)[dD]\([+-]\{0,1\}[0-9]\)/\1E\2/g' old.lhe > new.lhe 
 
This replaces a 'd' or 'D' with an 'E' only when it occurs in the combination 
<header>...</header> block. For conversion only 
inside the <init>...</init> and 
<event>...</event> blocks, create a file 
convert.sed containing 
 
  /<init>/,/<\/init>/bconv 
  /<event>/,/<\/event>/bconv 
  b 
  :conv 
  s/\([0-9]\.\{0,1\}\)[dD]\([+-]\{0,1\}[0-9]\)/\1E\2/g 
 
and run it with 
sed -f convert.sed old.lhe > new.lhe
LHAup derived class can set 
this header information, which can then be read out later. Although the 
naming convention is arbitrary, in practice, it is dictated by the 
XML-like format of LHE files. 
 
 string Info::header(string key)   key 
   
 
 vector <string> Info::headerKeys()   key with the contents of val 
   
 
 
process data member of the Pythia instance. It can 
for example be printed to the terminal by calling 
pythia.process.list(). 
 
All other information (e.g. stored in headers, the LHEF init block, 
or non-particle tags of the current event, such as weight information) is 
accessible through the Info class. 
 
If some information has been
Les Houches Event files can conform to version 1.0 (as agreed upon in [Alw06]) and version 3.0 of the standard (version 2.0 having been extended to 3.0 in [But14]). The LHEF version of an input file can can be accessed byInfo class. 
Note also the description of some settings in the 
Beam Parameters section. 
Theinformation is divided into the 
header, init and event blocks. 
The information stored in the header and init 
is: 
 
bool 
Info::isLHA().  As convenience feature, it is also possible to 
check if the end of the file from which events have been read in has 
been reached by calling bool Info::atEndOfFile(). 
double Info::sigmaGen(int i = 0) and 
double Info::sigmaErr(int i = 0). Please consult the 
Event Information section for further 
details. Alternatively, you may use the functions 
 int Info::nProcessesLHEF()   init 
block 
   
 double Info::sigmaLHEF(int i=0)   init block 
   
init block can be 
retrieved by calling int Info::lhaStrategy(). 
event block is: 
 
double Info::scalup(), see the 
Event Information section for further 
details. 
double Info::weight(), see the 
Event Information section for further 
details. 
Info class. An example main program using LHEF 3.0 
information is main127.cc. Note also the description of some 
settings in the Beam Parameters section. 
 
LHEF 3.0 offers new features both in the initialisation and the event sections 
of the input files. Possible information include extended 
use of XML tags in the <header> and 
<init> and event blocks. This LHEF 3.0 
information is stored in the Info class in a series 
struct's: 
 
<initrwgt> tag is a container 
tag for weight and weightgroup tags.   This information is stored 
internally in LHAinitrwgt. 
Currently, there is no dedicated 
output for this tag. However, all the information stored in the tag can 
be retrieved by using the Info class member pointer 
LHAinitrwgt Info::initrwgt. 
<weightgroup> tags: 
Container tag for weight tags. Currently, there is no dedicated 
output for this tag. However, all the information stored in the tag can 
be retrieved by using the Info class member pointer 
vector<LHAweightgroups> * Info::weightgroups. 
<weight> tags: Tag defining 
auxiliary information on an event weight, e.g. the identifier and information 
on what the weight represents. All the information stored in the tag can 
be retrieved by using the Info class member pointer 
vector<LHAweightgroups> * Info::init_weights. This vector 
contains all <weight> tags in the 
<initrwgt> container and its subcontainer 
<weightgroup> tags. The size of the vector can be accessed 
through the method 
<generator> tags: Store 
information on the generators used in the event generation. All the 
information stored in the tag can be retrieved by using the 
Info class member pointer 
vector<LHAgenerators> * Info::generators. More easy-to-use 
output functions are available. The size of this vector can be obtained from 
<generator> tag can 
be accessed through the method 
<generator> tag in 
the vector of tags. 
   
 
 
Attributes of the <generator> tag (e.g. the generator 
name and version) can be accessed via 
key for 
the n'th generator in the vector. Setting doRemoveWhitespace to 
true will return the value, stripped of any whitespace. An empty string is 
returned if the attribute named key does not exist. 
   
Info class 
member string getHeaderBlock(). For more information 
on the header block, please see the Header information paragraph 
above. Finally, to obtain information on cross sections, the following two 
methods can be used 
iProcess'th process. 
   
 
 
LHEF 3 also greatly extended the possible information stored within 
<event> blocs. In particular, multiple weights are 
supported, as are multiple scale values. Possible information from extended 
use of XML tags in the <event> block is: 
 
<rwgt> tag is a container 
tag for wgt tags. Currently, there is no dedicated 
output for this tag. It can however be retrieved by using the 
Info class member pointer 
LHArwgt Info::rwgt. 
<wgt> tags: Tag defining 
the event weight in the detailed version of LHEF 3.0.  All the information 
stored in the tag can be retrieved by using the Info class 
member pointer vector<LHAwgt> * Info::weights_detailed. 
More easy-to-use output functions are available. The size of this vector 
can be obtained from 
<wgt> tags is the Info class member 
vector<double> Info::weights_detailed_vector. The 
entries of this vector are ordered according to how <wgt> 
tags appear in the event block. 
 
 
The contents of a <wgt> tag can be accessed through the 
method 
<wgt> tag in the 
event. 
   
 
 
Attributes of the <wgt> tag (e.g. the weight 
id) can be accessed via 
key for 
the n'th wgt in the vector. Setting doRemoveWhitespace to 
true will return the value, stripped of any whitespace. An empty string is 
returned if the attribute named key does not exist. 
   
 
<weights> tag: Tag containing 
 a vector of double entries for weights in the compressed version 
 of LHEF 3.0. All the information stored in the tag can be retrieved by using 
 the Info class member pointer  LHAweights * 
 Info::weights and the vector  vector<double> 
 Info::weights_compressed. More easy-to-use output functions are 
 available. The size of this vector can be obtained from 
<weights> tag (not normally used) can be 
accessed via 
<weights> tag's attribute 
named key. Setting doRemoveWhitespace to 
true will return the value, stripped of any whitespace. An empty string is 
returned if the attribute named key does not exist. 
   
 
<scales> tag: Contains information 
 on different scales used by the matrix element generator. All the information 
 stored in the tag can be retrieved by using the Info class 
 member pointer  LHAweights * Info::scales. More easy-to-use 
 output functions are available. The contents of the scales tag can be 
 obtained from 
muf or mur). Attributes of the 
<scales> tag can be accessed via 
<scales> tag's attribute 
named key. Not-a-number will be returned if the attribute 
named key does not exist. 
   
 
<event> tag are 
supported. Attributes of the <event> tag can be accessed by 
key. Setting 
doRemoveWhitespace to true will return the value, stripped of 
any whitespace. An empty string is returned if the attribute named 
key does not exist. 
   
Additional comments appearing in the <event> tag 
can be obtained with the Info class member 
string getEventComments(). 
 
LHAupFromPYTHIA8. In order for it to do its job, 
it must gain access to the information produced by PYTHIA, 
specifically the process event record and the 
generic information stored in info. Therefore, if you 
are working with an instance pythia of the 
Pythia class, you have to instantiate 
LHAupFromPYTHIA8 with pointers to the 
process and info objects of 
pythia: 
LHAupFromPYTHIA8 myLHA(&pythia.process, &pythia.info); 
 
 
The method setInit() should be called to store the 
pythia initialization information in the LHA object, 
and setEvent() to store event information. 
Furthermore, updateSigma() can be used at the end 
of the run to update cross-section information, cf. 
closeLHEF(true) above. An example how the 
generation, translation and writing methods should be ordered is 
found in main124.cc. 
 
 
Currently there are some limitations, that could be overcome if 
necessary. Firstly, you may mix many processes in the same run, 
but the cross-section information stored in info only 
refers to the sum of them all, and therefore they are all classified 
as a common process 9999. Secondly, you should generate your events 
in the CM frame of the collision, since this is the assumed frame of 
stored Les Houches events, and no boosts have been implemented 
for the case that Pythia::process is not in this frame. 
 
 
The LHEF standard is the agreed format to store the particles of a 
hard process, as input to generators, whereas output of final states 
is normally handled using the HepMC 
standard. It is possible to use LHEF also here, however. It requires 
that the above initialization is replaced by 
LHAupFromPYTHIA8 myLHA(&pythia.event, &pythia.info); 
process is replaced by event. 
In addition, the PartonLevel:all = off command found in 
main124.cc obviously must be removed if one wants to 
obtain complete events. 
 
 
Pythia::Writer of LHEF3.h and 
LHEF3.cc) for this purpose. The functions of this 
file writer are used in the LHEF3FromPYTHIA8. 
This latter class allows users to output PYTHIA events 
in LHEF3 format from a PYTHIA main program. An example of how to use 
LHEF3FromPYTHIA8 is found in the 
main125.cc example. Please note that, although 
similar, the usage of LHEF3FromPYTHIA8 differs from 
the usage of LHAupFromPYTHIA8, with  LHEF3FromPYTHIA8 
 requiring fewer function calls. 
 
 
To print a comprehensive LHE file, LHEF3FromPYTHIA8 
is constructed with pointers to an Event object, 
as well as pointers to instances of Settings, 
Info and ParticleData, giving e.g. 
a constructor call 
LHEF3FromPYTHIA8 myLHEF3(&pythia.event, &pythia.settings, 
&pythia.info, &pythia.particleData); 
 
 
As a next step, you should open the output file by using the 
LHAupFromPYTHIA8 member function 
openLHEF(string name) 
name is the output file name. 
 
 
Then, the method setInit() should be called to store the 
initialization information (read from settings and 
info) and write the header and init blocks into the 
output file. Note that at this stage, the cross section printed 
in the init block is not sensible, as no integration has yet 
taken place. The init block can be updated at the end of 
the event generation (see below). 
 
 
During event generation, you should use setEvent() to 
write the event information (as read from info and 
event) to the output file. 
 
 
Finally, before leaving your main program, it is necessary to 
close the output file by using the 
LHAupFromPYTHIA8 member function 
closeLHEF( bool doUpdate = false) 
doUpdate is optional. 
If doUpdate is used, and if 
doUpdate = true, then the init block of the output 
file will be updated with the latest cross section information. 
 
 
Currently there are some limitations, that could be overcome if 
necessary. Firstly, you may mix many processes in the same run, 
but the cross-section information stored in info only 
refers to the sum of them all, and therefore they are all classified 
as a common process 9999. Secondly, you should generate your events 
in the CM frame of the collision, since this is the assumed frame of 
stored Les Houches events, and no boosts have been implemented 
for the case that Pythia::process is not in this frame.