ATLAS Detector Resources & - PowerPoint Presentation

Slide1

ATLAS Detector Resources & Lumi Blocks

Enrico &

NicolettaSlide2

Lumi Block (LB)

ATLAS data taking runs divided into intervals of time:

Lumi

Blocks1 minute long last yearData events within a LB (should) have been generated with same conditionsdetector statustrigger keysChanges of such conditions must issue a LB changeminimal LB length = 10s the conditions must be known by the expert system which issue the exceptional LB changesLBs drivedata files closureIoV for some COOL informationsome collections of monitoring dataATLAS instantaneous luminosity computation…

2Slide3

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 takingstatus of the resource saved in COOL under /TDAQ/EnabledResources/…expert system issues a LB change3Slide4

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 granularitye.g. disable a chamber in MDT does not trigger a LB change, but disable a Pixel Module does itGoals: agree on a common definition of Resourcesstore enable/disable status in COOLagree on: folder structure, IoV, content (channel ID & channel name)define when to issue LB changetoo

small granularity

should probably not trigger LB change



risk of too frequent LB

change

4Slide5

A use case (MDT)

A ROD can be:

r

ecovered through a re-synchfast operation, trigger holdno need for change in COOL? True for reconstruction purposes, but not for tracking problemsremoved through stopless removalregistered in COOL, LB changerare conditions!Chambers can be dropped during the runthe ROD performs the operationRCD is informed and publishes chamber statusDCS triggers re-initializationDAQ informed and chamber re-included by the RODno need to stop the triggercondition to COOL through DCS (and in data)

5Slide6

A use case (MDT)

Active chambers configuration

a

ctive chambers configured via a ROD mask in DCSno information to resource display when droppedinformation to COOL only in DCSPush to define chambers as resourcesgood to easy user interface to configurationcan be disabled/enabled when recoveringcondition can be displayed and consistently updated in COOLBut:recovering a chamber is rather frequentthe temporary drop of chambers does not substantially change run conditionsif the number is small and chambers are “well distributed”

r

ecovery

is rather fast

Special resources with

thresholds?

i

s it possible to define resources not triggering LB change?

i

s it possible to have user-defined thresholds for that?

6Slide7

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 7Slide8

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 changeMaybe useful to define two types of Resources in OKS?whose status change issue a new LBwhose status change is ONLY recorded in COOL8