Analyses¶

For each of the corresponding measurements, an analysis script has been prepared. This page will go through the general procedure to run these scripts.

By default most of the scripts will take the most recent run with its given tag. Generally you can select the tag by giving an additional “-n <tag_num>”. You can find the tag numbers by looking at the individual D-Egg json files in: /home/icehap-daq/data/json/run_00XXX/DEgg*.json. These tag numbers should always be aligned (consistent) between the D-Eggs.

FAT CAT Database¶

The FAT CAT database is storage at Madison which can be viewed through a typical web browser. This functions both for archival purposes, as well as for remote members of IceCube to view FAT data and results. The FAT CAT database can be access from: https://hercules.icecube.wisc.edu/upgrade/fatcat/devices .

Each measurement has a corresponding json file which has information formatted specifically to be inserted into the database. These are typically produced by the analysis scripts (though the camera dark rate script produces them following the DAQ finish). The files are located in degg_measurements/analysis/database_jsons under the specific run.

Most of these measurements have a corresponding “goalpost” - information which indicates an acceptable boundry for the measured value. For example, the measured dark rate should be below 3 kHz, and all D-Egg dark rates are then checked if they “pass” or “fail”. Goalposts are configured in degg_measurements/analysis/goalposts.py.

Once all of the json files have been created (all analyses below have been run successfully) and the FAT is finished the data should be inserted into the database. As the copying procedure can take a good amount of time (several hours), it should be run in a screen session. The script to perform the upload lives in degg_measurements/analysis:

screen -r upload
python3 upload_json_and_data.py XXX >> run_XXX_upload.txt

where “XXX” is the run number you would like to upload, but without the zero-padding, i.e. run 00130 becomes 130. The “>>” pipes the output to a text file which can be reviewed later for any errors.

Camera Results¶

Camera results will be handled mainly by the SKKU/Utah team. This includes both the camera dark noise and camera pattern tests. The responsibility of the Chiba group is to make the data available by copying it. Data can be copied by running the script:

python3 /home/icehap-daq/software/camera_helper/camera_copy_data.py /path/to/data mode

where the path to data will often be /home/icehap-daq/data/fat_calibration/camera_darknoise/ or /home/icehap-daq/data/fat_calibration/camera_pattern/. Mode should be either ‘darknoise’ or ‘pattern’, to determine the remote directory. This will run an rsync command, which takes about 30 minutes (ex. for the dark noise data).

As this script is run manually, it should be executed once per mode per FAT cycle.

Gain¶

See previous page

Monitoring¶

The monitoring DAQ script looks for a number of specific things and is generally run as the temperature is increasing or decreasing. It mainly performs checks of the gain, peak heights, dark rate, and delta-T as a function of temperature. The analysis script lives in degg_measurements/analysis/darkrate/ and can be run as:

python3 darkrate_vs_temperature.py /home/icehap-daq/data/json/run/run_00XXX.json -n [Y] --cache -o run_XXX_Y.hdf5

In this case “Y” is the specific monitoring run you would like to analyse. This is determined from examining one of the D-Egg json files and finding the “DarkrateTemperature_Y” tag: (/home/icehap-daq/data/json/run_00XXX/DEgg*.json). As performing the analysis can take some time if the dataset is large, we create an intermediate output file with -o. The syntax is setup such that you can combine several monitoring measurements from the same run. Alternatively you can manaully combine the dataframes later. Be careful about combining too many monitoring runs together as this can make the dataframe quite large (less than ~20). Also combining monitoring runs which feature both increasing and decreasing temperature profiles may look strange.

To make the final output files and the database json files you should run:

python3 darkrate_vs_temperature.py /home/icehap-daq/data/json/run/run_00XXX.json -in run_XXX_Y.hdf5

Interesting plots to check are the darkrate versus temperature for each module.

Simple Test Framework¶

The results from the simple test framework (STF) are produced when the script is executed and uploaded as it goes along. The results can be found here: https://hercules.icecube.wisc.edu/prodcal/runset_summary and selecting “Set Name: D-Egg FAT”.

Dark Rate¶

Running the default dark rate measurement is very straightforward. The script is located in degg_measurements/analysis/darkrate. It should be run for the dedicated dark rate measurements which are performed after the D-Eggs have been at a stable temperature and dark conditions for ~days. Running with the following configuration will create mainly summary plots of the dark rate and a final histogram:

python3 analyze_darkrates.py /home/icehap-daq/data/json/run/run_00XXX.json -m scaler

The primary plot to check is if any particular PMT has a dark rate over 3 kHz (uncorrected) or ~1.2 kHz (corrected).

Delta-T¶

The delta-T is naturally a function of the dark rate, but the shape can provide useful information regarding the dominating components (correlated/uncorrelated). At cold temperatures (below ~0), the contributions from the correlated and uncorrelated noise should be roughly the same. This script is also located in degg_measurements/analysis/darkrate and can be run with:

python3 analyze_dt.py /home/icehap-daq/data/json/run_run00XXX.json

Double Pulse¶

The double pulse analysis opens the D-Egg PMT waveforms and runs a simple peak-finding algorithm on them. The laser is pulsed with a 20 ns separation between the two pulses. For a PMT to pass the test, the laser pulse time should be “reconstructed” to be within 18 to 22 ns. This goal post size was determined based on the FPGA sampling frequency of 240 MHz.

