MICHIGAN ATLAS CHAMBER COMMISSIONING DATABASE

OCTOBER 17, 2004

SHAWN MCKEE, J WEHRLEY CHAPMAN, TIESHENG DAI, EDWARD DIEHL, CLAUDIO FERRETTI, DANIEL LEVIN, RUDOLF THUN, ZHENGGUO ZHAO AND BING ZHOU

DEPARTMENT OF PHYSICS

UNIVERSITY OF MICHIGAN

ANN ARBOR, MICHIGAN 48109

THE UNIVERSITY OF MICHIGAN CHAMBER COMMISSIONING DATABASE

TABLE OF CONTENTS

1.   ABSTRACT  4

2.   INTRODUCTION  4

3.   OUTLINE OF PAPER  5

4.   DATABASE DESIGN PHILOSOPHY  5

5.   COMMISSIONING CHAMBER COMPONENTS AND TESTS  6

6.   UM DATABASE IMPLEMENTATION OVERVIEW  9

6.1   DATA INPUT  9

6.2   WEB INTERFACE  10

7.   PLANNED FUTURE EXPLORATIONS  10

8.   FIGURES  11

9.   REFERENCES  28

10.   APPENDICES  29

10.1   SHORT DESCRIPTION OF THE ELECTRONIC TESTS  29

10.1.1   PRETEST HV OFF  29

10.1.2   NOISE TEST HV OFF  29

10.1.3   THRESHOLD SCAN  30

10.1.4   INJECTION SCAN  30

10.1.5   LINEARITY SCAN  31

10.1.6   GAIN SCAN  32

10.1.7   PRETEST HV ON  32

10.1.8   NOISE RUN HV ON  32

10.1.9   EXTRA NOISE RUN HV ON  33

10.1.10   ELECTRONIC TESTS HV ON  33

10.1.11   COSMIC RAY RUN  33

10.2   SUMMARY AND STRUCTURE OF THE COMMISSIONING DATABASE  35

10.2.1   Tables for electronics noise runs (“Bkg” station)  35

10.2.2   Tabels for cosmic ray data (“CR” station)  36

10.2.3   Tabels for electronics gain scan data (“Gain” station)  38

10.2.4   Tabels for eLectronics injection Scan data (“Inj” station)  39

10.2.5   Tabels for electronics linearity scan data (“Lin” station)  39

10.2.6   Tabels for mezzanine card Noise scan data (“Mezz” station)  40

10.2.7   Tabels for mezzanine card Serial numbers (“MezzSN” station)  41

10.2.8   Tabels forelectronics parts serial numbers (“SN” station)  41

10.2.9   Tabels for threshold scan data (“Thr” station)  42

10.2.10   Tabels for B sensor serial numbers (“Bsensor” station)  43

