AGILe is hosted by Hepforge, IPPP Durham

RivetGun generator interfaces

Available Generators

Parameter Setting

Parameters can be specified in a simple text file. The filename is specified using the -P commandline flag. Example parameter files are installed in ${INSTALL_PATH}/share/RivetGun.

Eventually it will be possible to specify parameters as HepML files as well.


Each subclass of Generator must implement a setKinematics (or something) method which takes the information collected from the all the rivet analysis classes which have been added to the rivet handler and uses it to determine the minimal safe phase space in which the generator can be run.

Each subclass of Generator must be able to tell the RivetGun what subprocesses need to be run to simulate the appropriate rivet analysis list for a given input Model.

The bulk of RivetGun at the moment is a set of object-oriented generator interface libraries. It's easiest to get an idea of the structure by looking at the code documentation. The idea is that a parent libRivetGun library describes the abstract Generator interface and then each class of generators (e.g. FHerwig) gets a separate library which contains concrete implementations of the generators, e.g. libFHerwig6510. These libraries must all be able to be built without need for the corresponding generator library or headers to be on the system.

Writing applications to use these generator libraries can either be done statically with the library on the system or dynamically, where the generator library only needs to be present at run-time. The rivetgun command line tool is an example of the latter.

Independence from RivetGun

The usefulness of a uniform, simple, OO interface to generators is not limited to RivetGun. I propose that this should be combined with the generator wrapper portion of HepMC to make a stand-alone generator interface library. Proposed name: AGILe (as in "A Generator Interface Library" with an "e" on the end just for niceness!)

The Generator interface

Methods such as initialize(), run(), fillEvent(HepMC::GenEvent) and finalize(). TODO: ADD MORE...

To come:

  • std::string name()
  • void setParam(const std::string& name, const double value)
  • void setParam(const std::string& name, const int value)
  • void setParam(const std::string& name, const std::string& value)
  • void setParam(const std::string& name, const int arrayindex, const double value)
  • void setParam(const std::string& name, const int arrayindex, const int value)
  • void setParam(const std::string& name, const int arrayindex, const std::string& value)

Do we need some special way to handle Pythia 8 configuration maps?

How do we verify that a name should be used with an array, map or simple param? How do we verify types? Validation in HepML? Explicit lists of allowed params in the concrete generator wrapper classes?

What is a unique generator?

Do we count "FHerwig" and "FHerwig+Jimmy" as separate generators? In principle this forces us to make every compatible combination of generator + add-on version possible, which is combinatorically unfeasible: that's not a problem, we just have to be selective about which combinations are the most sensible.

*Current status is this is done case-by-case.*

Jimmy is treated as an intrinsic part of FHerwig. Any generator wishing to make use of Jimmy (e.g. AlpGen or in future MC@NLO) will have to make use of FHerwig. Since so many Herwig parameters also affect Jimmy, this make sense.

In contrast, AlpGenFHerwig and AlpGenFPythia are separate generators, both of which internally use an instance of FHerwig or FPythia respectively. The also makes sense, since there are very few AlpGen-specific parameters (once you have generated the LHA files, anyway, which is assumed to be done before running RivetGun). So there is not much doubling of code by doing it this way. And it would be very tricky to make AlpGen a part of both Pythia and Herwig.

Last modified 10 years ago Last modified on Oct 23, 2008, 3:57:06 PM