Two versions of the script exist, but the simple version should only be used for testing purposes. Please run the script in degg_measurements/analysis/double_pulse/ as follows:

python3 analyze_double_pulse.py /home/icehap-daq/data/json/run/run_00XXX.json --every_waveform

The --every_waveform tag is important, so that the peak finder is run individually on every waveform rather than just on the average. This allows for a more realistic calculation of the peak separation and its error.

LED Flahsers¶

Each D-Egg is equipped with 12 LEDs, 8 horizontal and 4 vertical. The intensity of a given LED has a large variance and performing precision measurements of the intensity falls outside the FAT requirements. Instead, a simple test is performed to check if the observed charge is consistent with the PMT baseline. As the measurement is performed with the calibration trigger, the contribution from noise events should be around 0.

The script in degg_measurements/analysis/flasher_chargestamp/ can be run as:

python3 analyze_flasher.py /home/icehap-daq/data/json/run/run_00XXX.json

which will create output files for the lower PMTs as a function of LED voltage. In the case where the LED is working, the charge should increase above the baseline once the LED voltage reaches a certain level.

Linearity¶

The linearity analysis takes the observed average number of photoelectrons and peak current for a given filter wheel setting and compares to the ideal values. These ideal values are calculated based on the 10% filter (2nd dot), under the assumption that Observed = Ideal in this region. Each PMT is then fit independently, and the relative divergance from the ideal line at 200 PE calculated: D = Observed|200 PE / Ideal|200 PE. This value should be greater than or equal to 60%. The same goal post is applied for the peak current at 10 mA.

The script in degg_measurements/analysis/linearity can be run as:

python3 analyze_linearity.py /home/icehap-daq/data/json/run/run_00XXX.json

Check that both the “NPE_ideal_vs_observed” and “current_ideal_vs_observed” plots look good for the PMTs. This means that the fit describes the data well, and that the final point (100% filter) is above 200 PE. Depending on how the fiber output changes over time, this may need to be adjusted.

Timing Resolution¶

The timing resolution DAQ script already performs some light re-formating to the data, by pre-constructing a pandas dataframe. As such, the analysis script in degg_measurements/analysis/tts/ takes the pandas dataframea as the input. Old files before 2022-05-26 are found in: degg_measurements/timing/data/tts/<date>, but should be relocated to /home/icehap-daq/data/fat_calibration/tts. (Confirmed 2022-09-12)

Current implementation as of 2022-09-12 - SEE NOTE BELOW BEFORE RUNNING WITH SPE MODE!:

python3 analyze_tts.py <path_to_run_json> --rate <laser_rate>

Old implementations of the script are run as:

python3 analyze_tts.py -in <path_to_file> --rate <laser_rate>

where the ‘rate’ is the repetition rate of the laser in Hz. For the MPE-level TTS measurement, this is usually 100 Hz. At the SPE-level the rate is typically around 1 to 2 kHz. When analyzing data from ex. --spe, setting the rate correctly is very important. Note, the SPE configuration performs more checks and can take a long time and lots of memory. !!It is highly recommended to run the analysis on a node (tequila, bourbon)!!!

During the DAQ, the D-Egg mainboards are synchronised to the PPS (pulse per second) from the GPS and each board obtains the current clock time (from the mini-fieldhub ICM). In order to calculate the timing resolution, triggers from the table-top mainboard (indicating the laser sync-out) are matched to the PMT pules. This matching has some constant offset due to synchronisaton of the different mini-fieldhubs at measurement time, as well as cable delay and clock drift (not discussed here). As of 2022-09-12 this issue should be resolved, such that the offset of future results is the actual TT + cable effects. These effects result in a shift along the x-axis, but as of 2022-09-12 should no longer move between measurements and FAT runs. In general, the position along the x-axis is not a true indication of the PMT’s performance. If you observe that the tail of one of the distributions is being clipped by the matching window, you can temporarily increase this value. Currently is it configured to t_tolerance = 260e-9 on line 303. Again, this should have been resolved since 2022-09-12

Calculating the matching again can be time consuming if the number of triggers is large so a cached file is created automatically under cache/.

If the matching was satisfactory, but you’d simply like to remake the plots, run the script again using the cache:

python3 analyze_tts.py -c cache/timing_00130_matched_triggers.hdf5 --rate <laser_rate>

When examining the plots created by the script look, you should look for 2 primary things.

Is the histogram regular, i.e. does it actually follow a Gaussian distribution? In some cases we have observed distributions where there appear to be many local maxima outside the primary peak. This is still being investigated.
If the histogram is regular, does the fit describe the data. This is most important around the peak and 1-sigma width.

Future iterations of the analysiss should also take into account the mb-mb TTS.

Baseline¶

The baseline analysis script is critical to almost all other analyses and DAQ scripts. It does not create an output json file by default and rarely needs to be run on the command line. More commonly it is imported and run in scripts like:

from degg_measurements.analysis import calc_baseline
baseline = calc_baseline(bl_file0)['baseline'].values[0]

where the “bl_file0” is a file output by the measure baseline script.