10.2.11   Tabels for Chamber dark current data(“chdc” station  43

10.2.12   Tabels for Chamber Leak data (“ChLeak” station)  44

10.2.13   Tabels for HV hedgehog card serial numbers (“HVHH” station)  44

10.2.14   Tabels for Chamber parts installation data (“parts” station)  45

10.2.15   Tabels for signal hedgehog card serial numbers (“rohh” station)  46

10.2.16   Tabels for chamber Survey target data (“survey” station)  46

10.2.17   Tabels for chamber traveler data (“traveler” station)  47

10.2.18   Tabels for temperature sensor ID numbers (“Tsensor” station)  47

10.3   APPENDIX 3: E XAMPLES OF “ STATION” TEXT FILES  49

10.3.1   Survey target station file ("Survey" station)  50

10.3.2   B sensors station file ("Bsensor" station)  56

10.3.3   PMO mask mount station ("PMOmnt" station)  56

10.3.4   Parts station ("Parts" station)  56

10.3.5   High Voltage hedgehog cards serial numbers ("HVHH" station)  56

10.3.6        Signal hedgehog cards serial numbers ("ROHH" station)  56

10.3.7   Temperature sensor serial numbers ("Tsensor" station)  56

10.3.8         Chamber leak test ("ChLeak" station)  56

10.3.9   Multi-Layer Long-term Leak (‘leakLT’ Station)  56

10.3.10   Dark Current (‘chdc’ Station)  56

10.3.11   Inplane GRanite/GRadient Measurement (‘granite’ Station)  56

10.3.12   CHAMBER ELECTRONICS SERIAL NUMBERS (‘SN’ StatiON)  57

10.3.14   Threshold Scan HV OFF & HV ON (‘thOFF’ & ‘THON’ Station)  57

10.3.15   OFFSET CORRELATION HV OFF & HV ON (‘MEZZOFF’ & ‘MEZZON’ Station)  57

10.3.16   Injection Scan HV OFF & HV ON (‘injOFF’ & ‘INJON’ Station)  57

10.3.17   Linearity Scan HV OFF & HV ON (‘linOFF’ & ‘LINON’ Station)  57

10.3.18   Gain Scan HV OFF & HV ON (‘gainOFF’ & ‘GAINON’ Station)  57

10.3.19   nOISE RUN HV OFF & HV ON (‘BKGOFF’ & ‘BKGON’ Station)  57

10.3.20   Final Cosmic-Ray Test (‘CR’ Station)  57

10.3.21 ChamberTraveler ("Traveler" station)

10.4   APPENDIX 3: TABLES FOR MAPPING TUBE ID TO ELECTRONICS CH ANNEL  57

11.   TABLE INDEX  66

12.   FIGURE INDEX  66

ATTACHMENT I:  66

THE UNIVERSITY OF MICHIGAN ATLAS CHAMBER COMMISSIONING DATABASE

1.  ABSTRACT

We describe herein the design philosophy and the implementation details of the University of Michigan ATLAS Phase I Chamber Commissioning Database. Details are given that would be useful to other institutes wishing to establish a similar facility or for use as a design basis for other chamber commissioning.

Back to top

2.  INTRODUCTION

Over the next few years the ATLAS Collaboration will need to test, and commission a massive high precision muon spectrometer consisting of more than one million readout channels. The proper performance of this instrument is absolutely critical to the success of the experiment, particularly since one of the key physics goals is the detection of the Higgs boson, and the four-muon decay is expected to be one of the principal discovery modes.

After the base MDT chamber construction, the University of Michigan has moved to the next phase of the muon detector work: commissioning and testing the muon chambers. Michigan chambers consist of some of the longest drift tubes used in the experiment and are subject to a unique variety of design, production and commissioning challenges.

The success of the chamber pre-commissioning (so called phase I commissioning prior to detector installation) will depend critically on the creation and maintenance of a comprehensive database that is to contain the relevant evolutionary history and characterization of each muon chamber component and test.

There are a number of components to be installed on chamber and tests to be run during chamber commissioning . We will provide details of the tracked components and tests in section 5 of this paper. In addition we have designed a “Chamber Checklist” which is intended to be stored with each chamber and updated as the chamber progresses thru commissioning and testing. The detailed checklist is provided as Attachment I. The structure of our commissioning database reflects the steps followed in the commissioning and testing of the chambers.

We present herein the philosophy that guided us in the development of this database, and reference the repository of code that may be required as upgrades are made to the package in the years ahead.

There are several novel elements in our approach. One is a rather close linkage between our ACCESS database and PAW (a CERN analysis package), designed to facilitate extensive analysis of the chamber data in an environment that is familiar to a large number of the Project’s physicists. Another is the use of a tandem database structure where appropriate subsets of the final local data is routinely captured and made available to other ATLAS databases. Indeed, this arrangement will permit ongoing upgrades to the main local database, while yet providing a stable feed to the other databases. An additional unique feature is the provision we have made to insure that the essential functions of the database are accessible remotely via the web.

Other details will be described herein that we hope will be of value to other institutes as they design and deploy their databases.

Back to top

3.  OUTLINE OF PAPER

In Section 4 we discuss the guiding principles we used in establishing our database. The details of the commissioning components and tests are described in Section 5, including tables of recorded quantities. In Section 6 we provide an overview of the database implementation. Section 7 concludes with a view about possible future work.

Section 8 is a set of figures detailing important information for chamber commissioning. Section 9 includes all references. Section 10 are a set of appendices showing detailed information about the database, input file formats and tube to electronics channel mappings. The paper concludes with an attachment of our “Chamber Traveler” showing the details recorded on paper and stored with each chamber.

Back to top

4.  DATABASE DESIGN PHILOSOPHY

There are several basic principles we have tried to adhere to as the database structure was established. Many of these will, at first, appear to be obvious. But, even a significant fraction of these are subject to a reasonable debate.

To give just one example, in this day and age of fast computers and cheap data storage cost, one might think it reasonable to measure and record each and every conceivable bit of information about every component that goes into the muon chambers. After all, it may be argued, we may wish to have access to a particular data element five years from now, even though we see no use for it now. The competing argument is that if we are not careful we will drown in useless information and will be led into a false state of believing we can accept wide variances in chamber parameters now, since we presumably could correct for most maladies in the future. Even worse, the added burden of generating and recording data which may never be used could cause us to fail to meet our schedule or drive our costs over budget.

Against this background, we have decided to adopt the following set of guidelines:

We will collect and store every piece of data that is known to bear directly on the principal physics performance of the muon chamber

We will collect and store chamber   commissioning data related to the add-on components, commissioning conditions and commissioning test/verification procedures, including all information required by the ATLAS-wide muon coordinating groups like the MFT and Integration database groups.

We will automate each and every measurement possible. Each manual entry of a measured quantity to our database must be justified and approved for each case.

The database is to be available to any authorized user via the web. That is, key members of the ATLAS Muon group should be able to log on to the web anywhere in the world and, after sufficient authorization checks, have the same functionality as if he or she was in the commissioning lab.

Database backup should occur regularly, via replication, explicit backup to tape or disk and storage on RAID enabled system storage.

The initial database application backend will be based upon Microsoft ACCESS.

An ACCESS database, or whatever other application is specified by ATLAS, will be explicitly maintained to provide an interface to the ATLAS wide global databases.

Back to top

5.  COMMISSIONING CHAMBER COMPONENTS AND TESTS

The information we need to record for commissioning is critical to correctly identify each single component. Too much information will cause needless work, possible delays and/or cost overruns, while too little information risks missing recording potentially vital information needed during the systems operation or data analysis.

We have identified a number of components and tests from which we will gather selected information for storage in the database. While other components will be installed (Cables, Safety Brackets, AMB, etc.) we don’t have any need to record their details. The list of components we will track during chamber commissioning includes:

n   Survey Targets

n   B Sensors

n   PMO Mask Mounts

n   Gas-bar Extension Tube Types

n   Tubelet Types

n   HV Hedgehog Cards

n   Signal Hedgehog Cards

n   Mezzanine Cards

n   CSM Motherboard

n   CSM Daughterboard

n   DCS Box

The corresponding measurements and tests include:

n   Multilayer gas leak rate

n   Tube layer dark current rate

n   MECCA test

n   Inplane alignment measurements on granite table (copy from chamber production)

n   Inplane gradient measurements (copy from base chamber production)

n   Mezzanine card threshold scan

n   Mezzanine card linearity scan

n   Mezzanine card gain scan

n   Temperature sensor test (readout values and IDs)

n   Final cosmic-ray testing of full chamber

The following tables list the information we intend to record for each component or measurement. Implicit in each item is recording the Chamber ID barcode which gives the chamber mechanical ID, e.g., EML5C08.

Table 1 : Chamber Commissioning Components

The set of commissioning measurements and tests is given in the following table

Table 2 : Chamber Commissioning Tests and Measurements

Special Note on the Inplane RASNIK system: The inplane RASNIK system is an optical position measuring system consisting of a RASNIK mask, a lens, and a CCD camera. The lenses are mounted on the center crossbeam, and the mask and CCD are mounted on opposite end crossbeams. The system monitors the relative positions of the CCD, lens, and mask. The DB has the measurements of the inplane system when the chamber was on the granite assembly table and presumed to be perfected aligned with no distortions. When the chamber is removed from the granite it will distort, and by comparing inplane measurements taken off the granite with those taken on the granite, one may determine the chamber distortions the directions perpendicular to the inplane RASNIK lines. The RASNIK mask has encoded in it an X-Y coordinate system. The RASNIK X and Y measurements refer to the coordinates system used by the Brandeis RASNIK image analysis program. The mask is positioned so that the RASNIK X coordinate corresponds to the chamber Z coordinate, and the RASNIK Y corresponds to the chamber Y coordinate, with the exception of a possible sign change between the RASNIK X-Y and the chamber Z-Y. In order to determine this possible sign change, the RASNIK gradient (orientation) is measured. While on the granite assembly table, chamber distortions are introduced in the chamber +Z and +Y directions, respectively, at the position of the center crossbeam, and the change of sign of the RASNIK measurements compared to an undistorted chamber are recorded.

To calculate a chamber distortion one should use the equations:

 Z_chamber = Z_gradient * (X_Rasnik – X_granite)

 Y_chamber = Y_gradient * (Y_Rasnik – Y_granite)

Hence, in our convention, a positive distortion of the Z or Y value of RASNIK measurement means that the center crossbeam is offset in the +Z or +Y direction relative to the ends of the chamber.

Back to top

6.  UM DATABASE IMPLEMENTATION OVERVIEW

6.1  DATA INPUT

The list of permanent tables and fields comprising our production database are given in Appendix 1. Data are inserted into the database either manually or through a quasi-automatic process where data stations output results of their measurements to structured text files [See “UM DAQ System for MDT Production” by Qichun and Zhou, submitted as an ATLAS note]. These text files are then loaded into the database through express actions of the database manager (or a monitoring package, which he or she controls). In the latter step one has the option of not only coordinating the daily updates, but of also executing certain consistency checks before the uploading takes place.

Figure 1 : Schematic for information flow from each test station, to the File Server and finally into the Certification DB

6.2  WEB INTERFACE

Given the distributed nature of our production and testing facility, as well as the fact that key individuals in our group must be able to query the status of the fabrication at any time and from any place in the world, we have given high priority to providing full database access and control to authenticated users via the web.

The entire interface with the database will, of course, appear differently from the direct host-based interface described here. One reason has to do with security considerations. Another technical reason is that the web user is really not running ACCESS on the host machine, but rather is being provided with various published services. We have provided more details about how the features of the web interface in a previous ATLAS note on our production database (see reference 1)).

