FOCUS ON 3 GLOBAL ITEMSMuon Week, CERN

17-21 February 2014

Nicoletta Garelli (SLAC)

2

Fragment Sampling• Presented at DAQ-Detectors meeting on 27 Jan 2014 by

Wainer (https://indico.cern.ch/event/296275)• DAQ and Monitoring (gnam) experts should decide what to do

• RUN I: muon systems sample events at ROS• Which type of data?• Which rate?

• RUN II: Is the sampling at ROS really needed? Why?• Note: it is not sufficient to try to compile against tdaq-05-

03-00 and discover what is new, some planning and reading of release notes is necessary

2/20/2014

3

Wainer’s slide

2/20/2014

4

Wainer’s slide• Is ROS fragment sampling needed (in physics

datataking or DAQslice mode)?• sampling of full events at the HLT farm is possible• a 'Monitoring' stream type has been introduced

• dedicated HLT algorithms can accept events for monitoring → events will be fully built and made available over emon but not saved to disk

• If ROS fragment sampling is needed, is it acceptable to receive partial data?• not containing all ROL fragments for a given events• of course ROS can select requests containing data from all ROLs

• no guarantees on the rate at which this will happen → depends on trigger menu

2/20/2014

5

Enable/Disable Resources• 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/…

• We do not want to use DCS for storing this info in COOL (PVSS2COOL) anymore

• We need to:• Define a reasonable granularity for each subsystem• Define if/when to issue LB change• Modify OKS• Send the proper command to CHIP• Test

2/20/2014

6

Some technical notes from CHIP twiki• Light-weight procedure to disable/enable modules during a run

that have smaller granularity than a ROL and for which the BUSY and ECR setting are handled internally, if needed.

• The only thing that the CHIP does is notifying the ResInfoProvider of the change of status of some resources. Sequence: • Detector specific software sends a ERS issue of type daq::rc::ModulesDisabled or daq::rc::ModulesEnabled. The parameters contain a comma separated list of modules and a flag indicating whether the luminosity block shall be changed or not (NEW!).

• the parameters are validated (they shall be valid resources in OKS) and the change in enabled/disabled resources is notified to the ResourcesInfoProvider application using a USER command with arguments that are encoded using a dedicated utility (class Utils).

• if appropriate the MasterTrigger is asked to change luminosity block.

2/20/2014

7

Round-Table• MDT

• Run I: chambers and mezzanines enabled/disabled by RCD, but info stored in COOL via DCS

• Run II: Describe chambers as Resources, but keep mezzanines in DCS only for the time being

• TGC• Run I: sector granularity. • Run II: Daniel would like to implement the star switch granularity

(~10 per sector). Today, when a star switch times out the ROD drops it, but not listed as Resources

• RPC• Run II: at tower and trigger sector level

• CSC• Run II: at ROD and chamber level

2/20/2014

8

DAQ-DCS Communication• DT: Data Transfer - CT: Command Transfer - MT: Message Transfer• CSC

• Run I: DT for sending enabled/disabled list at the beginning of the run + MT for checking HV status

• Run II: ? Drop it?

• MDT• Run I: DT for sending enabled/disabled list + MT for sending ‘end of

initialitation’• Run II: ?

• TGC• Run I: ?• Run II: ?

• RPC• Run I: ?• Run II: ?

2/20/2014