Online Event Filter in the ECAL test beam

EvF Meeting 09/11/2004 N. Marinelli IASA-Athens

1

IASAIASA

Online Event Filter in the ECAL test beam

IASAIASA

Nancy MarinelliI.A.S.A.- Athens

Credits: EvF Group,

R. Alemany, N.Almeida (LIP)

TriDAS Week Event Filter Working Group Meeting – 9 Nov 2004


2

IASAIASA

System under test (1)

Beam LV

cables

HV cables

Cooling

Full Barrel supermodule: 1700 Xstals=68 towers= 1 DCCElectron beam – 1 Spill (every 14 sec)


3

IASAIASA

Token rings 8 and 6 not workingTry to fix during long MD, Sat-Tue 23-26 OctTry to fix during long MD, Sat-Tue 23-26 OctCarry out energy scans and uniform coverage scans in Carry out energy scans and uniform coverage scans in

M1 and M2M1 and M2to Sat 23 Octto Sat 23 Oct

System under test (2)


4

IASAIASA

S-Link

FEDkit

XDAQ

GIII

SB

S

ECAL CRATE SOFTWARE

Devicedrivers

Cratesoftware

XDAQ

Access ORACLE DBfor configuration

XDAQDStoreDcc Gui for Local Tests

ECAL Crate controller &

Run Control Guis

H4DAQSoftware

i2o msg

SOAP msg

Java Gui

BU

XDAQ

FU

XDAQ

ORCA

CC

S

DC

C

COSINE POOL DB

ROOT

General DAQ setup at H4


5

IASAIASAGeneral comments

The exercise has to fit in the official data taking schedule

First integration and data taking attempt last week, during MD, with Laser Data ( i.e. data from all crystals acquired per event ½ supermodule fired by laser, ½ supermodule just pedestals)

In principle FU can run in parallel with the official DAQ. Not tried yet. Hopes for this week to get some beam data on just a crystal tower

First approach: run FedKit and BU-FU on different machines The machine devoted to BU-FU much slower than the other. Request made to run BU-FU together with FedKit

Local installation of ORCA/COBRA/COSINE to be independent from AFS


6

IASAIASA

Online WorldOffline World

COBRA

ORCA

COBRADaq

Prototype

ORCA*Daq*

COSINE

XDAQ

Dependency

Offline/Online software integration


7

IASAIASA

Filter Unit integration (1)

The old BU-FU data protocol (SGL) released in COSINE is preserved,so no need to modify protocol in the FU

Operation of BU and FU at H4 via XdaqWin The FU executive needs to be killed at the end of each run

Fixes to the FU Halt() (from Giacomo) for correctly closing the POOL file in every conditions used. Because of kind of mismatch between the procedure implemented to halt the BU, not always working. Back up solution used

FEDkit

XDAQ

GIII

BU

XDAQ

FU

XDAQ

ORCA

COSINE POOL DB

ROOTA custom BU is used as interface

between the FedKit and the standard FU released in

COSINE_1_0_0_pre5


8

IASAIASA

Filter Unit integration (2)

All tests have been performed standalone before going to H4

A few DCC events taken in the lab were dumped into text file The H4 FedKit application was replaced by a custom application loop over data read from the file mimic the data bursts from the test beam ( # of event per burst configurable) Stable running for up to 20K events ( data from 19 towers ) FU running slows down with increasing number of events per run. Already known. Due to POOL storage. No longer runs tried

A POOL committing interval of 50 events was used. In the standalone test and at H4


9

IASAIASA

Raw Data to ORCA DIGIs (1)

On the FU side, in ORCA -> unformatting and CaloDataFrame (10 25 ns timeOn the FU side, in ORCA -> unformatting and CaloDataFrame (10 25 ns time slices digis ) cache fillingslices digis ) cache filling POOL persistency for both RawData and DigisPOOL persistency for both RawData and Digis No online reconstruction performedNo online reconstruction performed

Dets-FEDs association made available in ORCA by Giacomo Dets-FEDs association made available in ORCA by Giacomo (CommonDet/DaqDetInterface) only used in a very simplistic way (so far ……) (CommonDet/DaqDetInterface) only used in a very simplistic way (so far ……) because the concept of DetUnit, needed for the association, is still underway because the concept of DetUnit, needed for the association, is still underway for Calorimetryfor Calorimetry

So ….. consider Ecal as just one FED. Adequate for this TB application ( 1 DCC/1 supermodule). In ORCA a LazyObserver<DaqEvent> access the FED raw data buffer and length and make them available to the FED un-formatter


10

IASAIASA

Raw Data to ORCA DIGIs (2)

DCCDataParser (final) implemented by N. Almeida and integrated in the more general Calorimetry Daq framework existing in ORCA since 1 year (N.M.) It supersedes the previous implementation based on the DaqData class. Modular. Error checking included. More in Nuno’s slides

If modification to the DCC format design comes up, the parser is very flexible and can be easily updated

After parsing, DCC digis are geometrically mapped into a supermodule arbitrarily chosen in ORCA and they are available for reconstruction


11

IASAIASAOnline Monitoring

Attempt to perform some online monitoring. No reconstruction. Just error monitoring and histograms of digis

Use: DaqMonitor interface for online Monitor objects booking Physics Monitor server and client available in COSINE based on a CDF ROOT-based implementation including a GUI display client

It worked but was not stable. Random crashes observed. Clash betweenPOOL DB writing and online histograms. Emilio says it is an old problem related to ROOT and multy-threads ( with roots in COBRA) which had been solved and it is now back

So no online monitoring for safe data taking if we are allowed to takedata this week with beam


12

IASAIASA

Offline data access

Tested on the standalone setup-up first with DCC data input from Tested on the standalone setup-up first with DCC data input from file. Successful for both Raw Data and DIGIsfile. Successful for both Raw Data and DIGIs Laser Run Raw Data readability from POOL DB verified by parsing Laser Run Raw Data readability from POOL DB verified by parsing the eventsthe events

Unfortunately in the Laser Data runs no DIGIs were storedUnfortunately in the Laser Data runs no DIGIs were stored Only DCC events with NO errors at parsing level were supposed Only DCC events with NO errors at parsing level were supposed toto be stored.be stored. In laser runs data from ALL towers were acquired of whichIn laser runs data from ALL towers were acquired of which many were dead -> all events skippedmany were dead -> all events skipped

For the future finer error checking, especially on tower-by-tower For the future finer error checking, especially on tower-by-tower base, already implementedbase, already implemented

Documents

Online Event Filter in the ECAL test beam