pkgs/Slicer (NOvA offline)

The Slicer package splits an event into "slices" (RecoBase/Clusters) based on the positions and times of detector activity. The goal is to produce slices that each correspond to an indivdual interaction (neutrino or cosmic ray induced). Downstream algorithms can then operate on the individual interactions. A "noise" slice, always written last, contains those hits that seem unrelated to any bulk activity.

  • Input: rb::CellHits
  • Output: rb::Clusters, one for each slice

For a comprehensive talk describing the features of Slicer refer to document 6805 on doc-db by Susan Lein.


The Slicer package provides the Slicer module. Default configuration(s) are provided in slicer.fcl.

Slicer currently has these configuration parameters:

Name Type Default Description
CellHitFolderIn string "Hits" location of input rb::CellHits on the Cal() branch
ClusterFolderOut string "Slices" location of output rb::Clusters on the Reco() branch
DoNotSliceAnything int 0 set to true (non-zero) to produce a single output slice (with all the hits) plus an empty noise slice

Technical description

First, a couple of definitions:
  • Two hits are "neighbors" of each other if they are (a) in the same view, (b) within 5 planes of each other, and (c) within 6 cells of each other.
  • The notation "(a, b, c)" below indicates the values taken for the "(ND, NDOS, FD)". NOTE: the NDOS values are both 530 to reflect the DCS-level timing that we have at present. When we get fine-timing back in the MC (i.e., when we get it in real life), these values would be 80 ns in Step 1 and 250 ns in Step 2.

Step 1. The rb::CellHits are time sorted. Slicer walks through the sorted list looking for time gaps greater than (40, 530, 100) ns, ignoring those hits that have zero or one neighbors. (That is, spatially isolated hits cannot be the sole "bridger" of a time gap.) These time-gap-separated collections of hits defines an initial suite of slices. Many of these slices will be single hits standing alone in space and time.

Step 2. If a slice has fewer than four hits, an attempt is made to merge its hits with other, larger slices. A hit will be successfully merged if that hit is both (a) a neighbor of some hit from a "large" slice and (b) within (100, 530, 350) ns of that neighbor. If multiple candidate neighbors/slices exist, ones that come before the to-be-merged hit are given precedence over ones that come after, and (secondarily) ones nearer in time are given precedence over ones more separated in time.

Step 3. Any hits not successfully merged are collected into a single "noise" slice.

All the slices are then written out, including the noise slice. The output noise slice could be empty, but that would rare. (Possible usage: a downstream reconstruction package might choose to rummage through the noise slice looking for hits related to whatever slice it is working on. Another: a Michel electron may make only one or two hits (and thus not a slice); so, once a reconstructed muon track is in hand, one could look in the noise slice for those few hits of activity right at the end of the muon track.)

Looking at slices in the event display
Slices are rb::Cluster objects, so the event display can drawn them. There are multiple cluster drawing options available, and option 2 makes visualizing the slices easiest. To view slices, open a post-Slicer root file and turn on the drawing of clusters:
  • Edit->RecoBase Objects Drawing Options->ClusterFolders should include ./Slices (or whatever you changed the output folder to in the Slicer job.)
  • Edit->RecoBase Objects Drawing Options->DrawClusters should be set to 2 to get the point-wise cluster rendering rather than the outline cluster rendering.

An NDOS event:

The same event with the slices indicated:

Some things to notice
  1. Four slices: neutrino event, cosmic ray, Michel electron (at the end of the long track), and noise.
  2. In this DrawClusters==2 mode, the same marker type / marker color is used in both views for a Cluster's hits. Thus, the slices can be seen across views. (This is useful when slices overlap in one view.)
  3. There are five symbols and five colors defined, so if there were more slices (Clusters), the colors would wrap and the symbols would increment.

Final note: Slicer algorithm-controlling parameters of some sort will migrate to the XML file, but for now I'm keeping the user interface clean, as the algorithm itself is more likely to get tweaked than these particular parameter values are.