Les Houches Event Files

Event input
Transfer to the PYTHIA process record
Structure of Les Houches Event Files
Retrieving the information read from LHEF
PYTHIA 8 output to a Les Houches Event File version 1.0
PYTHIA 8 output to a Les Houches Event File version 3.0

The most common application of the Les Houches Accord (LHA) for user processes [Boo01] is to read input from a Les Houches Event File (LHEF) [Alw06], but it is also possible to have a runtime interface to another program.

A "no-beams" extension, currently not part of the standard, has been implemented. In this case only one part of a complete event is studied, and so no meaningful beam information can be set. The prime example is to study the decay properties of a resonance, where a parton-level decay chain is provided as input, and then showers and nadronization should be added. This simplified option does not cover R-hadron formation and may not handle junction topologies in baryon-number-violating decays. Normally it is assumed that parton showers in the decays are fully handled by PYTHIA, but you can also specify multiparton configurations as the starting point. Then it is important to avoid doublecounting between emissions accounted for by matrix elements and by shower, by a judicious choice of scales or by a rejection of unwanted emissions in a user hook. Another example would be where a given partonic configuration would be hadronized, without any previous showers. See further below and in the Hadron-Level Standalone description.

Another unofficial extension is the support for Double Parton Scattering (DPS), i.e. when two hard scatterings should be defined. This is allowed by letting one follow after the other in the event listing, such that two 2 → 2 scatterings are specified by eight lines. It is here required that daughters are located below mothers strictly within each scattering separately, since the logic needed to sort out an arbitrary ordering is deemed overkill for such a peripheral case. An additional line #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.

Event input

The maximum scale for parton-shower evolution of a Les Houches event is regulated by the 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.

Transfer to the PYTHIA process record

There are a few settings available for event input. They take effect when the LHA event record is translated to the PYTHIA process event record, but leaves the LHA event record itself unchanged.

mode LesHouches:idRenameBeams (default = 1000022; minimum = 0)
PYTHIA only implements a certain number of incoming beam particles. Specifically it needs to have PDFs for every composite particle to be used. Sometimes exotic beam particles are used, e.g. when a neutralino is supposed to be the Dark Matter particle and therefore neutralino pairs can collide and annihilate. Such a particle identity code, picked by this mode, is mapped onto an incoming tau neutrino beam (or antineutrino for the second beam), to bring it to a familiar situation. The trick cannot be used for composite particles, nor for a pair of different particles.

mode LesHouches:setLifetime (default = 1; minimum = 0; maximum = 2)
handling of the decay time information stored in 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)
setting of mass for final-state charged leptons. The reason here is that some matrix-element generators assume leptons to be massless, so as to simplify calculations. This is particularly common for the e and mu leptons, but sometimes also the tau lepton is afflicted. Incoming leptons are not affected by this procedure.
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.
Warning: when the mass is changed, also energy and/or momentum need to be shifted. This cannot be done for the lepton in isolation, but should be made so as to preserve the energy and momentum of the event as a whole. An attempt is therefore made to find another final-state particle recoiler that can transfer the appropriate amount of energy and momentum. The recoiler may be unstable, and if so the transfer is inherited by its decay products. The choice is straightforward if only two final-state particles exist, or in a two-body decay of an intermediate resonance, else a matching (anti)neutrino or (anti)lepton is searched for. These rules catch most of the standard cases for lepton production, such as gamma^*/Z^0/W^+-, but not necessarily all. Should they all fail the potential final-state recoiler with largest relative invariant mass is picked. In either case, if the transfer fails because the intended recoiler has too little energy to give up, then instead the energy is recalculated for the new mass without any transfer. The energy violation is partly compensated by changed energies for the incoming partons to the hard collision if LesHouches:matchInOut = on, but not always perfectly. One possibility then is to change the tolerance to such errors.

