# Documentation of g4sbs

## Documentation of g4sbs: Overview

This page is maintained by the UConn group (Andrew Puckett) and as of July 22, 2015 is specific to the "uconn_dev" branch of g4sbs on github.

### Coordinate System(s)

The global coordinate system of the simulation has

• +X horizontal to beam left
• +Y vertically up
• +Z along the beam direction

There are several "local" coordinate systems specific to different detectors in the simulation. These are discussed in the "ROOT tree structure" section below.

### System of units

The standard GEANT4 system of units is used. See GEANT4 user's guide for details. The default units assumed unless otherwise specified in the code are mm, ns and MeV for distance, time and energy-dimensioned quantities, respectively. Commands defined below that require units may be specified using any of the units in the standard CLHEP unit definitions.

Note: All quantities written to the ROOT tree that constitutes the main output of g4sbs (see below) are expressed in meters, ns, GeV for distance, time and energy. Angles in the ROOT tree are expressed in radians

## Getting the code and building the program

### Prerequisites

• Working ROOT installation. g4sbs is not yet compatible with root version 6!
• Working GEANT4 installation. For the uconn_dev branch (as of January 14, 2016), g4sbs is only compatible with GEANT4 version 10.1 and later. Other branches (except for the "geant4.10" branch), including the master branch, are only compatible with GEANT4 version 9.x and earlier
• cmake (also required in any case to build GEANT4).

Note on GEANT4 build options:

• GEANT4_INSTALL_DATA=ON is needed for installations on new machines.
• Qt note: On Mac OS X, I have built GEANT4 against Qt version 5.3.2. Your mileage may vary with newer versions of Qt. On Linux, the open-source version of Qt provided by the package manager of your distribution is recommended.

The code is hosted on a github repository owned by JLab. To clone via ssh (preferred method on JLab batch farm), do:

 git clone git@github.com:JeffersonLab/g4sbs.git

For this method to work, the ssh public key on the machine where you want to get the code must be added to your github account (see Guide to generating ssh keys and adding to your github.com account.)

Cloning the repository defaults to the "master" branch. This page documents the "uconn_dev" branch, which will soon be merged into the master branch. To change to the "uconn_dev" branch, do:

 git checkout uconn_dev

### Building the program

Create a "build" directory that is parallel to the "g4sbs" source directory (this is not strictly required, but the build directory must be separate from the "g4sbs" directory in any case). The following instructions assume that "build" is parallel to "g4sbs":

 mkdir build cd build cmake ../g4sbs make

If successful, the g4sbs executable and several other files and folders will be created in the "build" directory.

### Configuring the environment on the JLab batch farm

Updated January 14, 2016:

To use the standard versions of ROOT and GEANT4 supported by JLab on the batch farm, add the following lines to the ".login" file on your JLab CUE home directory:

 setenv JLAB_VERSION 1.3 setenv JLAB_ROOT /site/12gev_phys source $JLAB_ROOT/$JLAB_VERSION/ce/jlab.csh

As of January 14, 2016, the JLab version "1.3" software versions on the JLab batch farm are:

• ROOT version 5.34.34
• GEANT4 version 4.10.01.p02

## How to run the program

g4sbs works in two different modes, batch mode or interactive mode. In interactive mode, visualization of the geometry and events is possible. To run in interactive mode, do

 ./g4sbs

This will launch an interactive g4sbs session which, depending on your GEANT4 build, might be a csh terminal, a Qt GUI, or something in between. The Qt GUI in particular has a complete help menu:

In an interactive g4sbs session, individual commands can be invoked, or macros with many commands can be executed using:

 /control/execute file.mac

Due to the structure of the program, all commands invoked in an interactive session are executed after initialization of the GEANT4 kernel; i.e., after the invocation of G4RunManager::Initialize(). At the command prompt or in macros, all standard GEANT4 commands are available as well as g4sbs-specific commands (see below).

To run g4sbs in batch mode, do one of the following:

 ./g4sbs file.mac OR ./g4sbs preinit.mac postinit.mac,

where each ".mac" file is a text file containing valid GEANT4 and/or g4sbs commands, used to configure the simulation. If g4sbs is invoked with one command-line argument as in the first example, it will execute all the commands in "file.mac" after G4RunManager::Initialize(). If g4sbs is invoked with two command line arguments as in the second example, it will execute the commands in "preinit.mac" before G4RunManager::Initialize() and the commands in "postinit.mac" after G4RunManager::Initialize(). As detailed below, this feature was added to make it possible for the user to disable optical photon production via the Cherenkov and Scintillation processes without re-compiling the code, and a long-standing GEANT4 bug prevents disabling of the scintillation process via the standard /process/inactivate command.

Update January 25, 2016: New command-line options

Several options were added to the command-line arguments to g4sbs to allow the user more flexible control. Macro filenames may now be prefixed with keywords "preinit=" or "postinit=" to indicate that the commands are to be executed before or after initialization, respectively. These keywords can also be used to override the default ordering of command-line arguments. The optional "batch=X" argument was added (where X=0,1 or false,true) to force g4sbs to run in batch or interactive mode. In practice, only the "batch=0" or "batch=false" case is necessary, since in all cases where it makes sense to run in batch mode, batch mode is selected by default. Some combinations of these arguments are nonsensical; for example, if only pre-initialization commands are given, then only interactive mode makes sense, since the "/g4sbs/run" command which builds the geometry and generates events can only be executed after the initialization phase. Here are some examples of valid command-line invocations of g4sbs:

• ./g4sbs file.mac: execute the commands in file.mac after initialization, run in batch mode by default.
• ./g4sbs file1.mac file2.mac: execute the commands in file1.mac(file2.mac) before (after) initialization, run in batch mode by default.
• ./g4sbs preinit=file.mac: execute the commands in file.mac before initialization, run in interactive mode.
• ./g4sbs file.mac batch=0: execute the commands in file.mac after initialization, but force running in interactive mode (batch=false also works).
• ./g4sbs file1.mac file2.mac batch=0: execute the commands in file1.mac (file2.mac) before (after) initialization; run in interactive mode.
• ./g4sbs postinit=file1.mac preinit=file2.mac: run in batch mode, execute file2.mac (file1.mac) before (after) initialization.

## g4sbs commands

### Documentation of all commands

This section documents all g4sbs commands defined in the uconn_dev branch as of July 23, 2015. Command names are case-sensitive!

