SMASH Rivet output interface directly to Rivet analyses on the events generated by SMASH. That is, instead of writing the events to disk (or pipe) this output module generates HepMC (see also HepMC Output) events in-memory and pass them on directly to Rivet to avoid the costly encoding and decoding of HepMC3 events to and from disk (or pipe). This provides a speed up (at least \(\times 10\)) compared to intermediate files.

The results of the analyses are written to YODA files.

Internal event formats

Internally, this output module generates HepMC events. These can be made in two ways, selected by the formats YODA and YODA-full

YODA In this format only initial (beam) and final state particles are stored in the event structure and there is only one interaction point. Note, the incoming nucleons are combined into single nuclei.
YODA-full In this format, the whole event is stored (including intermediate states). Note, the incoming nucleons are combined into single nuclei, only to be split at the main interaction point. This allows tracking of the individual nucleons.

Only one format can be chosen. SMASH will use the first format recognized as valid, ignoring the rest. Please, note that choosing YODA or YODA-full determines the kind of information available to the analysis, but the content of the final YODA files depends on the analysis itself. Depending on what it does, the analysis might work fine with both formats, nevertheless, if it is not necessary to know the structure of the whole event, it is recommended to choose the lighter YODA format, thus saving computational time and resources (especially the RAM).

Configuration

The Rivet process can be configured in the main configuration file. This is done by adding keys to the Rivet key. Here, we can

Set load paths for data and analyses (Paths)
Preload data files - e.g., centrality calibrations (Preloads)
Specify which analyses to run (Analyses)
Choose whether to not validate beams (Ignore_Beams)
Set log levels in Rivet (Logging)
Specify weight handling (Weights)
and more ... (see below)

An example:

Output:
   Rivet:
     Format: ["YODA"]
     Ignore_Beams: True
     Logging:
       Rivet.AnalysisHandler: Debug
       Rivet.Analysis.MC_FSPARTICLES: Debug
     Analyses:
       - MC_FSPARTICLES

The Rivet set-up can be configured through the Output section in the configuration file

Rivet (top of Rivet configuration)
- Format (list of strings, no default) List of formats to generate Rivet instance for. Can be one of
  - YODA Only initial (beam) and final state particles are available in the events.
  - YODA-full Full event structure present to analyse
- Paths (list of strings, no default) This key specifies the directories that Rivet will search for analyses and data files related to the analyses.
- Analyses (list of strings, no default) This key specifies the analyses (including opossible options) to add to the Rivet analysis.
- Preloads (list of strings, no default) Specify data files to read into Rivet (e.g., centrality calibrations) at start-up.
- Logging (map of string to string, no default) Specifies log levels for various parts of Rivet, including analyses. Each entry is a log name followed by a log level (one of TRACE,DEBUG,INFO,WARN,ERROR, and FATAL)
- Ignore_Beams (bool, default true) Ask Rivet to not validate beams before running analyses. This is needed if you use the option Fermi_Motion (Collider) that disrupts the collision energy event-by-event
- Cross_Section (double,double, no default) Set the cross-section in pico-barns
- Weights (container, no defaults)
  - No_Multi (bool, default false) Ask Rivet to not do multi-weight processing
  - Nominal (string, no default) The nominal weight name
  - Select (list of string, no default) Select these weights for processing
  - Deselect (list of string, no default) De-select these weights for processing
  - NLO_Smearing (double, default 0) Smearing histogram binning by given fraction of bin widths to avoid NLO counter events to flow into neighboring bin.
  - Cap (double, no default) Cap weights to this value.