mode LesHouches:setQuarkMass (default = 1; minimum = 0; maximum = 2)
setting of mass for final-state quarks. The reason here is that some matrix-element generators assume all quarks to be massless, except for the top, so as to simplify calculations. Especially for c and b quarks this is a poor approximation, although PYTHIA most of the time still manages to shower and hadronize even such events. The reason is the resilience of the string fragmentation model, where the excess gluons near (in colour and momentum) to a massless b are "eaten up" when string fragmentation needs to gather enough invariant mass to give to the B hadron. Nevertheless it is an uncomfortable situation, to be avoided where possible. For d, u and s quarks the issue is less critical. Incoming or intermediate quarks are not affected by this procedure.
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.
Warning: when the mass is changed, also energy and/or momentum need to be shifted. This cannot be done for the quark in isolation, but should be made so as to preserve the energy and momentum of the event as a whole. An attempt is therefore made to find another final-state particle recoiler that can transfer the appropriate amount of energy and momentum. The recoiler may be unstable, and if so the transfer is inherited by its decay products. The choice is straightforward if only two final-state particles exist, or in a two-body decay of an intermediate resonance. If no recoiler is found this way a matching opposite-coloured parton is searched for. Should also this fail the potential final-state recoiler with largest relative invariant mass is picked. In either case, if the transfer fails because the intended recoiler has too little energy to give up, then instead the energy is recalculated for the new mass without any transfer. The energy violation is partly compensated by changed energies for the incoming partons to the hard collision if LesHouches:matchInOut = true, but not always perfectly. One possibility then is to change the tolerance to such errors.

parm LesHouches:mRecalculate (default = -1.)
Does not have any effect by default, or more generally when it is negative. If it is positive then all particles with an input mass above this value will have the mass recalculated and reset from the four-momentum, m^2 = E^2 - p^2. This step is prompted by an unforeseen choice made in some programs (like CalcHEP) of storing the nominal mass of a particle species rather than the mass of the current member of that species, a choice that is likely to induce energy-momentum nonconservation when the event is further processed. Obviously such a recalculation is problematic numerically for light particles, so it should only be used for the programs and particles where it is needed. Thus the value ought to be at least 10 GeV, so that only massive particles like W^+-, Z^0 and t are affected. If a particle does not have its mass recalculated, currently instead the energy is recalculated from its three-momntum and mass. This is to avoid spurious mismatches from limited numerical precision in an LHEF.

flag LesHouches:matchInOut (default = on)
The energies and longitudinal momenta of the two incoming partons are recalculated from the sum of the outgoing final (i.e. status 1) particles. The incoming partons are set massless. There are two main applications for this option. Firstly, if there is a mismatch in the Les Houches input itself, e.g. owing to limited precision in the stored momenta. Secondly, if a mismatch is induced by PYTHIA recalculations, notably when an outgoing lepton or quark is assigned a mass although assumed massless in the Les Houches input.
Warning: it is assumed that the incoming partons are along the +-z axis; else the kinematics construction will fail.

Structure of Les Houches Event Files

The LHEF standard ([Alw06], [But14]) specifies a format where a single file packs initialization and event information. This has become the most frequently used procedure to process external parton-level events in Pythia. To access this, you must set 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 -->

Normally the LHEF would be in uncompressed format, and thus human-readable if opened in a text editor. A possibility to read gzipped files has been added, based on the Boost and zlib libraries, which therefore have to be linked appropriately in order for this option to work. See the 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 main11.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 main12.cc. A variant, based on input in a command file, is given in main13.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
(digit) ('.' or absent) ('d' or 'D') ('+', '-' or absent) (digit)
It will work on all parts of the file, also inside a <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

Header information

A simple string key/value store, mainly intended for accessing information that is stored in the header block of Les Houches Event (LHE) files. In principle, any 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)
return the header named key

vector <string> Info::headerKeys()
return a vector of all header key names

void Info::setHeader(string key, string val)
set the header named key with the contents of val

Retrieving the information read from LHEF

