Barrel RPC Conditions Database It will hold all data describing the running conditions of the detector: Main part of the conditions data will be necessary for physics event reconstruction Other data will be used for error tracking It is a “trait d’union” between online and offline data What does that mean for Barrel RPCs ?

What we are dealing with 4 layers of muon detectors: in the barrel RPC+MDT In each layer 12 sectors: In each sector: 2 RPC chambers for RB1 and RB2 1 RPC chamber for RB3 and RB4 … for a total of 480 chambers

RPC system numbers area covered: 2400 m2 number of RPC chambers: 480 number of strips: ~75.000 number of front-end cards: 4.700 Each chamber has associated with it its story: construction DB Some of these data will have to be uploaded to conditions DB Data types (just a first hypothesys): substantially four kinds: ”Geometric” constants Environmental conditions Running conditions “Historical” informations

“Geometric” data Main (and primary) task: pass from raw data to tracks Raw data from RPC: hit address Chamber ID (2 bytes) and Fired Strip ID (1 byte) Needed: geometry of the Chamber From the point of view of fired strip information, RPCs chambers come into 10 main “flavours”, plus some variations (chimneys), differing in dimensions and strip pitch. Maybe necessary to keep track also of the service position (i.e. for noise studies) …then a factor 2 more types (left and right) Actually, due to the presence of pre-loaded bars, almost all chambers are different …

“Geometric” data Immediate association in the “local” reference system Hit address To pass from local reference system to CMS reference system, a point and three angles needed (from alignment?) In the barrel RPCs are “solidal” with MDT, so this part of the code could be common? Precision needed: hit information has the spatial resolution of the strip dimension, order of cm Reasonable to reach an order of mm accuracy

Environmental conditions Essentially temperature, pressure, humidity, needed for correct calibration of the system Temperature measured: 1 per Chamber (external) 1 per Front-end board Humidity measured: 1 per gas crate (internal) 1 per CMS (external) Pressure measured: 1 per CMS Informations from the gas system: operating conditions, gas flow rate, percentage of recirculation Hopefully more or less stable: no need to update constants frequently

Running conditions Basic information: was the chamber on? … Each chamber is divided in 2 or 3 DoubleGaps, so needed one information per DG … (maybe, in particular cases, one per SG?) Operation HV: 1 per chamber, maybe 1 per DG On front-end electronics: low voltage, threshold on input signals Possible failures (for instance) Front-end: broken boards Strips: “dead” or noisy strips ….. These should be the direct logging of a diagnostic online system

Running conditions It is an open issue, how often, and in which way, runs dedicated to calibration and measuring of subdetector performance will take place In this case, do we want also to keep track of a rough performance of the detector (important for estimating the trigger efficiency)? …Moreover, the information coming from RPCs will be fed into dedicated pieces of electronics (link and trigger boards) to generate 1st level muon trigger Informations related to connection topology, and problems in these deviced

“Historical” informations Probably useful if one wants to track possible sources of error, or for a better calibration, without accessing the construction DB For instance: measured resistivity (even at the level of bakelite sheets) measured efficiency (or noise) before installation, useful to keep track the need for a different operating voltage or threshold value

Conclusions and open issues At the moment we can define (more or less precisely) the kinds of data we want to keep in the conditions DB …more feedback needed from people making reconstruction and simulation analysis Given the data types, frequency of data refreshing in the DB can be inferred Given the main task of this detector (generate a 1st level muon trigger) needed more feedback from the trigger community To define how these data can be trasferred (from construction, geometry, etc.) to conditions DB … format, syntax …