MICE Collaboration Meeting Oct05

Mice CM Oct 2005 Jean-Sébastien Graulich Slide 1

MICE Collaboration Meeting Oct05

Review of DAQ Workshop andDAQ Issues

Jean-Sebastien Graulich, Univ. Genève

o Introduction

o Mice Control and Monitoring

o Detector DAQ

o Trigger and data volume

o What happened since the DAQ workshop

o What will happen next

o Summary


IntroductionIntroduction

Some Definitions:Some Definitions: DDAQ: Detector Data Acquisition

Deals mainly with data from detectorsException for RF phase and amplitude

Starts when the data is accessible on the VME busDAQ ≠ Detector Front End !

In particular, the choice of FEE belongs to the detector!DAQ ≠ Trigger System

Ends when the data is on local diskWhat 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)


DAQ Workshop DAQ Workshop (Daresbury)(Daresbury)

Took place at Daresbury, Aug 31 – Sept Took place at Daresbury, Aug 31 – Sept 11

14 people registered14 people registered Workshop goalsWorkshop goals

Overview MICE needs and main issues Decide general orientations for MCM and DDAQ

Key Issues for CMKey Issues for CM Safety Guarantee the stability of

Beam line, including target system RF system Absorbers

Key Issues for DDAQKey Issues for DDAQ Guarantee stability of data taking (no data loss

nor data taking time loss) Guarantee the data quality (integrity and

relevance)

Control System

EquipmentMonitoring

& “Control” System

Human Interface

Human Interface

Human Interface

may not need to be present (all the time)could be buttons/lamps/local mimic

/plug-in terminaluser/global expert/local

DA

QGeneric Control & Generic Control &

MonitoringMonitoring

paul drumm daq&c-ws august/september 2005


About MCMAbout MCM

EPICS has been presented (Brian EPICS has been presented (Brian Martlew)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

EPICSEPICS was found complying with MICE was found complying with MICE requirements and requirements and has been adoptedhas been adopted

MCM update rate should be > 1 HzMCM update rate should be > 1 Hz


To Be Done for MCMTo Be Done for MCM

Refine list of parameters Refine list of parameters Was a goal of WS but not really discussed See talks in CM 11

In particular, from detector groups:In particular, from detector groups: It’s time to think about:

HV systemInterface with EPICS might take some time

Tracker Control interface with EPICSNo problem expected but Should be assigned to

someone


About DDAQ (1)About DDAQ (1)

Main Requirement from the MICE Main Requirement from the MICE proposalproposal

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:-> First Principle:

This is because the readout of 1 event takes several 100 This is because the readout of 1 event takes several 100 µµs…s…

(20 kB of tracker data to transfer)(20 kB of tracker data to transfer)

Detector data Readout must be performed Detector data Readout must be performed at the end of the spillat the end of the spill

Data has to be buffered in the FEE


About DDAQ (2)About DDAQ (2)

-> ADC problem-> 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

stretchingFlash ADC already available from TPG R&D (40 MHz)

Even if the event buffer is large enough, Even if the event buffer is large enough, conventional ADC conventional ADC

can NEVER collect 600 muons/mscan NEVER collect 600 muons/ms


Trigger IssuesTrigger Issues

There is an urgent need for a more There is an urgent need for a more precise Particle-trigger scheme precise Particle-trigger scheme

New task for the same working group

Clarification is neededClarification is needed The word “trigger” is used for 3 different things RF trigger ≠ Readout trigger ≠ Particle trigger Particle trigger = Digitisation trigger

RF Cycle

1 secPULSE !

RF Pulse1 ms

20 ms

Isis Beam Radius

MS

RF Trigger

Target Position

SPILL !

SoS

DAQ gate

EoS~1 ms

DAQ Trigger

DAQ Event !

Particle Events !

“GoodEvent”

(TOF0xTOF1xTOF2)

100 ns

Digitisation Dead time

Particle Trigger

Bursts ! IsisMicrostructure

224 nsShould be ~500 ns

1700 ns on average

Next Particle Trigger

SoS

DAQ gate

EoS~1 ms

DAQ Trigger

DAQ Event !

Particle Events !

“GoodEvent”

(TOF0xTOF1xTOF2)

RF Pulse1 ms

20 ms

Isis Beam Radius

MS

RF Trigger

Target Position

SPILL !


Trigger IssuesTrigger Issues

Main Requirements on DAQ-TriggerMain 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 For Particle-Trigger a natural tt0 0 is Zero is Zero Crossing of RF signalCrossing of RF signal

Make sure we can we get that signal with a 60 ps resolution.


Data VolumeData Volume

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 TBOnline Storage capacity: ~10 TB Easy to set up Allow keeping 1 month of data taking on local

disk

Remote storageRemote storage Not discussed


DAQ Architecture DAQ Architecture ProposalProposal

Trigger distribution

Optical link

Online Monitoring

Tracker EmCal TOFTrigger + Ckovs

Ethernet

Linux PCs

GigaBit Switch

Run ControlEvent BuilderOnline Storage

VME Crates

Remote Storage


DAQ SoftwareDAQ Software

UNIDAQ has been presented (M. Yoshida)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. LHC DAQ software have been reviewed (E. Radicioni)Radicioni)