Back to top

7.  PLANNED FUTURE EXPLORATIONS

We plan to support future development based upon feedback from chamber commissioners.

Back to top

8.  FIGURES

Figure 2: Local chamber construction coordinate definition

Following are the figures referenced in the paper. First are the component ID drawings

.

Figure 3 : EI/EM chamber numbering scheme

Figure 4 : EO chamber numbering scheme

Each chamber type has locations charted for sensors, cameras and cabling. The following figures document these locations for EML5, EMS5, EML4, EMS4 and EML3 (A and C versions of each):

Figure 5: EML3 "A" chamber location numbering

Figure 6: EML3 "C" chamber showing location numbering

Figure 7: EMS4 "A" chamber showing location numbering

Figure 8: EMS4 "C" chamber showing location numbering

Figure 9: EML4 "A" chamber showing location numbering

Figure 10: EML4 "C" chamber showing location numbering

Figure 11: EMS5 "A" chamber showing location numbering

Figure 12: EMS5 "C" chamber showing location numbering

Figure 13: EML5 "A" chamber showing location numbering

Figure 14: EML5 "C" chamber showing location numbering

The mezzanine cards, as well as the signal and high-voltage hedgehog cards have a specific numbering that they follow as shown in the following figures. Not e the “A” and “C” chambers have a different map.

