1 / 26

MICE Collaboration Meeting Oct05

MICE Collaboration Meeting Oct05. Review of DAQ Workshop and DAQ Issues. Jean-Sebastien Graulich, Univ. Genève. Introduction Mice Control and Monitoring Detector DAQ Trigger and data volume What happened since the DAQ workshop What will happen next Summary. Introduction.

orly
Download Presentation

MICE Collaboration Meeting Oct05

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. MICE Collaboration Meeting Oct05 Review of DAQ Workshop andDAQ Issues Jean-Sebastien Graulich, Univ. Genève • Introduction • Mice Control and Monitoring • Detector DAQ • Trigger and data volume • What happened since the DAQ workshop • What will happen next • Summary Jean-Sébastien Graulich

  2. Introduction • Some Definitions: • DDAQ: Detector Data Acquisition • Deals mainly with data from detectors Exception for RF phase and amplitude • Starts when the data is accessible on the VME bus DAQ ≠ Detector Front End ! In particular, the choice of FEE belongs to the detector! DAQ ≠ Trigger System • Ends when the data is on local disk What is after (Remote Storage) is not covered • MCM: Mice Control and Monitoring • Should run constantly, giving status of MICE beam line, cooling channel and detector condition. • Related to safety • Long parameter list with very different hardware (from simple temperature probe to the status of standalone control subsystems) Jean-Sébastien Graulich

  3. DAQ Workshop (Daresbury) • Took place at Daresbury, Aug 31 – Sept 1 • 14 people registered • Workshop goals • Overview MICE needs and main issues • Decide general orientations for MCM and DDAQ • Key Issues for CM • Safety • Guarantee the stability of • Beam line, including target system • RF system • Absorbers • Key Issues for DDAQ • Guarantee stability of data taking (no data loss nor data taking time loss) • Guarantee the data quality (integrity and relevance) Jean-Sébastien Graulich

  4. Generic Control & Monitoring Monitoring & “Control” System Control System Equipment DAQ Human Interface Human Interface Human Interface may not need to be present (all the time) could be buttons/lamps/local mimic /plug-in terminal expert/local user/global paul drumm daq&c-ws august/september 2005

  5. About MCM • EPICS has been presented (Brian Martlew) • Experimental Physics and Industrial Control System • Software framework for control and monitoring • Free, Open Source • Based on Channel Access protocol • Large user community in physics : • Advanced Photon Source (Argonne), PSI, DESY, LBL, LANL, Jefferson Lab, KEK B-Factory • Expertise available • Daresbury and D0 at FNAL • EPICS was found complying with MICE requirements and has been adopted • MCM update rate should be > 1 Hz Jean-Sébastien Graulich

  6. To Be Done for MCM • Refine list of parameters • Was a goal of WS but not really discussed • See talks in CM 11 • In particular, from detector groups: • It’s time to think about: • HV system Interface with EPICS might take some time • Tracker Control interface with EPICS No problem expected but Should be assigned to someone Jean-Sébastien Graulich

  7. About DDAQ (1) • Main Requirement from the MICE proposal • The system should allow the acquisition of about 1000 muons/Spill (1 ms Spill per second) • Already reduced to 600 muons/Spill (originally because of expected beam problems) • -> First Principle: This is because the readout of 1 event takes several 100 µs… (20 kB of tracker data to transfer) Detector data Readout must be performed at the end of the spill Data has to be buffered in the FEE Jean-Sébastien Graulich

  8. About DDAQ (2) • -> ADC problem • Average Time between 2 muons is 1.7 µs • Conversion time for conventional ADC > ~3 µs • Critical for EmCal, worrying for Tracker • Possible Solution: Flash ADC after Signal stretching Flash ADC already available from TPG R&D (40 MHz) Even if the event buffer is large enough, conventional ADC can NEVER collect 600 muons/ms Jean-Sébastien Graulich

  9. Trigger Issues • There is an urgent need for a more precise Particle-trigger scheme • New task for the same working group • Clarification is needed • The word “trigger” is used for 3 different things • RF trigger ≠ Readout trigger ≠ Particle trigger • Particle trigger = Digitisation trigger Jean-Sébastien Graulich

  10. Trigger Issues • Main Requirements on DAQ-Trigger • Should be flexible (allow calibration, cosmic events, etc…) • Should allow partitioning (Data acquisition only from a subsystem) • For Particle-Trigger a natural t0 is Zero Crossing of RF signal • Make sure we can we get that signal with a 60 ps resolution. Jean-Sébastien Graulich

  11. Data Volume • Data Volume: • 40 kB/μ (2 kB/μ if zero suppression in the tracker) • ~25 MB/spill or 40 GB/run • ~ 100 TB/year (2500 runs) • Online Storage capacity: ~10 TB • Easy to set up • Allow keeping 1 month of data taking on local disk • Remote storage • Not discussed Jean-Sébastien Graulich

  12. DAQ Architecture Proposal Trigger distribution Tracker EmCal TOF VME Crates Trigger + Ckovs Optical link Linux PCs Ethernet GigaBit Switch Remote Storage Online Online Storage Event Builder Monitoring Run Control Jean-Sébastien Graulich

  13. DAQ Software • UNIDAQ has been presented (M. Yoshida) • Works very well for Test Beam • Would require to write an Event Builder (a lot of work) • LHC DAQ software have been reviewed (E. Radicioni) • CMS system is not importable • Alice system (DATE) has nice functionalities: • Run control (state machine) with GUI Allows to Configure DAQ topology, select trigger, communicate with Slow Control • Allow Partitioning of Event Building • DAQ performance check with GUI • Framework for online monitoring • Logging of DAQ-generated messages • No decision yet Jean-Sébastien Graulich

  14. About CM <-> DDAQ • Integration/Interaction between the two {has been/is/will be} heavily discussed • No Decision yet • Data from each single spill should be validated by the MCM system • MCM should be able to interrupt data taking • Many data values don’t have to be archived. For many parameters, an “all OK” tag is enough • Environment data needed for detector calibration require special attention • Included in the data file ? • Or logged elsewhere and linked by time stamp? • De facto, separated in the skill space… • And also by geography Jean-Sébastien Graulich

  15. What Happened since Then Trigger distribution Crate1 VME Crates • DDAQ Testbench • Started in Geneva • Hardware ordered • It will probably fixed the choice of VME-PCI interface: CAEN V2718 • Crates delivery in February • EPICS Training has started at RAL Crate2 Optical link Linux PCs Office Switch Run Control + Event Builder + Online Monitoring Jean-Sébastien Graulich

  16. What happened since Then • Test beam in KEK (See Makoto’s talk) • Half tracker FEE electronics -> Good Estimation of readout time of the tracker > 6.5 ms per event (10 kB) ! (x 2 for full tracker) Average transfer rate: 1.5 MB/s SBS Bit3 interface should be able to do better -> Slowed down by Unidaq ? Can be improved: - CAEN interface - DMA transfer However • Event by event readout -> Not a First Principle validation • Only one VME crate -> Not an architecture validation Jean-Sébastien Graulich

  17. What will happen next • Finalise Mice Note on Terminology • DAQ Test bench in Geneva will start in in Feb05 • Next DAQ workshop around CM14 in Osaka ? • Agreement on DDAQ requirements • Agreement on DDAQ<->MCM integration • Test beam in Frascati integrating TOF and EmCal (Mai06?) Jean-Sébastien Graulich

  18. Conclusion • Decisions taken in Daresbury • MCM will be based on Epics • DAQ will be based on VME bus • We’ll use PC under Linux • Detector Readout at the end of the spill • The same group will work on the trigger system • To be done first • Obtain a solid proposal for FEE • Specifications for DDAQ, including trigger system -> Choice of DDAQ software framework • Finalise discussion on DDAQ/CM interconnection Jean-Sébastien Graulich

  19. Seeds for Discussion • How many events do we really need? • Nacq ~ 1/(tav+tdead) ; tav = average time between two µ • tav is limited by rate in TOF0 and by the probability to have 2 muons in the same burst: tav > 1 µs (1000 good µ) • Example: tdead=2.8 ms -> Nacq=~240 • Which Monitoring data might have an impact on Physics Analysis ? • Environment: P, T • Magnetic fields • Low level alarms: Some parameter (like HV) slightly out of range. Not serious enough to stop the run but we could want to veto the spill offline • Target depth ? • Other ? • How much data with Beam ON/RF OFF ? • 1/1, 1/2, 1/4 w.r.t. Beam ON/RF ON? • How much data with Beam OFF/RF ON ? Jean-Sébastien Graulich

  20. Resting slides Jean-Sébastien Graulich

  21. On the Agenda • Talks on Control and Monitoring (CM) • Talks on Detector DAQ (DDAQ) • Talks on integration between CM and DDAQ Jean-Sébastien Graulich

  22. Workshop Goals (A. Bross) • Refine “Physics” parameter List • Further develop an understanding of the D/C/M needs for • Beam Line • Cooling Channel • Detectors • Produce Baseline Proposal for • DAQ Online System • Controls system • Monitoring system • Produce Outline for Comprehensive MICE D/C/M specification document • Start from MICE-NOTE-GEN-097 (Draft01/JSG) • Goal to have draft (0/1?) ready for collaboration meeting • GIVE SERIOUS CONSIDERATION TOEXISTING SYSTEMS/SOLUTIONS Jean-Sébastien Graulich

  23. DDAQ Roadmap • Ideally • Identify constraints and needs • List Use Case and User requirements • Write Specification • Choose Adapted Hardware and Software • Set up a test bench • Check performance Jean-Sébastien Graulich

  24. RF Phase and Particle detection trigger TOF 0 & 1 : 6m@c = ~20ns TOF 2 : +10m@c = ~50ns Possible 2p phase ambiguity but does it matter? 5 ns 201.25 MHz • Proposal: • Each cavity generates a • Zero crossing point (e.g. -ve slope): • TDC between TOF1 & next Z/C • resolution ~ 5ns/360=14ps/degree • Calibration: • Single cavity: find Emax & Emin flat top 10V pulse 16 bits: 1bit~1in 104 Paul Drumm

More Related