13 research outputs found
Software release build process and components in ATLAS offline - proceedings for CHEP2010
No full textATLAS is one of the largest collaborations in the physical sciences and involves 3000 scientists and engineers from 174 institutions in 38 countries. The geographically dispersed developer community has produced a large amount of software which is organized in 10 projects. In this presentation we discuss how the software is built on a variety of compiler and operating system combinations every night. File level and package level parallelism together with multi-core build servers are used to perform fast builds of the different platforms in several branches. We discuss the different tools involved during the software release build process and also the various mechanisms implemented to provide performance gains and error detection and retry mechanisms in order to counteract network and other instabilities that would otherwise degrade the robustness of the system. The goal is to provide high quality software built as fast as possible ready for final validation and deploymen
Software Release Build Process and Components in ATLAS Offline.
No full textATLAS is one of the largest collaborations in the physical sciences. The collaboration involves 3000 scientists and engineers from 174 institutions in 38 countries. This geographically dispersed developer community produces a huge amount of software. The ATLAS Offline software code is organized in 10 projects and in this presentation we discuss how the software is built on variety of compiler and operating system combinations every night. File level parallelism and package level parallelism together with multi-core build servers are used to perform fast builds of the different platforms in several branches. We discuss the different tools involved during the software release build process and also the various mechanisms implemented to provide performance gains and error detection and retry mechanisms in order to counteract network and other instabilities that would otherwise degrade the robustness of the system. We provide to our developers and user quality software built as fast as possible ready for tests and production
A Roadmap to Continuous Integration for ATLAS Software Development
No full textThe ATLAS software infrastructure facilitates efforts of more than 1000 developers working on the code base of 2200 packages with 4 million C++ and 1.4 million python lines. The ATLAS offline code management system is the powerful, flexible framework for processing new package versions requests, probing code changes in the Nightly Build System, migration to new platforms and compilers, deployment of production releases for worldwide access and supporting physicists with tools and interfaces for efficient software use. It maintains multi-stream, parallel development environment with about 70 multi-platform branches of nightly releases and provides vast opportunities for testing new packages, for verifying patches to existing software and for migrating to new platforms and compilers. The system evolution is currently aimed on the adoption of modern continuous integration (CI) practices focused on building nightly releases early and often, with rigorous unit and integration testing. This presentation describes the CI incorporation program for the ATLAS software infrastructure. It brings modern open source tools such as Jenkins and CTest into the ATLAS Nightly System, rationalizes hardware resource allocation and administrative operations, provides improved feedback and means to fix broken builds promptly for developers. Once adopted, ATLAS CI practices will improve and accelerate innovation cycles and result in increased confidence in new software deployments. The presentation reports the status of Jenkins integration with the ATLAS Nightly System as well as short and long term plans for the incorporation of CI practices
Large Scale Software Building with CMake in ATLAS
No full textThe offline software of the ATLAS experiment at the LHC (Large Hadron Collider) serves as the platform for detector data reconstruction, simulation and analysis. It is also used in the detector trigger system to select LHC collision events during data taking. ATLAS offline software consists of several million lines of C++ and Python code organized in a modular design of more than 2000 specialized packages. Because of different workflows many stable numbered releases are in parallel production use. To accommodate specific workflow requests, software patches with modified libraries are distributed on top of existing software releases on a daily basis. The different ATLAS software applications require a flexible build system that strongly supports unit and integration tests. Within the last year this build system was migrated to CMake. A CMake configuration has been developed that allows one to easily set up and build the mentioned software packages. This also makes it possible to develop and test new and modified packages on top of existing releases. The system also allows one to detect and execute partial rebuilds of the release based on single package changes. The build system makes use of CPack for building RPM packages out of the software releases, and CTest for running unit and integration tests. We report on the migration and integration of the ATLAS software to CMake and show working examples of this large scale project in production
Experience with C++ Code Quality in ATLAS
No full textAn explanation of tools used for code quality checking in Atlas offline software, including results and responses is given. The principle tools covered are: Coverity, cppcheck, 'include what you use', Undefined Behaviour Sanitize
ATLAS Distributed Computing: Its Central Services core
No full textThe ATLAS Distributed Computing (ADC) Project is responsible for the off-line processing of data produced by the ATLAS experiment at the Large Hadron Collider (LHC) at CERN. It facilitates data and workload management for ATLAS computing on the Worldwide LHC Computing Grid (WLCG). ADC Central Services operations (CSops)is a vital part of ADC, responsible for the deployment and configuration of services needed by ATLAS computing and operation of those services on CERN IT infrastructure, providing knowledge of CERN IT services to ATLAS service managers and developers, and supporting them in case of issues. Currently this entails the management of thirty seven different OpenStack projects, with more than five thousand cores allocated for these virtual machines, as well as overseeing the distribution of twenty nine petabytes of storage space in EOS for ATLAS. As the LHC begins to get ready for the next long shut-down, which will bring in many new upgrades to allow for more data to be captured by the on-line systems, CSops must not only continue to support the existing services, but plan ahead for the expected increase in data, users, and services that will be required. In this paper we explain the current state of CSops as well as the systems put in place to maintain the services provided
C++ Software Quality in the ATLAS experiment
No full textIn this paper we explain how the C++ code quality is managed in ATLAS using a range of tools from compile-time through to run time testing and reflect on the substantial progress made in the last two years largely through the use of static analysis tools such as Coverity®, an industry-standard tool which enables quality comparison with general open source C++ code. Other available code analysis tools are also discussed, as is the role of unit testing with an example of how the googlemock framework can be applied to our codebase
БОЛЕСТТА AMOR HEREOS В СРЕДНОВЕКОВНИЯ РОМАН HISTORIA DE JACOBO XALABÍN
No full textThe History of Jacobo Xalabín (La historia de Jacobo Xalabín) is a medieval anonymous novel written in the Catalan language. According to the latest research, it dates between 1492 and 1536. The narrator takes us to the court of Sultan Murad I in 1387. Sultan Yakub's first-born son rejects the love of his stepmother Isa Celebina, as a result of which she falls ill. Advised by the only doctor who discovered the cause of her illness – the Jew Kir Moshe, in order to cure her, they planned the death of Yakub Celebi. Although the inclusion of Isa Chelebina's illness in the narrative is only one of its elements, accurate conclusions can be drawn from the narrative about the level of modern medical practice at that time in the examination of patients, the treatment of identified diseases and the imposition of certain stereotypes regarding the qualifications of doctors in different countries. Added to them is the clearly expressed personal attitude of the author towards certain ethnic and religious types – the Christian wife of the ruler Isa Celebina, and the doctor from Constantinople, the Jew Kir Moshe
