Abstract
The Condition Database plays a key role in the CMS computing infrastructure. The complexity of the detector and the variety of the sub-systems involved are setting tight requirements for handling the Conditions. In the last two years the collaboration has put a substantial effort in the re-design of the Condition Database system, with the aim at improving the scalability and the operability for the data taking starting in 2015. The re-design has focused on simplifying the architecture, using the lessons learned during the operation of the Run I data-taking period (20092013). In the new system the relational features of the database schema are mainly exploited to handle the metadata (Tag and Interval of Validity), allowing for a limited and controlled set of queries. The bulk condition data (Payloads) are stored as unstructured binary data, allowing the storage in a single table with a common layout for all of the condition data types. In this paper, we describe the full architecture of the system, including the services implemented for uploading payloads and the tools for browsing the database. Furthermore, the implementation choices for the core software will be discussed.
Highlights
The “Conditions” are non-event data resulting from calibration and alignment algorithms
CMS has implemented a new infrastructure for the management of the condition data for Run II
The data model has been simplified into only a few entities: Payload, Record, Interval Of Validity (IOV), Tag and Global Tag
Summary
The “Conditions” are non-event data resulting from calibration and alignment algorithms. They vary with time and they need to be accessible by physicist within the offline event-processing applications. The CMS computing infrastructure has a dedicated software system managing such data, called Condition Database. The successful CMS Run I data taking (2009-2013) has lead to the discovery of the Higgs Boson in 2012. During this period, the Condition Database has been used at a very large scale. The significant operational effort that the infrastructure required has motivated a re-design towards the Run II phase. The goal was to provide the experiment with a lighter and more operational structure
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