• /g4sbs/run: Starts a simulation run. Requires one integer argument defining the number of events to simulate (which is allowed to be zero). Note that this command forces building or rebuilding of the geometry, in contrast to /run/beamOn, which does not re-initialize the G4 kernel. Presently, g4sbs will crash if the /g4sbs/run command is invoked more than once in a g4sbs session (bug is under investigation), meaning that configuration changes require separate simulation jobs.
• /g4sbs/gemconfig: expects one integer argument, defines BigBite GEM layout, possible values are 1 (default), 2, 3. Currently, option 1 is the only option that is compatible with the GRINCH geometry and is therefore recommended.
• /g4sbs/CDetconfig: defines configuration of the coordinate detector. This command is obsolete and currently has no effect
• /g4sbs/flipGEM: requires one boolean argument. Defaults to false. If true, reverses orientation of GEM materials front to back within each GEM chamber. Currently the command applies to ALL GEMs in the simulation.
• /g4sbs/ECALmap: Accepts one string argument which is the name of a text file listing active ECAL cells (rows, columns). File is assumed to be located in the "database/" subdirectory. This command is obsolete and currently has no effect
• /g4sbs/filename: Define output ROOT file name.
• /g4sbs/sigmafile: File containing GEM coordinate resolutions by chamber ID number. This command is obsolete and currently has no effect
• /g4sbs/target: Choose target type. Possible values currently include:
• LH2: liquid hydrogen target with scattering chamber and vacuum snout. Density fixed at 0.071 g/cm$^3$
• LD2: liquid deuterium target with scattering chamber and vacuum snout. Density fixed at 0.1624 g/cm$^3$
• H2: Hydrogen gas target, fixed pressure of 10.5 atm at 300 K
• 3He: Helium-3 gas target, fixed pressure of 10.77 atm at 300 K.
• neutron: Free neutron target, fixed pressure of 10.5 atm at 300 K.
• Note: All gas targets are currently enclosed in a GE180 glass cell with endcap thickness of 0.126 mm and wall thickness of 1.61 mm
• /g4sbs/kine: Choose kinematics for event generator. In all cases, unless otherwise noted, interaction vertex is generated flat assuming a rectangular, uniform raster pattern centered at (x,y)=(0,0) with user-defined raster size in x and y, and z along the target length. No "internal" or "pre-vertex" external radiative corrections are included in any of the event generators so far. Currently available kinematics types are:
• elastic: elastic electron-nucleon scattering. Electron polar and azimuthal angles are generated flat in $\cos \theta$ and $\phi$ within user-defined limits, everything else calculated from energy-momentum conservation. Cross section according to Kelly fit for GEp, GMp, GMn and Hall A GEn collaboration fit of GEn data. No radiative corrections. Behavior depends on target type:
• For H2 or LH2 or neutron targets: elastic electron scattering from free proton (or neutron) at rest
• For LD2 or $^3$He targets: Quasi-elastic electron-nucleon scattering with Fermi motion simulated by sampling the initial nucleon momentum from the momentum distribution in deuterium or $^3$He.
• inelastic: Inclusive inelastic electron-proton or electron-deuteron scattering. Generates electron scattering angles flat in $\cos \theta$ and $\phi$ within user-defined limits and generates electron energy flat from zero up to the full beam energy. Requires energy-momentum conservation. Uses Christy-Bosted parametrizations of inclusive p(e,e') (http://arxiv.org/abs/0712.3731v4) and inclusive d(e,e') (http://arxiv.org/abs/0711.0159v4) to compute inclusive inelastic cross sections for proton and neutron. Generates a final-state nucleon by assuming that the hadronic final state is $N\pi$ and that the pion momentum is generated isotropically in the rest frame of the virtual-photon-nucleon system.
• flat: Generate electron angles flat in $\cos \theta$, $\phi$, and $E'$. Generate final nucleon assuming that the outgoing nucleon absorbs all of the three-momentum transfer from the electron. Not clear how much sense this makes physically.
• dis: Deep inelastic scattering. Generate scattered electron angles flat within user-defined limits, generate $E'$ flat in $0 \le E' \le E$. Reject event if not kinematically allowed. Don't generate any final hadrons. Cross section based on CTEQ6 PDFs and neglect of longitudinal structure function $F_L = 0$
• beam: Beam kinematics. Generate beam electrons 5 meters upstream of the target with (x,y) according to normal raster size definitions. This option is the "minimum bias" generator that throws beam electrons at the target, and is typically used for background rates/detector occupancies/etc.
• sidis: Single-hadron semi-Inclusive deep inelastic electron-nucleon scattering (SIDIS) $N(e,e'h)X$. Generate outgoing electron and hadron angles flat in $\cos \theta$ and $\phi$ within user-defined limits. Generate outgoing electron and hadron energies flat within user-defined limits. Check four-momentum conservation and reject event/try again until a kinematically allowed event is returned. Compute cross section according to CTEQ6 PDFs and DSS2007 fragmentation functions. Assume flavor-independent Gaussian transverse momentum widths for PDF and fragmentation function. Neglect the longitudinal cross section for SIDIS. On output, normalize phase-space volume for event generation according to the efficiency for generating kinematically allowed events. Hadron $h = \pi^+$, by default. See /g4sbs/hadron for available hadrons in the event generator.
• wiser: Single inclusive hadron production. Generate outgoing hadron angles and energy flat within user-defined limits, compute "Wiser" cross section. See /g4sbs/hadron for available hadrons for this generator. Cross section calculation only defined for $\pi^\pm, \pi^0$.
• gun: Generic particle gun. Generate outgoing particle angles and energy according to user-defined limits. Vertex is generated according to usual prescription. Any valid GEANT4 particle type can be selected.
• pythia6: PYTHIA6.4 events. This generator actually does not call the ROOT-PYTHIA6.4 event generation interface directly. Instead, it reads primary events from a ROOT tree in a pre-defined format, documented below (see /g4sbs/pythia6file command). Any event generator that prepares events in this format can be used in g4sbs directly, without modifying the source code. An example macro that generates events in the format required by g4sbs using ROOT's built in interface to PYTHIA6 can be found in root_macros/Pythia6_minbias_gen.C.
• /g4sbs/pythia6file: Name of ROOT file containing events from PYTHIA6 (or other arbitrary event generators) in a predefined format.
• PYTHIA6 event format: The "pythia6" generator expects events in a ROOT tree with the following branch structure (see root_macros/Pythia6_minbias_gen.C and root_macros/Pythia6_tree.h for more details). Some of the branches and kinematic variables are specific to electron scattering, but the branches defining primary particles in the event are completely general.
• Int_t Nparticles: (type int) Total number of particles in the event. This is the size of the particle arrays.
• Float_t Q2: (type float) Four-momentum transfer squared or invariant mass squared of the virtual photon
• Float_t xbj: (type float) Bjorken x variable
• Float_t y : (type float) fractional energy lost by the scattered electron
• Float_t W2: (type float) Invariant mass squared of virtual photon-nucleon system.
• vector<int> *status: LUND status code of primary particles. "status==1" indicates final-state particles that will actually be generated. "status==21" indicates initial-state particles and "header" information in the event record. Other status codes indicate virtual and intermediate-state particles that have decayed.
• vector<int> *pid: LUND particle ID code. Particle numbers are according to the scheme documented by PDG.
• vector<int> *parent: index in the particle array of the parent of this particle (NOTE: the "parent" index starts at 1, with particle 1 always being the primary beam electron in the case of PYTHIA6 events. In C++ the array index starts with 0, so to access the parent particle one would use array index parent-1])
• vector<int> *fchild: Array index (starting at 1) of the first child particle of the current particle.
• vector<int> *lchild: Array index (starting at 1) of the last child particle of the current particle.
• vector<double> *px: x-component of particle three-momentum (in the same coordinate system as g4sbs). Units are GeV/c
• vector<double> *py: y-component of particle three-momentum (in the same coordinate system as g4sbs). Units are GeV/c
• vector<double> *pz: z-component of particle three-momentum (in the same coordinate system as g4sbs). Units are GeV/c
• vector<double> *vx: x-component of vertex where particle was produced (same coordinate system as g4sbs). Units are mm.
• vector<double> *vy: y-component of vertex where particle was produced (same coordinate system as g4sbs). Units are mm.
• vector<double> *vz: z-component of vertex where particle was produced (same coordinate system as g4sbs). Units are mm.
• vector<double> *E: Total energy of particle (in GeV).
• vector<double> *M: Invariant mass of particle (in GeV/c^2)
• vector<double> *theta: Polar angle of particle trajectory in radians
• vector<double> *phi: Azimuthal angle of particle trajectory in radians
• vector<double> *t: Time since start of event at which particle was produced, in lab frame, in units of mm/c.
• vector<double> *tau: Time since start of event at which particle was produced, in particle rest frame (i.e., proper time), in units of mm/c.
• /g4sbs/exp: Choose experiment configuration. This defines which detectors/magnets/target/etc. will be built. Expects string argument. Valid choices are:
• gep: GEP experiment. Geometries are:
• GEP-specific downstream beamline elements
• GEP electron arm:
• ECAL
• CDET.
• SBS magnet, pole shims, field clamps (optional), lead inserts (optional).
• HCAL: Remember to offset HCAL vertically by a 49.7 cm (see /g4sbs/hcalvoffset command), so that it is centered within the magnet acceptance for (upbending) elastically scattered protons.
• FPP: GEMs and CH$_2$ analyzers
• gmn: GMN experiment. Geometries are:
• GMN electron arm: BigBite with standard detector package
• GMN hadron arm: SBS magnet (no pole shims or field clamps), Default is HCAL vertically centered with respect to SBS magnet gap (change via /g4sbs/hcalvoffset command as necessary).
• gen: GEN experiment. Detector configuration same as GMN.
• a1n: A1n experiment. Detector configuration same as GMN (should it be? Actual experiment uses HRS).
• sidis: SIDIS experiment.
• SIDIS electron arm: BigBite with standard detector package.
• SIDIS hadron arm: SBS magnet without pole shims or field clamps. Default is HCAL vertically centered. Additional SBS trackers and RICH detector.
• /g4sbs/particle: Defines particle type for gun generator. Requires string argument. Any valid GEANT4 particle name is accepted. See Particles chapter in GEANT4 user's guide.
• /g4sbs/hadron: Choose hadron type for SIDIS and/or Wiser generators. Valid choices are:
• pi+: positive pion, valid for sidis, wiser
• pi-: negative pion, valid for sidis, wiser
• pi0: neutral pion, valid for sidis, wiser
• K+: positive kaon, valid for sidis (Wiser will generate but not calculate cross section)
• K-: negative kaon, valid for sidis (Wiser will generate but not calculate cross section)
• p: proton, valid for sidis (Wiser will generate but not calculate cross section)
• pbar: antiproton, valid for sidis (Wiser will generate but not calculate cross section)
• /g4sbs/48d48field: Expects integer argument. Turn on (1) or off (0) SBS uniform magnetic field.
• Turning ON (1) adds a uniform magnetic field located in the gap of the SBS magnet, and adds it to the "global field" object in G4SBSDetectorConstruction. If the "fUseGlobalField" flag of "G4SBSDetectorConstruction" is false, which is the case by default, the "fUseLocalField" flag is set for the "G4SBSHArmBuilder" class which defines the SBS geometry, which causes a local magnetic field to be associated with the air gap inside the SBS dipole magnet. Note: This command should never be used in combination with /g4sbs/tosfield below, as it will cause the uniform magnetic field to be added in superposition with the TOSCA field, approximately doubling or canceling the magnetic field in the gap, depending on the overall scale factors applied.. See "Setting up the magnetic field" below for a more detailed discussion of the way magnetic fields are handled.
• Turning OFF (0) deletes the uniform magnetic field from the global field if it exists, and sets the "local field" flag for "HArmBuilder" to false if and only if the "fUseGlobalField" flag of G4SBSDetectorConstruction is true, which prevents the uniform field from being created in "HArmBuilder"
• /g4sbs/bbfield: Expects integer argument. Turn on (1) or off (0) BigBite magnetic field. Requires BigBite field map file (see "setting up the magnetic field" below). Note: g4sbs currently requires map file to be named "map_696A.dat", as this file name is hard-coded.
• Turning ON (1) creates a new "G4SBSBigBiteField" object and adds it to the global field. If the "fUseGlobalField" flag of "G4SBSDetectorConstruction" is false, which is the case by default, the "fUseLocalField" flag is set for the "G4SBSEArmBuilder" class which defines the BigBite geometry. The bigbite magnetic field map is then assigned to the mother logical volume containing the BigBite magnet and detectors.
• Turning OFF (0) deletes the bigbite field from the global field object, and sets the "local field" flag for "EArmBuilder" to false iff the "global field" flag is set.
• /g4sbs/tosfield: Use global field from TOSCA field map file. Expects string argument equal to file name of map file. Requires SBS TOSCA field map file. See "setting up the magnetic field" below for more details. Note: invoking /g4sbs/tosfield is currently the only mechanism to set the "global field" flag to true. Invoking this command sets the "local field" flags for "EArmBuilder" and "HArmBuilder" to false.
• /g4sbs/shootgeantino: Expects a boolean argument. If true, shoot a geantino instead of an electron.
• /g4sbs/invertfield: Expects a boolean argument. If true, changes the sign of all global magnetic fields (also changes the sign of local magnetic fields).
• /g4sbs/totalabs: Expects boolean argument. If true, causes BigBite and SBS magnet materials to be total absorbers using G4UserLimits. Useful to speed up the simulation in applications such as acceptance and rate calculations. Default value is false.
• /g4sbs/targlen: Sets target length along beam direction. Requires a value and a unit.
• /g4sbs/targden: Sets target density. Requires a value and a unit. Note: the current behavior of the code is that this command has no effect, because the densities of target materials are hard-coded in G4SBSDetectorConstruction::ConstructMaterials()
• /g4sbs/targpres: Sets target pressure. Applies to gas targets. Requires a value and a unit. Note: the current behavior of the code is that this command has no effect, because the densities of target materials are hard-coded in G4SBSDetectorConstruction::ConstructMaterials().
• /g4sbs/beamcur: Beam current. Requires a value and a unit. Currently used in the normalization of events from a cross-section to an event rate.
• /g4sbs/runtime: Run duration Requires a value and a unit. Used to normalize events from cross section --> rate --> number of counts. Unit must be a valid time unit defined in G4SystemOfUnits.hh ("hour" "day" "year" do NOT work).
• /g4sbs/rasterx: Define horizontal raster size. Requires a value and a unit.
• /g4sbs/rastery: Define vertical raster size. Requires a value and a unit.
• /g4sbs/beamE: Define beam energy. Requires a value and a unit.
• /g4sbs/bbang: Define BigBite/electron arm angle (also applies to ECAL in the GEP configuration). Requires a value and a unit.
• /g4sbs/bbdist: Define BigBite/electron arm distance from target. Requires a value and a unit.
• In experiments using BigBite, this defines the distance from the target center (origin of global coordinates) to the front face of the magnet yoke.
• In the GEP experiment using ECAL, this defines the distance from the target center to the front of the lead-glass blocks of ECAL. The front of the lead-glass is therefore 40 cm closer to the target than the value defined using this command.
• /g4sbs/sbsang: Define SBS angle. Requires a value and a unit.
• /g4sbs/hcaldist: Distance from the target center to the front surface of HCAL. Requires value and unit.
• /g4sbs/hcalvoffset: Vertical displacement of the center of HCAL with respect to target vertical center. Requires value and unit.
• /g4sbs/48D48dist: Distance from target center to front face of SBS magnet yoke. Requires value and unit.
• /g4sbs/gemres: Set GEM coordinate resolution globally for all planes ($1\sigma$). Local x and y coordinates of hits in GEM detectors are subject to Gaussian smearing with this $\sigma$. Requires value and unit. Note: default value is $\sigma = 70 \mu$m
• /g4sbs/cerdist: Defines distance from front GEM of BigBite to entry window of BigBite Cherenkov. Requires value and unit. Note: default value is 7 cm
• /g4sbs/cerdepth: Defines depth of BigBite Cherenkov gas. Requires value and unit. Note: default value is 92 cm, defined by planned GRINCH depth.
• /g4sbs/gemsep: GEM separation from front to back set (for BigBite GEMs). Requires value and unit. Note: Default value is cerdepth + 10 cm. This is the z distance between the midpoints of the two sets of GEMs (before and after GRINCH). GEM planes within each set are separated by 5 cm in z.
• /g4sbs/bbcaldist: Distance from BigBite front GEM to BigBite calorimeter surface (preshower). Requires value and unit. Note: Default value is 20 cm + cerdepth.
• /g4sbs/thmin: Minimum polar angle for electron generation. Requires value and unit.
• /g4sbs/thmax: Maximum polar angle for electron generation. Requires value and unit.
• For all generators with scattered electrons (elastic, inelastic, flat, dis, sidis), thmin and thmax refer to the electron polar angle generation. For the beam and wiser generators, these are ignored. For the gun generator, thmin and thmax refer to the polar angles of the generated particle, regardless of type.
• /g4sbs/phmin: Minimum azimuthal angle for electron generation. Requires value and unit.
• /g4sbs/phmax: Maximum azimuthal angle for electron generation. Requires value and unit.
• For all generators with scattered electrons (elastic, inelastic, flat, dis, sidis), phmin and phmax refer to the electron azimuthal angle generation. For the beam and wiser generators, these are ignored. For the gun generator, phmin and phmax refer to the azimuthal angles of the generated particle, regardless of type.
• /g4sbs/hthmin: Minimum hadron generation polar angle. Requires value and unit.
• /g4sbs/hthmax: Maximum hadron generation polar angle. Requires value and unit.
• /g4sbs/hphmin: Minimum hadron generation azimuthal angle. Requires value and unit.
• /g4sbs/hphmax: Maximum hadron generation azimuthal angle. Requires value and unit.
• Note: hadron angle generation limits apply only to the sidis and wiser generators, and are otherwise ignored.
• /g4sbs/ehmin: Minimum generated hadron energy. Requires value and unit.
• /g4sbs/ehmax: Maximum generated hadron energy. Requires value and unit.
• Note: hadron energy generation limits apply only to the sidis and wiser generators, and are otherwise ignored.
• /g4sbs/eemin: Minimum generated electron energy. Requires value and unit.
• /g4sbs/eemax: Maximum generated electron energy. Requires value and unit.
• Note: "electron" energy generation limits apply only to the sidis and gun generators, and are otherwise ignored. When used with the gun generator, these limits refer to the energy of the generated particle, regardless of particle ID.
• Note: For now, the energy generation limits for both hadrons and electrons refer to the total energy of particles, not their kinetic energy. Therefore, the minimum generated energy must be greater than the mass of the particle type being generated. Perhaps this should be changed to refer to the particle kinetic energy.
• /g4sbs/richdist: Distance from the target center to the RICH entry window. Requires value and unit.
• /g4sbs/sbsmagfield: Defines SBS uniform magnetic field value. Requires value and unit. Can be positive or negative. Should be invoked before /g4sbs/48d48field.
• /g4sbs/sbsclampopt: Flag controlling SBS field clamp geometry. Expects integer argument. Valid choices are:
• 0: No field clamps for SBS.
• 1: Field clamps for BigBite experiments (default). Note: The geometry represented by this option is obsolete and does not reflect any current or planned experiment design.
• 2: Field clamps for GEP experiment. Note: The geometry represented by this option is based on the final field clamp design for the GEP (and GMN??) experiments.
• /g4sbs/uselead: Flag controlling lead shielding of the beamline and SBS. Expects integer argument. Valid choices are
• 0: no extra lead shielding on downstream beamline or in front of SBS apertures.
• 1: Yes--builds lead shielding of the downstream beamline and/or SBS apertures. Geometry is experiment-dependent.
• /g4sbs/treeflag: Flag controlling filling of the ROOT tree. Requires integer argument. Valid choices are:
• 0: Keep all events, regardless of detector status. This option is very expensive disk-wise for beam background simulations in which the vast majority of events have no hits in sensitive volumes.
• 1 (recommended in most cases): Keep only events with hits in sensitive volumes.
• /g4sbs/keepcalparticles: Flag to keep calorimeter-specific particle information in the ROOT tree for sensitive volumes defined with "calorimeter" sensitivity. Requires string and boolean arguments.
• The first argument is a sensitive detector name. If this argument does not correspond to the name of a sensitive detector with "calorimeter" sensitivity type, then the command has no effect.
• The second argument is a boolean. If true, calorimeter-specific particle history information will be kept (see ROOT tree documentation below). Defaults to false.
• /g4sbs/keephistory: Flag to keep generic particle history information in the ROOT tree for sensitive volumes with arbitrary sensitivity. See ROOT tree documentation below for details). Requires string and boolean arguments.
• The first argument is a sensitive detector name. If this argument does not correspond to the name of a sensitive detector that exists in the simulation, the command has no effect.
• The second argument is a boolean, which if true, causes the ROOT tree branches containing the generic particle history info to be created and also causes this information to be written to the ROOT tree for each event. Defaults to false.
• /g4sbs/steplimit: Flag to limit step length to zero for particles entering a given sensitive volume. Makes detectors effectively total absorbers that kill particles entering them and record their information using the calorimeter "hit" classes. This command is only implemented for a subset of sensitive detectors defined in the simulation, limited to calorimeters and/or scintillation detectors that produce large numbers of secondaries. Useful for heavy, showering detectors to speed up the simulation when full details of the response aren't needed. Requires string and (optional) boolean arguments:
• The first argument must be either the name of an existing sensitive detector in the list of implemented detectors OR the name of a mother volume enclosing such detectors. The current list of sensitive detectors for which this option is implemented:
• Harm/HCalScint: Scintillator plates of HCAL. Turning on the step limiter prevents production of large number of optical photons which then have to be tracked.
• lHCalo: Mother box entirely containing HCAL. Step-limiting this volume makes HCAL a total absorber with "calorimeter" sensitivity (sensitive detector name = "Harm/HCAL_box") that kills and records all particles entering it.
• bbcal_mother_log: Mother box entirely containing the BigBite shower, preshower and timing hodoscope. Step-limiting this volume makes the BigBite calorimeter a total absorber with "calorimeter" sensitivity (sensitive detector name = "Earm/BBCal").
• Earm/BBSHTF1: Lead-glass of the BigBite calorimeter (shower layer)
• Earm/BBPSTF1: Lead-glass of the BigBite calorimeter (pre-shower layer)
• earm_mother_log: Mother volume containing ECAL and CDET (only applicable in GEP). Makes "earm_mother_log" a sensitive "calorimeter" volume with sensitive detector name = "Earm/ECAL_box".
• The second (optional) argument is boolean (true/false) to toggle this option for a given volume. If the volume name is not in the list of supported detectors above, the command has no effect
• /g4sbs/useckov: Toggle optical photon production via the Cerenkov process on/off in G4SBSPhysicsList (and therefore for the entire setup). Takes one (optional) boolean argument. The Cerenkov process is ON by default for all detectors with a refractive index defined in their material properties tables. Note: Must be invoked in the pre-initialization phase (see below) to have an effect
• /g4sbs/usescint: Toggle optical photon production via the Scintillation process on/off in G4SBSPhysicsList (and therefore for the entire setup). Takes one (optional) boolean argument. The Scintillation process is ON by default for all detectors with scintillation properties correctly defined in their material properties tables. Note: Must be invoked in the pre-initialization phase (see below) to have an effect