Figure 15: Mezzanine card mapping for "A" chambers

Figure 16: Mezzanine card mapping for "C" chambers

The cabling between Mezzanine cards and CSM is shown in the following figures.

Figure 17: Cabling to CSM on "A" chamber

Figure 18: Cabling to CSM for "C" chamber

Figure 19: Temperature sensor locations, drawing 1

Figure 20: Temperature sensor locations, drawing 2

Back to top

9.  REFERENCES

1)  “Michigan ATLAS Monitored Drift Chamber Production Database”, Neal, Homer et al. (ATL-COM-MUON-2000-004 ) 

Back to top

10.  APPENDICES

10.1  SHORT DESCRIPTION OF THE ELECTRONICS TESTS

MDT chamber electronics tests are done both with chamber HV OFF, to identify any problems due to mezzanine cards, and with chamber HV ON, to discover problems due to the MDT chamber. For a description of how to run the tests using the MiniDAQ program and related chamber data analysis see the WEB page: http://cdfrh0.grid.umich.edu/~claudiof/Atlas/b184/cerntest.html

The descriptions of the electronics tests will often refer to the following quantities:

1)   V offset span: absolute value of maximum difference of offsets as measured by Harvard in the single ASD chip test (ASD database)

2)   Effective threshold: nominal ASD threshold - hysteresis + correction from ASD V-offsets where the correction from ASD is done as:

