Execution in Detail

Consider the following user-specified pipeline:

• Selection1: Creates a selection mask on events.

• Selection2: Creates another mask on events.

• SelectOnColumns: Uses the previously created masks to filter events.

• JetScaleCorrections (Jet Correction): Does some correction on jets; it declares dynamic parameters called systematic with possible values central, up, and down.

• JetFilter: Filters jets with some parameters.

• PileupSF (PileupScaleFactor): Adds some weight to the events.

• JetPtHistogram: Creates a histogram of jet \(p_T\).

Let’s examine how a single chunk of events is processed:

• The first module in the pipeline is always a LoadColumns module. It is added implicitly by the framework to any user-specified pipeline; the user does not need to add it. It has dynamic parameters chunk and metadata. Of course, it has no event input. When it runs, it loads the requested chunk and creates a TrackedColumns object.

• Each of the selections runs. In the backend, each selection adds a column to events which is the boolean mask of the requested selection. Note that no actual slicing of the array has been performed yet.

• SelectOnColumns runs, which actually filters the events.

• JetCorrection (using JetScaleCorrections) runs using the default systematic "central".

• JetFilter runs, changing the shape of jets.

• PileupSF runs, adding a column Weights.pileup_sf.

• JetPtHistogram runs and returns a ModuleAddition result, with a certain RunBuilder and a certain module HistogramBuilder.

• This ModuleAddition requests a multi-run with systematics on the jet corrections. This starts a new pipeline for each systematic \(S\):

  • We start from the beginning with LoadColumns. However, since the chunk is the same, we can use the cached result.

  • This holds true for Selection1, Selection2, and SelectOnColumns, where we can use the cached result.

  • The dynamic parameter systematic of JetCorrection (corresponding to JetScaleCorrections) changes to \(S\), so the correction module is re-run.

  • JetFilter is re-run, since it depends on the column Jet, which was changed.

  • PileupSF uses the cached result, since it does not depend on Jet.

  • JetPtHistogram re-runs and produces another ModuleAddition, which is ignored (results are ignored within a nulti-run).

  • The three sets of events corresponding to the up, down, and central systematics are passed to the HistogramBuilder module, which returns a single Histogram containing an axis called "systematic", and any number of other data axes.

  • This ends the multi-run.

• The results are returned.

This process is visualized below.