Monte Carlo Data Acquisition

The subroutine MCDAQ performs the `Monte Carlo Data Acquisition'. After an event has been simulated a very large amount of information exists in the ZEBRA banks concerning the history of the event. The purpose of MCDAQ is to extract only that information which would be available in a real event (the times, amplitudes, and numbers of the hit PMTs) and load it into ZEBRA banks whose format can be duplicated for the real data coming from the detector. The fitters then act on these banks, and is thus blind as to whether it is fitting a Monte Carlo event or a real event.

To simulate the electronics as closely as possible, MCDAQ calls four separate routines: MCGROUP, MC_XTALK, MCQANDT, and MCTRIG. MCGROUP performs the task of adding noise tubes to an event. There are subtleties connected with the PMT noise. First, there is no point in analyzing events which will yield no triggers, so the code can be made faster by applying the hardware hit threshold as early as possible. However, it is always possible for an event to have enough noise hits in the trigger window to get it over threshold. As a compromise a first-cut threshold CTHRESH is applied as the first step inc MCDAQ. Events which have fewer than CTHRESH total hits before noise is added are discarded by a call to ZTELL. CTHRESH should be set well below the desired hardware threshold to allow for noise. In the current version an added capability is that if CTHRESH is set less than zero, MCDAQ simulates pure noise triggers. The only subtlety is that if CTHRESH = 0 and a 0 hit event occurs the code crashes. This would correspond to a pure noise trigger being added to the other events being generated, but as there is no obvious time to add it which would be correct for all cases, this is not currently supported.

Since the PMT noise will occur within the detector at $\approx$khz rates, simulating each noise hit which might occur over the $\approx$100 ms which a neutron event might take would be wasteful, and over the few seconds that a spallation event might take would be ridiculous. The routine first separates the hits actually generated within the event into groups separated by more than the width of the trigger window. These groups are a calculational tool, they don't correspond to the actual detector triggers. A group may contain many (or no) triggers, but a trigger cannot extend between groups, thus they select out blocks of time which are of interest and where noise must be added. The routine then adds noise hits (with a call to MCNOIS) on random tubes at random times distributed between an input offset before the first hit in the group and a different input offset after the last hit in the group. The generation of charge for the noise tubes is done in the same manner as for real tubes, though a call to PMT_CHARGE in MCNOIS.

Once the noise has been added, MCDAQ calls MC_XTALK to add crosstalk, as described in 13.5.5 and then MCQANDT, which takes the PMT hits in the MCPM banks and combines hits on the same tube into single Q measurements if the hit occurs within the length of time that the integrator gate is open (that is, the width of the discriminator pulse). These multiple hits form a `cluster', and if a tube is hit by many photons distributed over a long period of time, it may have several clusters. In addition, MCQANDT applies a charge-correlated delay to each of the tube times, in order to simulate the realistic effects of discriminator walk.

Various changes were added to SNOMAN 2_08 to produce a more realistic simulation of the PMT charge and timing. For a more complete description see the document 'qtcalib.tex' in the report archive on the SNOGUEST account, what follows is a brief account. A table of the one pe PMT integral pulse height spectrum in arbitrary units is added to the "mc_generator.dat" file with the name SPEL. The first two numbers in the table are the slope and intercept required to change the arbitrary scale to units of pe. The file 'titles_spel.inc' is the include file which holds the ZEBRA pointers.

A call to the routine 'spe_charge.f' randomly generates a charge in units of pe. This routine is called from 'pmt_charge.f'. A call to pmt_charge is added to 'mcnois.f' to generate a charge for the noise pulses as well. The phenomenon of decreased discriminator delay time with increasing charge into the discriminator due to both the inherent characteristic of the discriminator and finite rise time of the analogue pulse is referred to as walk.

