Brief Description of TestDAQ runs

This file was last updated on Sep 13, 2005
On Dec 13 the flasher width mistake was corrected

Brief Description of TestDAQ runs

Every TestDAQ run we have taken so far at pole is shown here , sorted by year, month and day (reverse-ordered so the latest runs appear first). The DarkNoise runs are listed here , and the Flasher runs are listed here .

The information on these webpages is presented in the following format (you can click on any of the hyperlinks):

Year

Month

Day

Server

Run Number

Run Type

Steering File

Data Hit File
(MBytes)

Domcal Zip File
(MBytes)

TestDAQ Control Log

Data Quality Log

Comments

Median Mainboard Temperature (degrees)

Median Mainboard Scaler Rate (kHz)

2005 05 25 SPS-DAQ-STRINGPROC01 0006147 DarkNoise-FullReadout-ATWD0 SteeringXML 991.02 MB 2.11 MB TDlog DQlog - -

2005 04 17 SPS-DAQ-STRINGPROC01 0003617 LocalCoincidence-023-IniceIcetop-NoHit-ATWD0 SteeringXML N/A 2.11 MB TDlog DQlog 16 requested DOMs not present - -

2005 04 10 SPS-DAQ-STRINGPROC01 0003116 Flasherboard-60Bucatini-Bright127-Width020-MaskFFF-Rate0610-ATWD0-A SteeringXML 9.56 MB 2.11 MB TDlog DQlog flasherboard failed power up - -

2005 02 06 SPS-DAQ-STRINGPROC01 0000428 Flasherboard-23Lemur-Bright064-Width020-MaskFFF-Rate0610-ATWD0 SteeringXML 236.24 MB 0.39 MB TDlog DQlog - -

provided by the 50 lines of code which make up "Experiment Control"; includes year, month, day, string processor id and run number

Run type - contains useful keys/phrases having to do with the run configuration

hyperlinks to data and to log files

useful info about the run

The run descriptor contains the following information:

1) the string processor ID as determined by "Experiment Control", eg "SPS-DAQ-STRINGPROC01"

2) the run number, as determined by "Experiment Control", eg "run0000428". The run number is contained between the first and second underscores in the run descriptor.

3) the run type, eg "Flasherboard", "DarkNoise", "LocalCoincidence", and any other information deemed important

"Flasherboard" runs contain the following additional information in the run descriptor, eg for SPS-DAQ-STRINGPROC01_run0000428_Flasherboard-23Lemur-Bright064-Width020-MaskFFF-Rate0610-ATWD0:

1) the position on the string and the name of the DOM which is flashing (eg "23Lemur")

2) the LED brightness setting (eg "Bright064", 127 is the maximum brightness)

3) the width of the LED pulses in ns times 2 (eg "Width020", 127ns is max width)

4) which LEDs are on (there are 12 LEDs and "MaskFFF" means all LEDs are on, "Mask001" would mean that only LED #1 is on); in early runs I used the phrase "led" instead of "Mask". LEDs 01 thru 06 are on the top side of the flasherboard pointing up at 45 degrees, and LEDs 07 thru 12 are on the underside of the flasherboard pointing downwards at around 10 derees.

5) the rate the LEDs are flashing at (eg "Rate0610" = 610 Hz, currently always the case)

6) which ATWD is being read out - in Pole runs we almost always read out ATWD0 (chip "0", not channel "0"), but I took some runs where I read out ATWD1 (chip "1", not channel "1") - the two chips have different sets of calibration contants.

Additional fields in the run descriptor:

1) in some runs you can find additional phrases in the run descriptor. Hopefully no additional explanation is required. Beware of runs with the phrase "SuiteCaseDOMS"!

2) If the run has the phrase "NoHit" then the TestDAQ hit file was left at the pole (satellite bandwidth limitations prevent us from bringing over all TestDAQ hit files) you can click on the steering XML file to get the full run configuration.
For SPS-DAQ-STRINGPROC01_run0000428_Flasherboard-23Lemur-Bright064-Width020-MaskFFF-Rate0610-ATWD0 you will see:
The flashing DOM "Lemur" (if you start looking through these files you will quickly learn that it is much easier to look for a simple name in a sea of numbers instead of looking for a serial number in a sea of numbers!) you will see:
param name="NUM_SAMPLES_ch3" value="64"
param name="SAMPLE_SIZE_ch3" value="2"

This means we were reading out the Muxed signal on ATWD chip 0 channel 3, 64 samples of it at 2 bytes per sample (this waveform contains the current pulse for one of the LEDs on the flashing DOM). Also:

param name="FB_ENABLE" value="1"
param name="FB_BRIGHTNESS" value="64"
param name="FB_WIDTH" value="20"
param name="FB_DELAY" value="150"
param name="FB_LED_MASK" value="4095"
param name="FB_RATE" value="610"

These settings should correspond to what is in the run descriptor. (FB_DELAY is unimportant for this discussion).

For any other DOM the readout configuration can be set differently. In this particular run the entire ATWD (not the Muxer, however) and also the complete FADC were read out:
param name="NUM_SAMPLES_ch0" value="128"
param name="SAMPLE_SIZE_ch0" value="2"
param name="NUM_SAMPLES_ch1" value="128"
param name="SAMPLE_SIZE_ch1" value="2"
param name="NUM_SAMPLES_ch2" value="128"
param name="SAMPLE_SIZE_ch2" value="2"
param name="NUM_SAMPLES_ch3" value="0"
param name="SAMPLE_SIZE_ch3" value="2"
param name="NUM_FADC_SAMPLES" value="255"

Data-taking at pole

List of IceCube Modules

Modules came online almost every day for several days. Note that the earliest South Pole runs were performed in water, not ice. Here is a snapshot list of modules being used in data-taking before and after Feb 1st, 2005.
On Feb 1st 2005 we had 16 modules hooked up for normal data-taking. By Feb 6 this figure had grown to 36 modules.

Beginning on Feb 1st I made an attempt to use the longest "mini-string" possible, and when I took Flasher data I made sure to flash a DOM somewhere on this long "mini-string".

The data-quality log

Probably the best way to find out which DOMs were part of a run is to click on the "Data Quality Log", which contains the total number of triggers for each DOM.

You could also look at the configuration steering file, and cross-reference which of these DOMs were "active" (listed at the bottom of the steering file).

If the data-quality log finds missing DOMs, then this is noted in the Comments field of the TestDAQ run description webpages.