ATLAS Detector Resources & Lumi Blocks Enrico & Nicoletta

Lumi Block (LB) ATLAS data taking runs divided into intervals of time: Lumi Blocks – 1 minute long last year Data events within a LB (should) have been generated with same conditions – detector status – trigger keys Changes of such conditions must issue a LB change – minimal LB length = 10s – the conditions must be known by the expert system which issue the exceptional LB changes LBs drive – data files closure – IoV for some COOL information – some collections of monitoring data – ATLAS instantaneous luminosity computation – … 2

ATLAS Detector Resources During a run many changes occur to the detector – parts to be removed/reinserted from/into data taking – parts turn off/on If a part of the detector is described in the data taking database (OKS) as a Resource, it can be automatically enabled/disabled from the data taking – status of the resource saved in COOL under /TDAQ/EnabledResources/… – expert system issues a LB change 3

What is a Resource? A resource can represent a different granularity of ATLAS – subdetector itself (e.g. Pixel detector) – a sensor (e.g. 80M) Each (muon) subdetector chose a different granularity – e.g. disable a chamber in MDT does not trigger a LB change, but disable a Pixel Module does it Goals: – agree on a common definition of Resources – store enable/disable status in COOL agree on: folder structure, IoV, content (channel ID & channel name) – define when to issue LB change too small granularity should probably not trigger LB change  risk of too frequent LB change 4

A use case (MDT) A ROD can be: – recovered through a re-synch fast operation, trigger hold no need for change in COOL? True for reconstruction purposes, but not for tracking problems – removed through stopless removal registered in COOL, LB change – rare conditions! Chambers can be dropped during the run – the ROD performs the operation – RCD is informed and publishes chamber status – DCS triggers re-initialization – DAQ informed and chamber re-included by the ROD – no need to stop the trigger – condition to COOL through DCS (and in data) 5

A use case (MDT) Active chambers configuration – active chambers configured via a ROD mask in DCS – no information to resource display when dropped – information to COOL only in DCS Push to define chambers as resources – good to easy user interface to configuration – can be disabled/enabled when recovering – condition can be displayed and consistently updated in COOL – But: recovering a chamber is rather frequent the temporary drop of chambers does not substantially change run conditions – if the number is small and chambers are “well distributed” recovery is rather fast Special resources with thresholds? – is it possible to define resources not triggering LB change? – is it possible to have user-defined thresholds for that? 6

Open Questions Where the COOL information with detector resources status are used? – DQ? – offline? – simulation/MC? If offline uses it, which detector granularity is needed by the reconstruction? Which information are written to COOL only in DCS? – which conditions ended in the data? Are 10s LBs treated by the offline as the 1m LBs? Those questions need to be answered in order to adopt a proper resource description 7

To Be Agreed On Define COOL data – uniform folder structure allows for better use of the information (e.g. web page to display status of resources online) Decide when a change of resource status should trigger a LB change Maybe useful to define two types of Resources in OKS? 1.whose status change issue a new LB 2.whose status change is ONLY recorded in COOL 8