An inverse fifth order polynomial is used to parametrize this time shift as a function of the high gain short time charge in unit of PICO-COULOMBS. This time shift is calculated in "t_walk_correction.f". The parameters for the inverse polynomial are in the TITLES bank "q_t_calib.dat" with the name QTCA, where there is one line of calibration constants for each PMT. "q_t_calib.inc" is the include file holding the ZEBRA pointers.

t_walk_correction is called from mc_daq when MC events are generated and from cal_calibration_ini when analyzing data from the DAPM bank (MC or real data).

Also included on each PMT line in "q_t_calib.dat" is the gain for the PMT to convert the charge in units of pico-Coulombs to pe. The PMT transit time jitter is represented by a skewed Gaussian function whose parameters are in the file "mc_generator.dat" file the name TWOB. The file 'titles_t_wobble.inc' is the include file which holds the ZEBRA pointers.

Using the skewed Gaussian functional form ("t_wobble_fn.f") a table of the integral of this function is generated with a call to "gen_t_wobble_table.f" A call to the routine 'pmt_t_wobble.f' randomly generates a a transit time jitter from the integral table. This routine is called from 'pmt_charge.f'. A call to pmt_charge is added to 'mcnois.f' to generate a charge for the noise pulses as well.

After clustering hits and adding the discriminator walk, MCDAQ calls MCTRIG which looks through a time ordered list of the (now walked) phototube times. The trigger generation is a simulation of the analog sum actually used in the detector. MCTRIG steps through time in 0.25 ns increments, adding up the amplitudes of all the trigger pulses currently active.

As of SNOMAN 5.01, new simulation of the actions of the SNO discriminator and integrator is now available. The new code, residing primarily in MCDISCINT.FOR, replaces the older MCQANDT.FOR. In the previous SNOMAN versions, we have assumed that any PMT which has been `hit' according to the 3D or greydisk PMT simulations has necessarily a charge above threshold. The charges for each hit PMT were thus generated from threshold upward.

In the new code, each PMT hit has a charge generated for it which can be as low as zero. The charge is generated using SPE_SNO_CHARGE.FOR, and is drawn from a distribution which includes a scaling with the measured gain of each PMT. The generated charge is then compared to the PMT's threshold (drawn from the DQXX banks or a user-selectable threshold) and if it exceeds the threshold a hit is recorded and the PMT's charge and time are passed on to the trigger simulation along with all other PMT hits in the event. Noise is added to the charge before the discriminator threshold is checked, but it is assumed that this is high frequency noise which will integrate to zero. Additional smearing, representing the pedestal smearing, is added later in the data acquisition simulation in the routine MCFEC.FOR.

The apparently simple business of comparing the PMT charge to the discriminator's threshold becomes complex when we consider PMT's which are hit more than once. A PMT hit by two photons may trigger the discriminator even if each individual photon produces a charge which is below threshold. In the past, this case was handled incorrectly, as each photon was treated independently of every other photon.

Figure 13.2: Approach and timing in the threshold simulation taken in the new code. As shown in the top row of this diagram, the first hit is below threshold, and the threshold crossing only occurs when two hits (hits 2 and 3) combine to exceed the discriminator threshold. The time of the threshold crossing is the time of the leading edge of the 3rd hit. The integration gates open up $\sim$8 ns in the past (the PMT pulses themselves are actually delayed on their way to the integrator), and so hits 2 and 3 are both included in the total charge, but hit 1 is too early to be included. Hit number 4 is included in the short integration time (t_short or SAMPLE), and hit number five is included along with hits 2,3, and 4 in the long integration time (t_long or RESET). After a time t_wait (which is roughly the RESET time) the discriminator can fire again, and in this example it does on the 6th hit.

Figure 13.2 illustrates the approach used in the new threshold simulation code. To handle these multiple photons, the new code steps through each photon hit on a given tube, summing up the total charge accumulated on that PMT up to the current photon hit. A `timeout' period for the charge is enforced by treating each hit a square pulse whose height is equal to the charge from that hit and whose width is 7 ns, roughly the full width at half-maximum of the SNO PMT pulses. A more complete simulation would include the shape of the pulse, but that is probably an unnecessary complication.

