The ATLAS DAQ and event filter prototype “−1” project

Ambrosini, G.; Burckhart, D.; Caprini, M.; Cobal, M.; Duval, P.Y.; Etienne, F.; Ferrari, R.; Francis, D.; Jones, R.; Joos, M.; Kolos, S.; Lacourt, A.; Suu, A. Le van; Mailov, A.; Mapelli, L.; Michelotto, M.; Mornacchi, G.; Nacasch, R.; Niculescu, M.; Nurdan, K.; Ottavi, C.; Patel, Arpita; Pennerath, Frédéric; Petersen, J.; Polesello, G.; Prigent, Daniel; Qian, Z.; Rochez, J.; Scuri, F.; Skiadelli, M.; Soloviev, I.; Spiwoks, R.; Touchard, F.; Tremblet, L.; Ünel, G.; Vercesi, V.; Wheeler, S.; Wildish, A.

doi:10.1016/s0010-4655(97)00160-4

Cited by 11 publications

(6 citation statements)

References 1 publication

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The DAQ system and its predecessors (CERN R&D 13 group [2], ATLAS DAQ Prototype-1 Project [3]) had evaluated several shareware and commercial candidates for the configuration service, including persistent object managers, object and relational databases, but no system satisfying all the requirements was found [4]. Therefore it was decided to use as a prototype an existing object manager OKS [5] and make it capable of fulfilling the DAQ configuration service needs.…”

Section: Configuration Service Implementationmentioning

confidence: 99%

The ATLAS DAQ system online configurations database service challenge

Almeida¹,

Dobson

Kazarov

et al. 2008

J. Phys.: Conf. Ser.

View full text Add to dashboard Cite

The ATLAS DAQ system online configurations database service challenge Igor.Soloviev@cern.chAbstract. This paper describes challenging requirements on the configuration service for the ATLAS experiment at CERN. It presents the status of the implementation and testing one year before the start of data taking, providing details of: the capabilities of underlying OKS object manager to store and to archive configuration descriptions, its user and programming interfaces; the organization of configuration descriptions for different types of data taking runs and combinations or participating sub-detectors; the scalable architecture to support simultaneous access to the service by thousands of processes during the online configuration stage of ATLAS; the experience with the usage of the configuration service during large scale tests, test beam, commissioning and technical runs. The paper also presents pro and contra of the chosen object-oriented implementation comparing with solutions based on pure relational database technologies, and explains why after several years of usage we continue with our approach. IntroductionThe configurations database service described in the paper is a part of the ATLAS High-Level Trigger, Data Acquisition (DAQ) and Controls system [1]. It is used to provide the overall description of the DAQ system and partial description of the trigger and detectors software and hardware. Such descriptions cover the control-oriented configuration of all ATLAS processes running during data taking (including information such as: which parts of the ATLAS systems and detectors are participating in a given run, when and where processes shall be started, what run-time environment to be created for each of them, how to check status of running processes and to recover run-time errors, when and in what order to shut down running processes, etc.) and provide configuration parameters for many of them (overall DAQ data-flow configuration, online monitoring configuration, connectivity and parameters for various DAQ, trigger and detector modules, chips and channels).

show abstract

Section: Configuration Service Implementationmentioning

confidence: 99%

The ATLAS DAQ system online configurations database service challenge

Almeida¹,

Dobson

Kazarov

et al. 2008

J. Phys.: Conf. Ser.

View full text Add to dashboard Cite

show abstract

“…An implementation of partitioning using CORBA Naming Servicc was included in tlic IPC package [12] and uscd hy a11 back-end components, giving the devclopcrs the possibility to run tests in parallcl. Component specific dcveluper interfaccs (in Motii) and thc intcgratcd graphical user interlace (in liwa) haw bccn used during the tCStS.…”

Section: Diugnorrics Packagementioning

confidence: 99%

Performance and scalability of the back-end sub-system in the ATLAS DAQ/EF prototype

Aleksandrov

Amorim²,

Badescu³

et al. 2000

IEEE Trans. Nucl. Sci.

Self Cite

View full text Add to dashboard Cite

Thc DAQ group of the futurc ATLAS experiment has developed a prototype system based on the TriggerIDAQ architccturc descrihctl in tlic ATLAS Technical Propusal [I] to support studios of the full system lunctionality, nrchitccturc BS wcll as availnhlc hardware and software technologies.Onc sub-systcm of this prototype is thc hack-end which cncompasses the softwarc nccdcd to configure, control and monitor tlic DAQ, hut cxcludcs lhc processing and transportation of physics data.The back-end consists OS a number of coinponents including run control, configuration datahascs and messago reporting system. l'hc softwnrc has hccn dcvelnped using standard, external softwnrc technologies such as 00 databases and CORHA. It has been portcrl to several C++ compilers and opcrating systcms including Solaris, Linux, WNT and LynxOS. This paper gives an ovcrvicw of thc hack-end software, its performance, scalability and current status.

show abstract

“…The proposed architecture comprises of five subsystems one of which is the online software system, a system Manuscript based on the design of the back-end subsystem of the ATLAS DAQ/EF-1 project [2], [3]. The online software system is responsible for overall experiment control, including run control, configuration of the HLT/DAQ system and management of data-taking partitions.…”

Section: Introductionmentioning

confidence: 99%

Process Management inside ATLAS DAQ

Aleksandrov

Amorim

Badescu

et al. 2002

IEEE Trans. Nucl. Sci.

Self Cite

View full text Add to dashboard Cite

The Process Management component of the online software of the future ATLAS experiment data acquisition system is presented. The purpose of the Process Manager is to perform basic job control of the software components of the data acquisition system. It is capable of starting, stopping and monitoring the status of those components on the data acquisition processors independent of the underlying operating system. Its architecture is designed on the basis of a server client model using CORBA based communication. The server part relies on C++ software agent objects acting as an interface between the local operating system and client applications.Some of the major design challenges of the software agents were to achieve the maximum degree of autonomy possible, to create processes aware of dynamic conditions in their environment and with the ability to determine corresponding actions. Issues such as the performance of the agents in terms of time needed for process creation and destruction, the scalability of the system taking into consideration the final ATLAS configuration and minimizing the use of hardware resources were also of critical importance.Besides the details given on the architecture and the implementation, we also present scalability and performance tests results of the Process Manager system.

show abstract

The ATLAS DAQ and event filter prototype “−1” project

Cited by 11 publications

References 1 publication

The ATLAS DAQ system online configurations database service challenge

The ATLAS DAQ system online configurations database service challenge

Performance and scalability of the back-end sub-system in the ATLAS DAQ/EF prototype

Process Management inside ATLAS DAQ

Contact Info

Product

Resources

About