DAQ thoughts about upgrade 11/07/2012

What we would like to see in a future framework (1)  Unique database for online and offline configs and calib, include data valid for current run (for DA and DQM per instance)  Data traceability : calibration -> ocdb -> application (keep track of calibration and config used for run N)  Unify data format that could be used throughout systems (from LDC). If two format (like raw and ROOT, then transparent conversion from one to the other)  Review our policy on dropping incomplete events  Single lib/interface to read/write data (local, castor, tags, indexes)

What we would like to see in a future framework (2)  Independent modules of reasonnable size  Make use of new available online CPU (for reco or analysis)  Dynamic adaptation of algorithms to available online resources (e.g. online reco on event building cpus for a fraction of events)  DQM-QA merge : unique system usable online and offline for all QA related tasks.  DQM : Reco online of events and storage of results for later. Completion of QA offline, but first X % online.  Multithreading

Common Procedures (1)  Not necessarily common hardware or facilities !  E.g. same build system know-how but different instances  Release numbering  Build system & Packaging  Tools  e.g. cmake, svn, rpm, yum, ticket system  Dependencies handling (aliroot version to use in prod/test)  Benchmark (ref sys and tools)  Mock modules

Common Procedures (2)  Code access policy (open-source ? Commit rights ?)  Languages (C++, standard libraries STL/Boost, ROOT)  OS (Production farm and desktops ; SLC, Ubuntu, Mac OS, Windows, mobile)  HW (x86_64, GPUs, virtualisation)  Storage (cloud ?)  Core language features (e.g. log / printf / cout)  Coding guidelines and standards

Current daq tools or features that could be used/replaced by a common framework  Data validity checks, e.g. what we have in the readout now  Infologger  Logbook (common source of information for online and offline)  FXS (Move data around at runtime between system)  Publish-Subscribe and notification mechanism (now DIM)  Process control  AMORE (online DQM allowing parallel execution of detector code, collection of results and visualization through custom, generic and web user interfaces)

New DAQ  Replay and inject events at any level (testing, benchmarking, mock)  Started a prototype of a new DAQ system based on modular IO boxes  Few types of modules: event producer, consumer, filter  C++ base classes provide common needs: FIFOs, thread pools, process control  Inheritance + virtual methods to implement custom behavior of each module  Flexible description of modules interconnects to instantiate different DAQ systems

Answers to Matthias’ questions  Max data recording : 4GB (4x10Gbits fibers to CASTOR)  Limiting factor : bandwidth to CASTOR (4 vs >8 GB locally)  Easy scale up of the system (more LDCs and GDCs) and hardware evolution  Other « DAQ » group services : ACT, ECS, FXS, Logbook, DQM, DA, ACR stations, InfoLogger, DIP

Conclusion  We are looking for topics of reflexion and debate, discussions and definition of architecture and common processes, but not for direct technical solution or implementation.  The Panel should also define the processes of R&D for what will follow the Panel’s work and provide requirements.