1 / 12

Online Event Filter in the ECAL test beam

IASA. Online Event Filter in the ECAL test beam. Nancy Marinelli I.A.S.A.- Athens Credits: EvF Group, R. Alemany, N.Almeida (LIP) TriDAS Week Event Filter Working Group Meeting – 9 Nov 2004. Beam. LV cables. HV cables. Cooling. System under test (1).

linus
Download Presentation

Online Event Filter in the ECAL test beam

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. IASA Online Event Filter in the ECAL test beam Nancy Marinelli I.A.S.A.- Athens Credits: EvF Group, R. Alemany, N.Almeida (LIP) TriDAS Week Event Filter Working Group Meeting – 9 Nov 2004 N. Marinelli IASA-Athens

  2. Beam LV cables HV cables Cooling System under test (1) Full Barrel supermodule: 1700 Xstals=68 towers= 1 DCC Electron beam – 1 Spill (every 14 sec) N. Marinelli IASA-Athens

  3. System under test (2) Token rings 8 and 6 not working Try to fix during long MD, Sat-Tue 23-26 Oct Carry out energy scans and uniform coverage scans in M1 and M2 to Sat 23 Oct N. Marinelli IASA-Athens

  4. Access ORACLE DB for configuration ECAL CRATE SOFTWARE XDAQ Crate software XDAQDStore Device drivers GIII XDAQ FEDkit ROOT POOL DB General DAQ setup at H4 SBS CCS DCC Dcc Gui for Local Tests S-Link ECAL Crate controller & Run Control Guis Java Gui COSINE SOAP msg XDAQ XDAQ ORCA H4DAQ Software BU FU i2o msg N. Marinelli IASA-Athens

  5. General 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 N. Marinelli IASA-Athens

  6. Offline World OnlineWorld COBRA Daq Prototype XDAQ COBRA ORCA *Daq* ORCA COSINE Dependency Offline/Online software integration N. Marinelli IASA-Athens

  7. COSINE XDAQ XDAQ ORCA BU FU GIII XDAQ FEDkit ROOT POOL DB Filter Unit integration (1) A custom BU is used as interface between the FedKit and the standard FU released in COSINE_1_0_0_pre5 • 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 N. Marinelli IASA-Athens

  8. 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 N. Marinelli IASA-Athens

  9. Raw Data to ORCA DIGIs (1) On the FU side, in ORCA -> unformatting and CaloDataFrame (10 25 ns time slices digis ) cache filling POOL persistency for both RawData and Digis No online reconstruction performed • Dets-FEDs association made available in ORCA by Giacomo (CommonDet/DaqDetInterface) only used in a very simplistic way (so far ……) because the concept of DetUnit, needed for the association, is still underway for 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 N. Marinelli IASA-Athens

  10. 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 N. Marinelli IASA-Athens

  11. Online 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 between • POOL 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 take • data this week with beam N. Marinelli IASA-Athens

  12. Offline data access Tested on the standalone setup-up first with DCC data input from file. Successful for both Raw Data and DIGIs Laser Run Raw Data readability from POOL DB verified by parsing the events Unfortunately in the Laser Data runs no DIGIs were stored Only DCC events with NO errors at parsing level were supposed to be stored. In laser runs data from ALL towers were acquired of which many were dead -> all events skipped For the future finer error checking, especially on tower-by-tower base, already implemented N. Marinelli IASA-Athens

More Related