Rivet developer guide
Checkout and build
What's the idea?
Projections are classes which define a "projection operator" on a generated event object. The result of the projection can be accessed through the projection class and can range from observables as simple as multiplicity counts up to complex quantities like event shapes, jet correlations and so-on.
Projections are the central kind of object in Rivet - the bricks from which more complex features like Analyses are built. Much of the infrastructure of Rivet is designed to make Projections efficient - if two Analyses internally use the same type of projection, then only one projection will be created and its operation on each event will only be calculated once. Ideally, the analyses authors don't need to know any of the details of this...
An Analysis is an implementation of an experimental analysis (nominally a paper, though it might just be a subset of the data found in a published paper) using the Rivet Projection mechanisms. Analyses can be accessed from outside Rivet, and applied to events: this is one of the major roles of RivetGun.
Analyses should be named either after the
hep-ex record (NB. isn't this changing?) or the published paper. Any Analysis added to Rivet should have a corresponding paper entry in the HepData database, and an AIDA version of this paper should be added to the Rivet collection of reference data files (see the entry on this below). If the data in HepData is incomplete or wrong, Analysis authors should contact the HepData admins (Mike Whalley) to get it updated/corrected.
RivetInfo objects are structured descriptions of the Projection or Analysis that produces them. They can be used to specify restrictions on the sorts of events which can be analysed by that Analysis or Projection, such as the pair(s) of acceptable beam particles, energy ranges, kinematic cuts and so-on.
RivetInfo needs a bit of an overhaul to introduce the beam type info and to use enumerations to describe the other cuts. RivetInfo objects themselves do not place a veto on applying certain analyses to unsuitable event types - they merely provide a mechanism for conscientious client applications (like RivetGun... eventually) to do so.
HepData reference data
The plan is for HepData to export AIDA XML format data records for each Analysis in Rivet. These will have a standard internal path structure, enabling Analysis histograms to be booked as exact copies of the reference histograms in HepData. The HepData AIDA data reference files will be written to the Rivet share path at install time - they can be located by running the
lhapdf-config script, which users/sysadmins should ensure is in the user execution path, i.e. the PATH environment variable.
Coding style guide