Accelerator Neutrinos

Abstract:

The ATLAS inner detector is used to reconstruct secondary vertices due to hadronic interactions of primary collision products, so probing the location and amount of material in the inner region of ATLAS. Data collected in 7 TeV pp collisions at the LHC, with a minimum bias trigger, are used for comparisons with simulated events. The reconstructed secondary vertices have spatial resolutions ranging from ∼ 200μm to 1 mm. The overall material description in the simulation is validated to within an experimental uncertainty of about 7%. This will lead to a better understanding of the reconstruction of various objects such as tracks, leptons, jets, and missing transverse momentum. © 2012 CERN.

Abstract:

The ATLAS Metadata Interface ("AMI") was designed as a generic cataloguing system, and as such it has found many uses in the experiment including software release management, tracking of reconstructed event sizes and control of dataset nomenclature. The primary use of AMI is to provide a catalogue of datasets (file collections) which is searchable using physics criteria. In this paper we discuss the various mechanisms used for filling the AMI dataset and file catalogues. By correlating information from different sources we can derive aggregate information which is important for physics analysis; for example the total number of events contained in dataset, and possible reasons for missing events such as a lost file. Finally we will describe some specialized interfaces which were developed for the Data Preparation coordinators. These interfaces manipulate information from both the dataset domain held in AMI, and the run-indexed information held in the ATLAS COMA application (Conditions and Configuration MetadatA)..

Abstract:

The ATLAS detector at the LHC is used to search for high-mass states, such as heavy charged gauge bosons (Wʹ), decaying to a charged lepton (electron or muon) and a neutrino. Results are presented based on the analysis of pp collisions at a center-of-mass energy of 7 TeV corresponding to an integrated luminosity of 4.7 fb−1. No excess beyond Standard Model expectations is observed. AWʹ with Sequential Standard Model couplings is excluded at the 95% credibility level for masses up to 2.55 TeV. Excited chiral bosons (W*) with equivalent coupling strength are excluded for masses up to 2.42 TeV.

Abstract:

In the ATLAS experiment, a system called COMA (Conditions/Configuration Metadata for ATLAS), has been developed to make globally important run-level metadata more readily accessible. It is based on a relational database storing directly extracted, refined, reduced, and derived information from system-specific database sources as well as information from non-database sources. This information facilitates a variety of unique dynamic interfaces and provides information to enhance the functionality of other systems. This presentation will give an overview of the components of the COMA system, enumerate its diverse data sources, and give examples of some of the interfaces it facilitates. We list important principles behind COMA schema and interface design, and how features of these principles create coherence and eliminate redundancy among the components of the overall system. In addition, we elucidate how interface logging data has been used to refine COMA content and improve the value and performance of end-user reports and browsers..

Abstract:

The ATLAS experiment deployed Frontier technology worldwide during the initial year of LHC collision data taking to enable user analysis jobs running on the Worldwide LHC Computing Grid to access database resident data. Since that time, the deployment model has evolved to optimize resources, improve performance, and streamline maintenance of Frontier and related infrastructure. In this presentation we focus on the specific changes in the deployment and improvements undertaken, such as the optimization of cache and launchpad location, the use of RPMs for more uniform deployment of underlying Frontier related components, improvements in monitoring, optimization of fail-over, and an increasing use of a centrally managed database containing site specific information (for configuration of services and monitoring). In addition, analysis of Frontier logs has allowed us a deeper understanding of problematic queries and understanding of use cases. Use of the system has grown beyond user analysis and subsystem specific tasks such as calibration and alignment, extending into production processing areas, such as initial reconstruction and trigger reprocessing. With a more robust and tuned system, we are better equipped to satisfy the still growing number of diverse clients and the demands of increasingly sophisticated processing and analysis..