1 / 8

Focus on 3 Global items

Focus on 3 Global items. Muon Week, CERN 17-21 February 2014 Nicoletta Garelli ( SLAC). 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

petronella-meris
Download Presentation

Focus on 3 Global items

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Focus on 3 Global items Muon Week, CERN 17-21 February 2014 NicolettaGarelli (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

  3. Wainer’s slide

  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

  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

  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.

  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

  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: ?

More Related