CMS system is not importable Alice system (DATE) has nice functionalities:

Run control (state machine) with GUIAllows 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 yetNo decision yet


About CM <-> DDAQAbout CM <-> DDAQ

Integration/Interaction between the Integration/Interaction between the two {has been/is/will be} heavily two {has been/is/will be} heavily discussed 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… De facto, separated in the skill space… And also by geography


What Happened since What Happened since ThenThen

DDAQ Testbench 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 EPICS Training has started at RALstarted at RAL

distributionTrigger

Optical link

+ Online Monitoring

Crate1Crate2

Linux PCs

Office Switch

Run Control

+ Event Builder

VME Crates


What happened since What happened since ThenThen

Test beam in KEK (See Makoto’s talk)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

HoweverHowever Event by event readout

-> Not a First Principle validation Only one VME crate

-> Not an architecture validation


What will happen What will happen nextnext

Finalise Mice Note on TerminologyFinalise Mice Note on Terminology DAQ Test bench in Geneva will start in DAQ Test bench in Geneva will start in

in Feb05in Feb05 Next DAQ workshop around CM14 in Next DAQ workshop around CM14 in

Osaka ?Osaka ? Agreement on DDAQ requirements Agreement on DDAQ<->MCM integration

Test beam in Frascati integrating TOF Test beam in Frascati integrating TOF and EmCal (Mai06?)and EmCal (Mai06?)


ConclusionConclusion

Decisions taken in DaresburyDecisions 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 firstTo 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


Seeds for DiscussionSeeds for Discussion

How many events do we really need?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 Which Monitoring data might have an impact on

Physics Analysis ?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 ?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 ?How much data with Beam OFF/RF ON ?


Resting slidesResting slides


On the AgendaOn the Agenda Talks on Control and Monitoring (CM)Talks on Control and Monitoring (CM)

Talks on Detector DAQ (DDAQ)Talks on Detector DAQ (DDAQ)

Talks on integration between CM and DDAQTalks on integration between CM and DDAQ

Beam Line Overview and Needs Drumm

Cooling Channel Overview and Needs Drumm

MICE Safety Systems Ivanyushenkov

EPICS at Daresbury Martlew

EPICS experience at Fermilab Savage

Detector DAQ Overview and Needs Graulich

MICE Trigger Long

KEK Unidaq Yoshida

Experience with Tracker Prototype Ellis

Review of DAQ Software Options Radicioni

Online data quality and monitoring Ellis

Thoughts on MICE DAQ/Control/Monitory integration

Drumm


Workshop Goals (A. Workshop Goals (A. Bross)Bross)

Refine “Physics” parameter ListRefine “Physics” parameter List Further develop an understanding of the D/C/M needs Further develop an understanding of the D/C/M needs

forfor Beam Line Cooling Channel Detectors

Produce Baseline Proposal forProduce Baseline Proposal for DAQ Online System Controls system Monitoring system

Produce Outline for Comprehensive MICE D/C/M Produce Outline for Comprehensive MICE D/C/M specification documentspecification document

Start from MICE-NOTE-GEN-097 (Draft01/JSG) Goal to have draft (0/1?) ready for collaboration

meeting

GIVE SERIOUS CONSIDERATION TOGIVE SERIOUS CONSIDERATION TO EXISTING EXISTING SYSTEMS/SOLUTIONSSYSTEMS/SOLUTIONS


DDAQ RoadmapDDAQ Roadmap

IdeallyIdeally Identify constraints and needs List Use Case and User requirements Write Specification Choose Adapted Hardware and Software Set up a test bench Check performance

RF Phase and Particle RF Phase and Particle detectiondetection

201.25 MHz

5 ns

flat top

10V pulse16 bits:1bit~1in 104

trigger TOF 0 & 1 : 6m@c = ~20ns

TOF 2 : +10m@c = ~50ns

Proposal: • Each cavity generates a Zero crossing point (e.g. -ve slope): • TDC between TOF1 & next Z/C• resolution ~ 5ns/360=14ps/degreeCalibration:• Single cavity: find Emax & Emin

Possible 2 phase ambiguity but does it matter?

Paul Drumm

MICE Collaboration Meeting Oct05

Documents

Transcript of MICE Collaboration Meeting Oct05