2)   0.5 * (min V offset + max V offset) (V offset span < 12mV)

2)   0.5 * (min V offset + max V offset) – 2 mV (V offset span 12mV to 14mV)

2)   0.5 * (min V offset + max V offset) – 4 mV (V offset span 14mV to 16mV)

3)   ASD noise: hits with a charge width below a cut value set between 30 and 40 ns depending on the DAQ parameters. This noise is also referred to as "electronics noise" since it generally comes from the mezzanine cards and e.m.i. pickup.

4)   Tube noise: the noise remaining after subtracting the ASD noise, mainly related to the tube, HV hedgehog card and Signal hedgehog card.

10.2.1  PRETEST HV OFF

The MDT electronics tests with Chamber HV OFF start with a DAQ hardware check. This step typically requires a total time of 10 minutes. The main purpose is to insure DAQ system functionality and to check for valid mezzanine card IDs. An error message is issued for any of the following conditions:

1)   Unable to find or open the mezzanine card database file;

2)   Unable to find a mezzanine card in the mezzanine card database;

3)   An ASD threshold offset span is larger than 16.0 mV.

10.2.2  NOISE TEST HVOFF (“BKG” TYPE “OFF” STATION)

The first chamber test is a noise test. This test checks that the MDT chamber electronics are not noisy with HV OFF and identifies any mezzanine cards with a high ASD noise level.

The trigger used is the TTCvi random trigger at 5 KHz (the usual measured DAQ rate is 9.2 KHz with TTCvi Mark II). The (recommended) DAQ time for this run is 20 minutes (typical total test time is 22 minutes, including initialization), with an effective threshold -50mV and a (recommended) ASD Hysteresis of 8.75 mV. From this noise run both ASD and Tube noise rates are measured. The requirement is that for each channel/tube the ASD noise rate < 5KHz and a WARNING is issued for ASD/Tube noise > 5 KHz and a simple INFO for > 2KHz.

Recorded quantities (for each channel):

1)   Mezzanine Card Number and Channel Number (unique electronic address of each tube)

2)   Row Number (from 1 to 6/8, counted from the PMO side) and Tube Number (to address each tube as physical location)

3)   Number of large width hits,

4)   ASD noise and the non-ASD (Tube) noise rate in kHz.

10.2.3  THRESHOLD SCAN (“THR” STATION)

The second test is a threshold scan. This is to insure that recorded mezzanine card IDs are correct for each location by comparing the measured V offsets with Harvard mezzanine card/ASD database since the 24 channels V offsets from a card are like a fingerprint of the board. It also identifies any dead channels in the card.