If the sum of all the overlapping charges exceeds the PMT's threshold, a tube hit is then recorded. The time of the hit is set equal to the time of the most recent pulse contributing to the sum--there is no averaging of PMT times done. To ensure that all the hits contributing to a given sum are included in the tube's total charge, the gate (simulating the discriminator's RESET timing) begins 8 ns in the past. The gate extends the nominal RESET time ($\sim 400$ ns) into the future, but as yet the variations in the RESET time from channel-to-channel are not simulated. The simulation of the integrator's long and short integration times is done as in the past, simply by checking the time of each hit agains the two time scales and accumulating the total charge in the corresponding array (long or short integration time arrays).

After the gate closes, the code continues to loop through hits on the same PMT, to see if there are any other discriminator firings which need to be recorded. A multiple firing can happen, for example, in an antineutrino event when the initial positron produces a photon which hits a tube and then the subsequent neutron capture also hits the same tube many ms later.

During initialization of either the Monte Carlo simulation (in INDAQ.FOR) or the CAL processor (in CAL_CALIBRATION_INI.FOR) the efficiencies for each channel and the overall average are calculated. The way this is done is that charge spectrum for each tube for that run (that is, including the most recent gain measurements) is integrated from threshold up and divided by the integral over the whole range of the spectrum. To include the effects of noise, the spectrum is convolved with the noise fluctuations before being integrated. The resulting channel efficiencies is stored in an array (CHANEFF) kept in the sno_charge_com.inc common block, which can be accessed by energy estimators. CHANEFF is indexed by PMT number.

In order to ensure that the number of detected noise hits in the simulation agrees with data, the noise rate must be increased by (1./average channel efficiency). This is done in MCNOIS.FOR, by explicitly increasing the average number of noise hits in each event. The global noise rate is not changed.

The new threshold and charge spectrum simulation supports four modes, which can be set by changing a flag in word 32 of the MCDQ bank:

• Mode 0: Old (Frati) charge spectrum and threshold simulation. This is what was used pre-SNOMAN 5.0, and forces a tube's charge to be above threshold.
• Mode 1: New charge spectrum, but old (Frati) threshold simulation. This is what is currently being run in the D$_2$O re-processing.
• Mode 2: New charge spectrum and threshold simulation. In this mode, the PMT collection efficiency is re-normalized so that the overall energy scale is unchanged. In this case, therefore, the detector's average energy scale will not drift with changes in tube gain or threshold.
• Mode 3: New charge spectrum and new threshold simulation. In this mode, no renormalization of the PMT collection efficiency is done. Note that to use this mode, the PMT collection efficiency must have been measured with the threshold efficiencies turned on in the simulation and the energy estimation. Otherwise the overall energy scale will be $\sim$80% lower, due to the effects of the threshold cuts.

Note that during data processing, the channel efficiencies are always calculated, and they are always done assuming that real PCA gains and DQXX thresholds are desired.

With SNOMAN 5.0, MCTRIG has been re-written so that now the various functions performed by different pieces of hardware (the analog trigger sum, the MTC/D trigger decision and latching, and the Front End Card data storage) are now all in separate routines. The modularity allows us to now simulate many different trigger types, including both N100 and N20, ESUM, PRESCALE, EXT, and PULSE_GT. The notable exceptions are the OWL triggers, because SNOMAN does not simulated the OWL tubes. Overall, the new trigger simulation more directly mimics the actual hardware than the previous version.

The routine MCTRIG.FOR is still the main routine in the simulation, and it still includes the loop over PMT hit times which is used to create the simulated analog sums. Now, however, in the loop one or more analog sums can be created during the loop. Each of the analog sum routines act much like the MTC/A hardware--the N100 summing routine, for example, which produces the analog sums for the NHIT100 signal has three thresholds corresponding to NHIT100LO, NHIT100MED, and NHIT100HI. The one exception to this is that the ESUMLO signal, which in the detector has its own MTC/A, is treated in the code in just one routine (MCTR_SUM.FOR).

Each of the analog summing routines creates a sum from a particular shape--a NHIT-shaped pulse for the NHITS (100 and 20) and a gaussian shaped pulse for ESUM. It then checks the height of these sums against user-defined thresholds, and if they exceed the threshold a bit is set in the trigger word (just as it is in the actual trigger logic). In addition to the analog summing routines, there are `digital' triggers, the PRESCALE trigger and the PULSE_GT trigger. The PULSE_GT cannot be run independently of the other triggers (yet) but rather will fire if during the event a PULSE_GT trigger fires--in other word, pile-up of PULSE_GT and other events is now simulated. PRESCALE counts the number of NHIT100LO triggers, and the PRESCALE fraction can be user-selected. An EXT trigger is also simulated, and is checked during the PMT loop to determine whether the EXT time has passed (this is a more natural way of handing EXT than in previous MCTRIG incarnations).

After each of these routines has been called, MCTRIG.FOR then checks the trigger word against a user-defined trigger mask, to see if any of the bits corresponding to triggers of interest have been set.

If there is valid trigger, the Global Trigger is not immediately sent out, but the loop over time continues for roughly 10 ns, which is the latching time of the real MTC/D (note that this number needs to be remeasured to make the simulation more accurate).

Once the 10 ns latching time has passed, allowing any other triggers which are in coincidence with the initial trigger to fire, the flow passes to a simulation of the MTC/D (MCMTCD.FOR). MCMTCD.FOR latches the global trigger, stores the trigger word, trigger times (10 MHz and 50 MHz), error flags, and simulated AMB data. Note that the one feature which is no longer in the trigger code is the interpolation of the trigger time to determine the exact time of threshold crossing. This is not easy to do now because we do not know which of the analog sums caused the trigger, though perhaps in a future version this problem will be solved.

Once MCMTCD.FOR is finished, the flow goes to MCFEC.FOR which simulates the storage of the PMT times relative to the common-stop arrival of the Global Trigger. After MCFEC.FOR, control returns to MCTRIG.FOR, and the loop continues, jumping a LOCKOUT ( 440 ns) period forward in time to look for any other triggers in the event.

Control of the simulation is done through words in mc_daq.dat. The user can set the trigger mask, all the trigger thresholds, as well as some of the parameters controling the shapes of the analog pulses (note that the control of the `reality' of the simulation itself is still done in the same way as in previous SNOMAN versions). In addition to these parameters, individual triggers can be disabled using a mask similar to the trigger mask. The hardware analog of this disabling is the pulling of one or more of the MTC/A cables.

MCTRIG supports five simulation modes:

• Perfect Trigger--In this mode, the pulses in the simulated analog sum are perfect, unit-sized pulses, and therefore the trigger efficiency itself is perfect. This is the fastest way of running MCTRIG and, for MC studies far away from threshold, is no different than the other modes.

• Simulated Trigger--In this mode, the pulses have finite rise and fall times, as well as individual variations in amplitude. In addition, variations in the baseline are modeled as being caused by CMOS dropout and simple baseline drift. For the CMOS dropout, the user specifies (in mc_daq.dat) the Poisson average of the number of dropout channels and the RMS of the baseline drift (modelled as a Gaussian drift). The rise and fall parameters as well as the degree of amplitude differences pulse-to-pulse are also specified in mc_daq.dat.

• Simulated Trigger with Dead Channels--This differs from the previous mode only in that dead trigger channels are taken into account, by giving those channels a trigger pulse height of zero. The dead channels are gotten out of the DQCH bank (which must be valid and available to run in this mode). As the code currently stands, this does not accurately represent the effects of the dead trigger channels, since the Monte Carlo does not include dead channel information in the upstream parts of MCDAQ. In other words, MCTRIG turns off all channels whose NHIT triggers are disabled according to the DQCH banks, but most of these are because the channels themselves are dead. Dead channels do not affect the trigger efficiency (they affect the overall detector response), only active channels with dead trigger pulses. So this will degrade the efficiency in the Monte Carlo relative to reality until the Monte Carlo learns how to turn off the channels in the part of the code which generates tube hits.

• Measured Trigger Efficiency--Here MCTRIG generates triggers based on the measured trigger effiency curve, obtained from the TREF bank which resides in trigger_efficiency.dat. In this case, the trigger generation starts out with perfect trigger pulses, and every time an additional tube is added to the analog sum, MCTRIG finds the probability of the trigger firing based on the measured curves and throws a random number to see if the Monte Carlo should generate a trigger. In this way, events which have fewer hits than the nominal threshold can trigger the detector (because the real efficiency is nonzero below threshold) and events above the nominal threshold may miss (because the trigger just above threshold is not 100% efficient). There is one subtlety involved, which is that the measured trigger efficiency curves are necessarily cumulative curves--in other words, the efficiency is measured as a function of the maximum in-time NHIT. We therefore don't know if, for example, 30% of the time that the trigger fires when the maximum in-time NHIT is 18 it actually fired on the 17th hit. Since the Monte Carlo does not know a priori what the maximum in-time NHIT will be (it sums the trigger pulses as a function of time), it must adjust the probabilities in the TREF bank whenever it checks the sum against threshold and misses. The alternative, in which the maximum NHIT was determined first and then compared to the efficiency curves, is not practical since in the Monte Carlo world many physical events can be part of the same Monte Carlo event and determining the maximum is not well-defined.

• Measured+Simulated Trigger Efficiency--This mode is only included if one wishes to study the effects of timing (which will jitter somewhat for the simulated rather than perfect pulses) in conjunction with the measured efficiency. It is not a reasonable representation of reality since it combines the inefficiencies of both methods, and it not recommended for most Monte Carlo running.

If MCTRIG finds that the summed signal exceeds the hardware threshold it creates a global trigger, which is latched by the 50MHz clock. The phase of the 50 MHz clock is retained from event to event so for Monte Carlo runs where the time of each event changes (like charged current and neutral current events) the trigger window will shift by up to 20 ns each event. For events generated at the same place and time, the window will remain fixed since the phase of the clock relative to the trigger creation will be the same for each event. The global trigger time includes the delay from each front end card to the master trigger card. For more detail on the way SNO records PMT times see A.1. MCTRIG also fills some of the trigger words, simulating, for example, the information from the Analog Measurement Board based on that board's measured parameters.

MCTRIG then creates an EV bank for the trigger, and then from the EV bank it hangs a linear chain of PMT banks with data words PN, PHL, PT, PLX, PHS, PT0, and PF. These are respectively, the number, charge (integrated over the longer time), unwalked time, charge (at lower gain), and charge (integrated over a shorter time) of the hit PMT's, the unwobbled time, and the hit type (the type of hit is not used in the fitter but is saved for later analysis). The charges are in units of photo-electrons, and the times are referenced to the global trigger time, including the delay from the master trigger card to the front end card. Tube times therefore run from 0 ns to 250 ns (the setting of the discriminator pulse width). If one has not activated the software units for data uncalibration, packing, calibration and unpacking, then analysis of tube times can be done from these `Px' words.

In addition to the Px words, MCTRIG lifts and fills `PIx' words PIN, PIHL, PIT, PILX, PIHS, and PIT0 which, for charge and time, have the same form as the Px words but hold tube times with the discriminator walk applied, and charges in units of pico-coulombs instead of photo-electrons. The values in the PIx words will be digitized and packed if the user requests. After packing, these wordss hold information that is an identical form to the data.

If no triggers are found, MCTRIG calls ZTELL to dump the event, as no further processing is necessary.