Summary
The calibration unit (CU)
CU is different from the LAT in many respects, so is the software to run it. There is essentially only a single local installation allowing to run the CU, right now, and it resides on the lat-btserver - latbt01 machines. Here are some notes about the installation itself, the tests that can be performed, the schema files to be used.
Flight Hardware : TKR (FM8) & CAL (FM101) on bay 3 (close to the edge) and CAL (FM109) on bay 1.Patrick will back-up all data from the computers. Reference runs for data taking were not linked because we are not connected to the farm (behind firewall) We took photos from arrival and during installation in the clean room.
No modifications were done or rework on towers during the beam test. During intergration for 1 integration into the 1 x 4 grid one TKR connector for cable 7 (between flex cable 7 and the TEM) of non-flight TKR, slightly shifted was slightly offset and we added a connector saver to avoid stress in the cable.
Note for mechanical crew : For future operations, note that clearance inside is very small, so exercise care before remving the Inner Shipping Container. Since SLAC has a precision crane this will not be an issue.
Eliazar Ortiz assured us that the clean room (room 104) is continuously monitored for humidity and temperature.
Downloaded data from recorder: max humidity 7%, max temp 33 C, Max force 4 g. Eliazar downloaded all data , which was then provided to John Ku for review. Note: Dates are logged in awkward format: first day was April 24, last day was May 1 2007.
Summary of Results
The CU is different from the LAT in many respects, so is the software to run it. There is essentially only a single local installation allowing to run the CU, right now, and it resides on the lat-btserver - latbt01/lat-bt04 (spare) machines. Here are some notes about the installation itself, the tests that can be performed, the schema files to be used.
No anomalies or failures were experience over the coruse course of the beam test that would degrade the flight hardware. The fact that CU passed functional tests below demonstrates that.
...
The documentation of all beam test activities is available in this linkClearance is very small, exercise care before remving the Inner Shipping Container.
Tests at SLAC were carried out by Carmelo Sgro and Lua Baldini and data reviewed by Eduardo do Couto e Silva and Jana Thayer./
As part of the knowledge transfer process from Pisa to SLAC, Luca and Carmelo taught Jana how to operate the CU.
Tests
Here is the list of functional tests we performed as part of the incoming procedure.
...
For charge injection runs, tests are self-contained and results labeled PASSED are indeed meaningful (we also inspected the reports). Charge injection tests are done one tower at the time.
For data taking tests we added a reference run taken from the Beam Test at CERN (see below) because the PASS/FAIL condition is affected by how we treated the FIFO errors. Also configuration of the set-up may affect rates. So the figure of meirt for the data taking is that event rates are consistent with expectations.treat the well-known issue of TKR FIFO errors.
Jana will ask Patrick to back-up all data from the computers. Reference runs for data taking were not linked here because we are behind the firewall and it does not make sense to do all the work manually when the whole disk will be backed up.
Note about tests: When the CU is powered up and initialized after having been off for an extended period of time, trigger parity (and other data acquisition) errors are often observed for the first few hours of running. This problem has been consistently observed over the life of the CU and is believed to be a DAQ issue (we dot not use Flight DAQ modules, nor FSW in the CU), not a CU problem. Consequently, some events taken within the first few hours after the CU is powered will show evidence of parity errors until the problem resolves on its own on the timescale of a few hours. The quality of the rest of the data is not adversely affected. There has been some investigation on this from our team and Ric Claus, but we never came to a conclusion. Luca Latronico collected all the relevant info in some emails. Jana is aware of the issue and agrees that due to the transient and non-fatal nature of the problem, it is a feature that does not need to be fixed. Further investigation would involve swapping out the GASU and attaching the CU to a more flight-like DAQ, which is in line with the current plans for the unit. This problem has not interfered with the operation of the CU in the past and it is not expected that it will interfere in the future.
TKR
- Noise and gain measurement (TkrNoiseAndGain.py)
- Reference run for the TKR module attached to TEM 3: run 700004421 (PASSED)
- Reference run for the TKR module attached to TEM 2: run 700004435 (PASSED*)
* Note that TKR FM16 (connected to TEM 2) is not filght and it does have its "features" and idiosyncrasies. In particular there are quite a few layers failing in terms of disconnecetd/defecting channels (Y15, X13, Y11, Y10, Y2). A good reference run for comparison (though quite old, now, and taken with a different software version) is run 700000107:
- Noise occupancy measurement (TkrNoiseOccupancy)
- Reference run for the TKR module attached to TEM 3: run 700004422 (PASSED)
- Reference run for the TKR module attached to TEM 2: run 700004436 (PASSED)
CAL
- Standard CPT (CPT_beamtest.py)
- Reference run for the CAL module attached to TEM 3: runs 700004423-700004433, summary 700004434 (PASSED)
- Reference run for the CAL module attached to TEM 2: runs 700004437-700004447, summary 700004448 (PASSED)
- Reference run for the CAL module attached to TEM 1: runs 700004449-700004459, summary 700004460 (PASSED)
Data taking
- Standard end2end (BT 2, nominal conditions, all triggers enabled). See table of configurations
- 700004466 ~ 2 kevents
- 700004467 ~ 12 kevents
- reference run from BT 70000657Triggers rates for TKR 2 and 3 are slightly different but consistent with results from CERN tests
...