### "Pre-init" vs "Post-init" commands

Most g4sbs commands can be invoked pre-initialization or post-initialization, with several exceptions:

• /g4sbs/usescint and /g4sbs/useckov must be invoked in the pre-initialization phase to have any effect. These commands may cause g4sbs to crash if invoked post-initialization.
• /g4sbs/run can only be invoked in the post-initialization phase. May cause g4sbs to crash if invoked pre-initialization.

When running g4sbs in interactive mode, G4RunManager::Initialize() is invoked before passing control of the program to the user interface. Therefore all commands executed in an interactive g4sbs session are post-initialization commands. This means that it is presently not possible to disable Cherenkov and Scintillation processes in interactive sessions, which is undesirable. A fix that allows these processes to be toggled in interactive mode is in the works.

### Setting up the magnetic field

This section describes proper procedures and command sequences to achieve the desired results when configuring the magnetic field in g4sbs. The magnetic field description in g4sbs is somewhat complicated by the need to optimize the program for speed. As detailed here, defining a global magnetic field when only small regions of the setup have significant magnetic field makes the tracking unnecessarily expensive, because tracking in a magnetic field costs the same number of CPU cycles whether the field is large or zero. Therefore, g4sbs is designed to treat different situations differently.

Several points are useful to keep in mind in approaching the g4sbs magnetic field definition:

• TOSCA field maps for the SBS magnet are not portable from one experiment configuration to the next; i.e., the TOSCA field map does not translate with the SBS magnet in angle or distance. This is because each experiment configuration involves a separate layout of active and passive magnetic shielding on the downstream beamline to protect the beam from the stray field of the SBS magnet, and these shielding elements do not translate/rotate with the magnet. Therefore, a separate field map is required for each configuration.
• The physical region covered by the typical SBS TOSCA map is too large to easily implement as a local field, because it wholly or partially overlaps too many other logical volumes at the same level of the geometry hierarchy. Therefore, the use of SBS TOSCA maps necessitates the use of a global magnetic field.
• The standard BigBite field map (http://hallaweb.jlab.org/12GeV/SuperBigBite/downloads/map_696A.dat), on the other hand, encompasses a small enough physical region that it can be confined to a logical volume enclosing the BigBite magnet and detectors without interfering with other logical volumes at the same level of the volume hierarchy. Therefore, it is possible to use the BigBite field map both globally and locally.
• For configurations of SBS for which a final TOSCA map is not yet available, a reasonable first approximation is to use a uniform dipole field in the SBS magnet gap. This can be treated as a local field and combined with a local BigBite field.
• Presently, the only experiment configuration with a more-or-less final TOSCA map available that can be used with g4sbs is the 12 GeV$^2$ setting of the GEP experiment, with SBS at 16.9 degrees and 1.6 meters from the target.

#### Command sequences for typical magnetic field permutations

• BigBite only:
• /g4sbs/bbfield 1
• /g4sbs/48d48field 0 (optional since SBS uniform field is OFF by default).
• BigBite and SBS uniform field with a magnitude of 1.8 T:
• /g4sbs/bbfield 1
• /g4sbs/sbsmagfield 1.8 tesla Note: it is recommended, but not strictly required, to set the field value before turning on the SBS uniform field. The only ill effect of setting the field value after turning it on is that the diagnostic plots written to the root file will show the default field value of 1.4 T instead of the user's choice. The actual field used in the simulation will always be overridden by "/g4sbs/sbsmagfield"
• /g4sbs/48d48field 1
• SBS TOSCA field only:
• SBS TOSCA field and BigBite field (Note: To the extent that the BigBite and TOSCA field maps overlap in any region of the global coordinate space, the superposition principle is applied and the two fields as interpolated from the two maps will be vector-added at any point in the overlap region):
• /g4sbs/bbfield 1

Any time "/g4sbs/tosfield" is invoked, g4sbs is forced to use a global magnetic field definition. In all other cases, the code is written so that local fields are used for SBS and BigBite, which makes the simulation noticeably faster.

#### Links to field map files

BigBite field map. TOSCA map for GEP $Q^2 = 12$ GeV$^2$

 wget http://hallaweb.jlab.org/12GeV/SuperBigBite/downloads/map_696A.dat (for the BigBite field map) wget http://hallaweb.jlab.org/12GeV/SuperBigBite/downloads/GEP_12map0_newheader.table (TOSCA map for GEP 12 GeV$^2$ configuration)

The BigBite field map must be located in the same directory as the g4sbs executable and have the name "map_696A.dat" to work correctly. This is because the file name is hard-coded.

New header format for SBS TOSCA map:

In the uconn_dev branch of g4sbs, the code that reads the TOSCA map file is modified to expect three rotation angles to be read in from the header, interpreted as $\alpha_x, \alpha_y, \alpha_z$. The rotation matrix for the magnetic field is then defined by applying these three rotations in the order xyz; i.e.,

• First, rotate the field by $\alpha_x$ about the original x axis. Positive angles are defined as clockwise rotations as viewed from the +x direction (in other words, if I am sitting at $x = +\infty$ and looking in the -x direction, a positive $\alpha_x$ corresponds to a clockwise rotation.
• Second, rotate the field by $\alpha_y$ about the new y axis.
• Third, rotate the field by $\alpha_z$ about the new z axis.

The new header format means that the code in uconn_dev cannot read the TOSCA maps with the old header format that only has one rotation angle. The only TOSCA map file at http://hallaweb.jlab.org/12GeV/SuperBigBite/downloads/ that is presently compatible with uconn_dev is GEP_12map0_newheader.table.

#### Notes on field maps

The SBS TOSCA map for the GEP 12 GeV$^2$ configuration uses trilinear interpolation of a uniform rectangular grid with a lattice spacing of 2.5 cm defined at 161 z points from $-200\ cm \le z \le 200\ cm$, and 121 x/y points from $-150\ cm \le x,y \le 150\ cm$. The +z axis of the SBS TOSCA map is opposite the direction of particle motion, and the origin of the field map is located at a distance of 221 cm from the target along the line making an angle of 16.9 degrees to beam right with respect to the beam direction.

The BigBite field map also uses trilinear interpolation on a 2 cm grid with $(N_x, N_y, N_z)=(26, 96, 116)$, with $(\Delta x, \Delta y, \Delta z)=(\pm 25\ cm, \pm 75\ cm, \pm 160\ cm)$. The BigBite field map has a "natural" orientation with the +z axis in the direction of particle motion, and its origin is always at a fixed position relative to the "mother" logical volume containing the BigBite magnet and detectors. Unlike the SBS TOSCA map, the BigBite field map is "portable" and moves with the BigBite spectrometer.

## Output ROOT file structure

The output of g4sbs is a ROOT file containing metadata about the run, diagnostic plots of the magnetic field layout in Hall A, and a ROOT tree with the data from simulated events, including global event properties and data from individual detectors.

The run metadata is stored in an object of class "G4SBSRunData" which inherits from ROOT's "TObject". The object is always written to the file with the key/name "run_data". The information stored in this object includes:

• git repository info: This includes the commit identifier (source code version) and commit message, as well as change tracking information.
• Geant4 version; version of the GEANT4 toolkit against which g4sbs was built
• ROOT version; version of the ROOT libraries against which g4sbs was built
• cmake version: version of cmake used to build g4sbs
• Time stamp: includes the date and time of the simulation run and the name of the host machine on which the simulation was executed.
• Directory in which g4sbs was executed on the host machine
• N generated: Number of events generated: This is the actual number of primary events generated.
• N tried: Number of events "tried". This is the number of "attempted" event generations. For most of the event generators in g4sbs, N tried = N generated. In all cases, the simulated yield should be normalized to "N tried" to get the correct event rate, since the generated phase space volume includes kinematically forbidden regions of phase space. Here is the behavior for each currently available generator:
• elastic: N tried = N generated
• inelastic: Returns false if generated event not kinematically allowed. Ntried >= Ngenerated.
• flat: N tried = N generated
• dis: Returns false if generated event not kinematically allowed. Ntried >= Ngenerated.
• beam: Always generates an event. Ntried = Ngenerated
• sidis: Returns false if generated event not kinematically allowed. Ntried >= Ngenerated.
• wiser: Always generates an event. Ntried = Ngenerated
• gun: Always generates an event. Ntried = Ngenerated
• pythia6: Always generates an event. Ntried = Ngenerated
• Experiment: Experiment type. Corresponds to valid experiment types chosen via /g4sbs/exp command.
• Generator: Event generator type. Corresponds to one of the valid event generators chosen via /g4sbs/kine command.
• Field maps: information about TOSCA field map file(s) used by the simulation (if any)
• Pre-Init Macro run: Contents of macro file containing commands executed prior to initialization (if any).
• Macro run: Contents of macro file containing commands executed after initialization (if any).
• External macros called: Contents of external macro files invoked by either of the pre-/post-initialization macros.

### Diagnostic Magnetic Field Plots

All of the magnetic field plots are two-dimensional histograms showing the projection onto the xz plane at y = 0 in the global coordinate system of the individual field components and the field magnitude:

• field_x (type TH2F): x-component of the magnetic field (Tesla).
• field_y (type TH2F): y-component of the magnetic field (Tesla).
• field_z (type TH2F): z-component of the magnetic field (Tesla).
• field (type TH2F): total magnitude of the magnetic field (Tesla).

### ROOT Tree

The output ROOT Tree is the main result of the simulation, and contains global properties of each event as well as the individual detector responses.

• ev data structure (Note: count, rate, solid angle, sigma and other variables in this data structure have different definitions, meanings and/or units for each generator, and are NOT vetted or checked for correctness or meaningfulness across all generators. Interpret with care!). Contains global properties of the event:
• count/D: Projected event yield. Product of event rate and run duration. Event rate is determined by the product of the calculated differential cross section, the luminosity, and the phase space generation volume divided by the total number of generated events, while run duration is defined via /g4sbs/runtime.
• rate/D: Projected event rate in Hz. Product of differential cross section, luminosity and phase space generation volume, divided by total number of generated events.
• solang/D: phase space generation volume divided by number of generated events.
• sigma/D: differential cross section in $\frac{d\sigma}{d\Omega_e}$ in cm$^2$/sr.
• For DIS and inelastic generators, the cross sections are actually $\Delta E'_e \frac{d^2\sigma}{d\Omega_e dE'_e}$, where $\Delta E'_e$ is the energy interval for generation of the scattered electron's energy.
• For the SIDIS generator, sigma is actually $\frac{d\sigma}{d\Omega_e d\Omega_h dE'_e dE'_h}$ in units of $\frac{cm^2}{GeV^2 \times sr^2}$
• W2/D: Invariant mass squared of virtual photon-nucleon system. Units are GeV$^2$
• xbj/D: Bjorken x variable according to standard definition.
• Q2/D: Invariant four-momentum transfer squared from electron to target, in GeV$^2$
• th/D: Polar angle of scattered electron (radians)
• ph/D: azimuthal angle of scattered electron (radians)
• Aperp/D: Perpendicular asymmetry. Defined in the context of elastic or quasi-elastic electron nucleon scattering from a polarized target, this is the beam-target double-spin asymmetry for the component of the target polarization parallel to the electron scattering plane but perpendicular to the momentum transfer direction.
• Apar/D: Parallel asymmetry: Defined in the context of elastic or quasi-elastic electron nucleon scattering from a polarized target, this is the beam-target double-spin asymmetry for the component of the target polarization parallel to the electron scattering plane and parallel to the momentum transfer direction.
• Pt/D: Transverse component of transferred polarization. Only meaningful in the context of elastic or quasi-elastic ep or en scattering.
• Pl/D: Longitudinal component of transferred polarization. Only meaningful in the context of elastic or quasi-elastic ep or en scattering
• vx/D: x-coordinate of primary particle generation vertex in meters.
• vy/D: y-coordinate of primary particle generation vertex in meters.
• vz/D: z-coordinate of primary particle generation vertex in meters.
• ep/D: Initial momentum of generated primary final-state electron in GeV. For gun generator, this is the generated initial momentum of the primary particle, regardless of type.
• np/D: Initial momentum of generated primary final-state nucleon in GeV. For sidis and wiser generators, this is the initial momentum of the generated primary final-state hadron.
• epx/D: x-component of final-state electron momentum in GeV.
• epy/D: y-component of final-state electron momentum in GeV.
• epz/D: z-component of final-state electron momentum in GeV.
• npx/D: x-component of final-state nucleon/hadron momentum in GeV.
• npy/D: y-component of final-state nucleon/hadron momentum in GeV.
• npz/D: z-component of final-state nucleon/hadron momentum in GeV.
• pmperp/D: Missing perpendicular momentum in GeV (only meaningful in the context of quasi-elastic and/or inelastic generators)
• pmpar/D: Missing parallel momentum in GeV (only meaningful in the context of quasi-elastic and/or inelastic generators)
• pmparsm/D: "Smeared" missing parallel momentum in GeV, where the smearing is due to time-of-flight resolution (only meaningful in the context of quasi-elastic and/or inelastic event generators).
• z/D: Fraction of virtual photon energy carried by observed hadron. Only meaningful for SIDIS generator.
• phperp/D: Hadron transverse momentum in GeV. Only meaningful for SIDIS generator.
• phih/D: Azimuthal angle between hadron production plane and lepton scattering plane in radians. Defined according to the "Trento convention". Only meaningful for SIDIS generator.
• MX/D: Missing mass of unobserved final-state hadrons in GeV. Only meaningful for SIDIS generator.
• Sx/D: x-component of initial particle polarization in fixed SBS TRANSPORT coordinates. Only meaningful for particle gun generator.
• Sy/D: y-component of initial particle polarization in fixed SBS TRANSPORT coordinates. Only meaningful for particle gun generator.
• Sz/D: z-component of initial particle polarization in fixed SBS TRANSPORT coordinates. Only meaningful for particle gun generator.
• nucl/I: Initial (struck) nucleon type: 1 = proton, 0 = neutron. Meaningful for nuclear targets.
• fnucl/I: Final-state (detected) nucleon type: 1 = proton, 0 = neutron. Meaningful for nuclear targets.
• $\pm 1 = \pi^\pm$
• $0 = \pi^0$
• $\pm 2 = K^\pm$
• $+3 = p$
• $-3 = \bar{p}$
• earmaccept/I: flag indicating event passed acceptance criteria for detection in electron arm. Not currently implemented in a meaningful way across experiments/generators.
• harmaccept/I: flag indicating event passed acceptance criteria for detection in hadron arm. Not currently implemented in a meaningful way across experiments/generators.
• gen data structure: Contains some global experiment parameters on an event-by-event basis:
• thbb/D: Central angle of electron arm (BigBite or ECAL) in radians. Assumed to be on beam left.
• thsbs/D: Central angle of hadron arm (SBS) in radians. Assumed to be on beam right.
• dbb/D: Distance from target center to front surface of BigBite magnet yoke (GEn/GMn/SIDIS) or ECAL lead-glass (GEp), in meters.
• dsbs/D: Distance from target center to front surface of SBS magnet yoke, in meters.
• dhcal/D: Distance from target center to front surface of HCAL, in meters.
• voffhcal/D: Vertical offset of HCAL center relative to beamline, in meters.
• drich/D: Distance from target center to RICH entry window, in meters. Only applicable to "SIDIS" configuration.
• dsbstrkr/D: Distance from target center to SBS GEM tracker focal plane in meters. Only applicable to "SIDIS" configuration.
• Ebeam/D: Beam energy in GeV.

#### Sensitive Detector Data Structures

These are the experiment-dependent ROOT Tree branches that contain detector response information. There are presently four different sensitive detector "types" defined in g4sbs: "GEM" (kGEM), "Calorimeter" (kCAL), "RICH" (kRICH), and "ECAL" (kECAL). These sensitive detector types are distinguished by what kinds of information are stored in their "hit" classes and what information is written to the ROOT tree for each event. When the experiment geometry is constructed, logical volumes defined as sensitive detectors are grouped according to unique sensitive detector names, that are typically hard-coded in the geometry construction routines. Typically, the naming convention for sensitive detectors is chosen such that all unique physical placements of one or more logical volume(s) corresponding to a set of detectors that function as a single logical unit have the same unique sensitive detector name. An example is the SBS front tracker, which consists of six unique physical placements of a single logical volume representing one layer of GEMs. These six GEM layers function together as a single tracking unit in the code. Moreover, the naming scheme adopted in the code attaches the prefix "Earm/" or "Harm/" to sensitive detectors belonging to the electron arm (BigBite or ECAL) or hadron arm (SBS) of an experiment. The following is a list of sensitive detector names currently available in g4sbs with abbreviated descriptions of the purpose and relevant experiments in which they are used:

• Electron arm sensitive detectors:
• BigBite GEMs: (experiments = GEn, GMn, SIDIS)
• Earm/BBGEM (type kGEM): BigBite GEM-based tracking detectors. Records energy deposition and coordinates in primary ionization region of GEM modules.
• BigBite GRINCH: (experiments = GEn, GMn, SIDIS)
• Earm/GRINCH (type kRICH): BigBite Gas Ring-Imaging Cherenkov Detector (GRINCH) PMTs. Records number of photoelectrons.
• BigBite Calorimeter: (experiments = GEn, GMn, SIDIS)
• Earm/BBCal (type kCAL): BigBite calorimeter mother volume. Only active when /g4sbs/steplimit bbcal_mother_log 1 is invoked, which effectively turns a mother box enclosing the entire BigBite shower and preshower calorimeters (and timing hodoscope) into a total absorber of all particles that enter it, recording the properties of those particles at the time they enter the box.
• Earm/BBSHTF1 (type kCAL): BigBite shower calorimeter lead-glass. Records total energy deposition in lead-glass.
• Earm/BBSH (type kECAL): BigBite shower calorimeter PMTs. Records number of photoelectrons ejected by the PMT photocathode.
• Earm/BBPSTF1 (type kCAL): BigBite preshower calorimeter lead-glass. Records total energy deposition in lead-glass.
• Earm/BBPS (type kECAL): BigBite preshower calorimeter PMTs. Records number of photoelectrons ejected by the PMT photocathode.
• C16 Prototype: (experiments = C16)
• Earm/C16 (type kECAL): C16 PMTs. records number of photoelectrons.
• Earm/C16TF1 (type kCAL): C16 lead-glass. Records total energy deposition in lead-glass.
• ECAL/CDET: (experiment = GEP)
• Earm/ECAL_box (type kCAL): ECAL/CDet mother volume. Only active when /g4sbs/steplimit earm_mother_box 1 is invoked, which effectively turns a mother box enclosing the entire electron arm of the GEP experiment (including ECAL and CDet) into a total absorber which stops and records the properties of all incident particles.
• Earm/ECalTF1 (type kCAL): ECAL lead-glass. Records total energy deposition in lead-glass.
• Earm/ECAL (type kECAL): ECAL PMTs. records number of photoelectrons.
• Earm/CDET (type kECAL): Coordinate detector maPMTs. Records number of photoelectrons.
• Earm/CDET_Scint (type kCAL): Coordinate detector scintillator strips. Records energy deposition in scintillator strips of coordinate detector.
• HCAL (experiments = ALL):
• Harm/HCalScint (type kCAL): HCAL scintillator. Records energy deposition in HCAL scintillator tiles.
• Harm/HCal (type kECAL): HCAL PMTs. Records number of photoelectrons in HCAL PMT photocathodes.
• Harm/HCAL_box (type kCAL): mother box enclosing entire HCAL volume, only active when /g4sbs/steplimit lHCalo 1 is invoked, which turns the HCAL mother box into a total absorber that stops and records the properties of all entering particles.
• GEM trackers for GEP (experiment = GEP):
• Harm/FT (type kGEM): SBS front-tracker GEMs. Records energy deposition in primary ionization region and coordinates.
• Harm/FPP1 (type kGEM): SBS front polarimeter GEMs, located between first and second CH2 analyzers. Records energy deposition in primary ionization region and coordinates.
• Harm/FPP2 (type kGEM): SBS back polarimeter GEMs, located between second CH2 analyzer and HCAL. Records energy deposition in primary ionization region and coordinates.
• GEM tracker for SIDIS (experiment = SIDIS):
• Harm/SBSGEM (type = kGEM): large-area GEM-based tracker for SIDIS, based on UVA polarimeter GEM trackers, located in front of SBS RICH. Records energy deposition in primary ionization region and coordinates.
• RICH (experiments = SIDIS):
• Harm/RICH (type kRICH): RICH PMTs. Records number of photoelectrons.