Assuming there is predominantly thermal noise (generally the tube resistance is the dominate noise source and this is a valid assumption), the noise of each channel of an ASD chip is a threshold dependent Gaussian distribution:

 ASDNoiseRate = R0 * exp[-(V-VOffset)**2/(2.0*Sigma**2)]

where

·   R0 is the maximum ASD noise rate (typical value 20MHz);

·   V is the ASD threshold and VOffset is the threshold offset;

·   Sigma is the Gaussian width of ASD noise distribution.

This test measures the noise at different threshold and the measured results are fitted to a Gaussian distribution to obtain V Offset. The ASD noise rate can reach 20MHz which is far beyond the AMT chip readout limits (300 KHz per channel), so only the tails from the Gaussian are used for the fit.

Note: large noise not due to mezzanine cards (such as from the MDT chamber) could spoil the V offset measurement, typically with large CHI2 and abnormal sigma.

The test is structured as 76 runs of 10K events each with ASD hysteresis set to zero, the ASD calibration capacitor is 50fF, the trigger is a TTCvi software trigger (giving a typical DAQ rate of 2.5KHz), for a typical total test time of 35 minutes. In order to minimize the interference between the 3 ASDs, their thresholds are arranged so that if one ASD is at a low threshold, other two have high ones.

Recorded quantities:

1)   for each mezzanine, the card number and the channel number to address each single tube;

2)   for each channel the number of triggers,

4)   Number of degrees freedom (number of data points - 3 fit parameters),

6)   Chi square per degree of freedom,

8)   Three Gaussian fitted parameters V offset, Sigma and log(Normalization) and the correlation between on chamber data and the ASD database V-offset measurement.

The correlation is given for the full Mezzanine card (all 24 channels readout) and for each ASD.

All correlations are required to be larger than 70%.

A WARNING message is issued if:

�   a mezzanine card is not found in the card database

�   any of the previously described correlation is less than 0.7

�   the number of degrees of freedom of the Gaussian fit is less than 0.

�   V offset could not be measured, which happens for dead or extremely noisy channel.

An INFO message is issued if the absolute value of V offset is larger than 16mV (bad measurement or potential bad mezzanine card) or the Sigma from the Gaussian fit is larger than 10 mV.

INJECTION SCAN (“INJ” STATION)

The third test is an injection scan to identify low efficiency and high levels of crosstalk for each channel. The calibration signal is injected into a single channel of each mezzanine card so hits are expected only in the injected channel. The channel efficiency is defined as the actual hits in the injected channel over the number of injections. The channel crosstalk is defined as the number of actual hits in all the other 23 channels of the same card divided by the total number of injections. Of course, high noise rates can skew the crosstalk measurement since it is not based on time, but we have not found this to be a significant problem.

The test consists of 24 runs of 10K events each, with ASD Threshold at -50mV, ASD Hysteresis at 2.5mV, ASD calibration capacitor is 250fF and triggered by the TTCvi one shot random trigger (typical DAQ rate 2.5KHz), for a typical total test time of 11 minutes.

Recorded quantities (for each channel):

1)   Mezzanine card number and channel number,

2)   Number of triggers/injections,

3)   Channel efficiency,

4)   Channel crosstalk.

The single channel requirement is to have efficiency > 95% and cross-talk < 20% for channel 0, 8 and 16, and < 5% for other channels.

A WARNING message will be issued if a channel is

a)   Dead (efficiency <= 5%),

b)   Low efficiency (efficiency in the range (5%, 95%]),

c)   Hot (105% <= Efficiency < 200%),

d)   Very hot (efficiency>= 200%)

e)   Large cross-talk (>= 20% for channel 0, 8 and 16, >=0.05 for all other channels).

LINEARITY SCAN (“LIN” STATION)

The fourth test is a linearity scan which measures each channel's intrinsic TDC time resolution and checks for good linearity in time measurements. The calibration signals are injected at different times with respect to the calibration trigger. The average TDC time and TDC time resolution (calculated by using hits near major time peak) are obtained at each injection, and the measured TDC times are fitted against the expected ones using a linear function (s