PMT Simulation¶
RAT uses a custom PMT simulation extracted from GLG4Sim.
PMT Models¶
Various PMTs build types are stored in tables named PMT
and referenced by
their index which refer to a pmt_model
. RAT-PAC supports multiple build
types of PMTs which are placed in the geometry with the pmtarray
geometry
factory. The following build types are supported with the specified fields
Toroidal (GLG4TorusStack):
Field | Type | Description |
---|---|---|
construction |
string |
Must be “toroidal”. |
dynode_material |
string |
Material used for the dynode stack. |
glass_material |
string |
Material used for the PMT body. |
pmt_vacuum_material |
string |
Material used for the PMT vacuum. |
photocathode_surface |
string |
Surface containing photocathode properties. |
mirror_surface |
string |
Surface containing reflective back properties. |
dynode_surface |
string |
Surface containing dynode surface properties. |
dynode_radius |
double |
Radius of dynode. |
dynode_top |
double |
Top Z of dynode relative to PMT equator. |
wall_thickness |
double |
Thickness of the PMT body. |
z_edge |
double[] |
PMT shape argument to GLG4TorusStack. |
rho_edge |
double[] |
PMT shape argument to GLG4TorusStack. |
z_origin |
double[] |
PMT shape argument to GLG4TorusStack. |
Revolution (G4Polycone):
Field | Type | Description |
---|---|---|
construction |
string |
Must be “revolution”. |
dynode_material |
string |
Material used for the dynode stack. |
glass_material |
string |
Material used for the PMT body. |
pmt_vacuum_material |
string |
Material used for the PMT vacuum. |
photocathode_surface |
string |
Surface containing photocathode properties. |
mirror_surface |
string |
Surface containing reflective back properties. |
dynode_surface |
string |
Surface containing dynode surface properties. |
dynode_radius |
double |
Radius of dynode. |
dynode_top |
double |
Top Z of dynode relative to PMT equator. |
dynode_height |
double |
Total height of the dynode stack. |
rho_inner |
double[] |
Cylindrical radius of inner edge coordinates. |
z_inner |
double[] |
Z value of inner edge coordinates. |
rho_edge |
double[] |
Cylindrical radius of outer edge coordinates. |
z_edge |
double[] |
Z value of outer edge coordinates. |
PMTINFO
Tables:
These tables are used by pmtarray
to place PMT and the information contained
is passed along to Gsim. The order of items in this PMT array assigns IDs to the
PMTs, though the order of placement determines the order in which various
PMTINFO
tables are assigned indexes when using multiple pmtarray
elements.
Positions given in these tables are in global coordinates. If the PMTs are placed
in sub volumes the appropriate transformations are made on the fly.
Field | Type | Description |
---|---|---|
x |
double[] |
List of X positions in global coordinates. |
y |
double[] |
List of Y positions in global coordinates. |
z |
double[] |
List of Z positions in global coordinates. |
dir_x |
double[] |
List of X direction vector (will be normalized). |
dir_y |
double[] |
List of Y direction vector (will be normalized). |
dir_z |
double[] |
List of Z direction vector (will be normalized). |
type |
int[] |
List of logical PMT types (stored in DB). |
efficiency |
double[] |
List of individul PMT efficiency corrections (optional). |
Q/T Response¶
Gsim checks the database for single photoelectron charge and transit time PDFs
automatically for PMT models that are added to the geometry. These PDFs are
stored in tables named PMTCHARGE
and PMTTRANSIT
respectively, where the
index corresponds to a pmt_model
field used in GEO
tables. These PDFs
are sampled whenever a photon is absorbed by the photocathode to create a
realistic Q/T response automatically for PMTs independent of any DAQ processor.
If no tables are defined for a pmt_model
the time defaults to approximately
zero spread from photoelectron absorption time and the charge defaults to a
phenomenological model used by MiniCLEAN.
PMTCHARGE
fields:
Field | Type | Description |
---|---|---|
charge |
double[] |
“X” values of the charge PDF (arbitrary units) |
charge_prob |
double[] |
“Y” values of the charge PDF (will be normalized) |
PMTTRANSIT
fields:
Field | Type | Description |
---|---|---|
cable_delay |
double |
Constant offset applied to all PMTs of this model (nanoseconds) |
time |
double[] |
“X” values of the time PDF (nanoseconds) |
time_prob |
double[] |
“Y” values of the time PDF (will be normalized) |
Efficiency Model¶
Efficiency for detecting a photo electron before any DAQ process is applied is based on the following.
- PMT Geometry - reflections of the photons from the PMT and internal reflections.
- Photocathode QE - defined in the photocathode surface
OPTICS
table as theEFFICIENCY
property (wavelength dependent). - Placement Correction - each
pmtarray
GEO
placement has an (optional)efficiency_correction
muplicative factor that applies to all PMTs it palces. - Individual Correction - the (optional)
efficiency
field inPMTINFO
tables specifies an individual correction to each PMT (settable from macro).
Dark Current¶
PMTs have an intrinsic noise rate, or “dark current”, which results from thermal excitation at the single electron level. These thermal electrons can exactly mimic a photoelectron from the PMT’s photocathode and, thus, noise hits cannot be distinguished from ‘true’ hits caused by incident photons.
On the upside, this makes the noise hits fairly simple to simulate: we can draw from the same charge spectrum as is used for regular PMT hits. The only subtleties are in the timing distribution of the hits, and the rates at which noise is generated. This document describes the inclusion of noise hits in RAT.
The old noise processor (source:rat/src/daq/NoiseProc.cc) had several problems with the implementation, in particular the hits were incorrectly distributed in time (generated for one sampling window width from the start of the simulated event, therefore not extending throughout the event window), and noise was defined in terms of a number of hits per event instead of a rate (which is what we are more likely to measure). In addition, under the principle of “apathy should lead to the most realistic simulation possible” (- Dr Stanley Seibert), it was decided to incorporate noise hits into the default event simulation, rather than retaining the optional processor. This avoids the possibility of noise not being included either through forgetfulness, or because the noise processor was run in the wrong order, for example after the DAQ processors. As a result, running RAT will now include PMT noise hits by default, unless they are switched off. Details on how to do so follow.
Control¶
There are three options for the inclusion of noise, as follows:
0: No noise hits simulated.
1: Average noise rate read from ‘noise_rate’ in DAQ.ratdb.
2: Tube-by-tube noise rates read from ‘PMTnoise’ in DAQ.ratdb.
These options are controlled by the use of the ‘noise_flag’, in the DAQ.ratdb file. This flag can be include’ in RAT macros as follows:
/rat/db/set DAQ noise_flag x
where x = 0, 1, or 2, depending on the noise model chosen.
The noise is included in the simulation after the physics event has been propagated (all particles followed to extinction, and PMT hits recorded) but before the DAQ, which runs as a separate processor. All noise hits are flagged with the ‘isNoise’ bit in the MCPhoton class (set to 1 for noise hits, and 0 for regular PMT hits).
Timing Distribution¶
Noise hits are generated uniformly in time, throughout a pre-defined ‘noise window’. The DAQ records data beginning from a predefined time before a trigger. This time period (pretrigger time) is given by a fixed number (currently 1350) of sampling windows (4ns each). We want noise to be simulated throughout any recorded waveform. The noise window therefore begins at a time before the first photon hit given by this pretrigger time. To allow for a noise hit in coincidence with the last recorded photon to cause a trigger, the noise window continues until the width of the event window, plus the width of a single discriminator pulse, past the last photon hit time.
Speed and file size Comparison¶
To determine the effect of including noise in the default simulation, I generated 1000 isotropic 20keV electrons at the centre of the detector using each noise model. Both the average and the individual tube noise rates were set to 2000Hz, to emphasise any impact of including noise hits (default is 500Hz). The results, in terms of CPU usage (output file size), were as follows:
Noise model 0: 2280.91 s (46M)
Noise model 1: 2285.77 s (48M)
Noise model 2: 2341.45 s (48M)
So including noise in the simulation increases the processing time by 0.2%, and simulating noise tube-by-tube increases it by a further 2.4%.
The file size increased by ~5% when noise was included in the simulation.
Parameters¶
All are stored in DAQ.ratdb
noise_rate: 500.0d, // The mean noise rate across all PMTs, in Hz
PMTnoise: [], // an array with 92 entries: individual noise rates per PMT, in Hz
noise_flag: 0, // the flag to determine which noise model you use (default is to turn noise off completely)