Information passed to PYTHIA through LHE files is handled in, and can be retrieved by two ways. The collection of particles transferred through the Les Houches event is directly accessible through the event record. A copy of the hard scattering event (i.e. the hard particle identifiers, colors, momenta etc. read from the Les Houches event file) is stored in the 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 by
int Info::LHEFversion()

LHEF 1.0 information

Please find below the documentation of LHEF 1.0 information as stored in the Info 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:

To check if the process information has been generated by external Les Houches Accord, you can infer the function 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().

If the process has been transferred through LHEF, then you can retrieve the cross section values and errors by calling 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()
to retrieve the number of cross sections stored in the LHEF init block
double Info::sigmaLHEF(int i=0)
to retrieve the value of i'th cross sections stored in the LHEF init block

The weighting strategy indicated in the init block can be retrieved by calling int Info::lhaStrategy().

The event-by-event information read from the event block is:

The scale associated with the event, which can be obtained from a call to double Info::scalup(), see the Event Information section for further details.

The weight associated with the event can be retrieved from a call to double Info::weight(), see the Event Information section for further details.

LHEF 3.0 information

Please find below the documentation of LHEF 3.0 information as stored in the Info class. An example main program using LHEF 3.0 information is main38.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:

The <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.

Multiple <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.

Multiple <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
int Info::getInitrwgtSize()

Multiple <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
int Info::getGeneratorSize()

The contents of an individual <generator> tag can be accessed through the method
string Info::getGeneratorValue(unsigned int n = 0)
Return the contents of the n'th <generator> tag in the vector of tags.
Attributes of the <generator> tag (e.g. the generator name and version) can be accessed via
string Info::getGeneratorAttribute(unsigned int n,
string key, bool doRemoveWhitespace = false)"> Return the value of the generator attribute named 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.

Note that the complete header can be obtained with the 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
int Info::nProcessesLHEF()
return the number of processes for which the cross section is stored.
double Info::sigmaLHEF(int iProcess)
return the cross section of the 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:

The <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.

Multiple <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
unsigned int Info::getWeightsDetailedSize()
A convenient access point to the information stored in the <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
double Info::getWeightsDetailedValue(string n)
Return the value of the n'th <wgt> tag in the event.
Attributes of the <wgt> tag (e.g. the weight id) can be accessed via
string Info::getWeightsDetailedAttribute(string n, string key, bool doRemoveWhitespace = false)
Return the value of the wgt attribute named 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.

The <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
unsigned int Info::getWeightsCompressedSize()

The n'th weight can be accessed through the method
double Info::getWeightsCompressedValue(unsigned int n)

Attributes of the <weights> tag (not normally used) can be accessed via
string Info::getWeightsCompressedAttribute(string key, bool doRemoveWhitespace = false)
Return the value of the <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.

The <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
string Info::getScalesValue()

However, note that the actual scale values are stored as attributes (called e.g. muf or mur). Attributes of the <scales> tag can be accessed via
double Info::getScalesAttribute(string key)
Return the value of the <scales> tag's attribute named key. Not-a-number will be returned if the attribute named key does not exist.

Finally, arbitrary attributes of the <event> tag are supported. Attributes of the <event> tag can be accessed by
string Info::getEventAttribute(string key, bool doRemoveWhitespace = false)
return the value of the event 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. Additional comments appearing in the <event> tag can be obtained with the Info class member string getEventComments().

PYTHIA 8 output to a Les Houches Event File version 1.0

The above methods could be used by any program to write an LHEF. For PYTHIA 8 to do this, a derived class already exists, 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 main20.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);
i.e. that process is replaced by event. In addition, the PartonLevel:all = off command found in main20.cc obviously must be removed if one wants to obtain complete events.

PYTHIA 8 output to a Les Houches Event File version 3.0

PYTHIA 8 also supports LHEF 3.0 output, and we include a general LHEF3 writer (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 main20lhef3.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)
where 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)
The boolean variable 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.