Accelerator Neutrinos

Abstract:

A search for a narrow Higgs boson resonance in the diphoton mass spectrum is presented based on data corresponding to 7.0fb-1 of integrated luminosity from pp̄ collisions at √s=1.96TeV collected by the CDF experiment. No evidence of such a resonance is observed, and upper limits are set on the cross section times branching ratio of the resonant state as a function of Higgs boson mass. The limits are interpreted in the context of the standard model and one fermiophobic benchmark model where the data exclude fermiophobic Higgs bosons with masses below 114GeV/c2 at a 95% Bayesian credibility level. © 2012 American Physical Society.

Abstract:

The volume and diversity of metadata in an experiment of the size and scope of ATLAS are considerable. Even the definition of metadata may seem context-dependent: data that are primary for one purpose may be metadata for another. ATLAS metadata services must integrate and federate information from inhomogeneous sources and repositories, map metadata about logical or physics constructs to deployment and production constructs, provide a means to associate metadata at one level of granularity with processing or decision-making at another, offer a coherent and integrated view to physicists, and support both human use and programmatic access. In this paper we consider ATLAS metadata, metadata services, and metadata flow principally from the illustrative perspective of how disparate metadata are made available to executing jobs and, conversely, how metadata generated by such jobs are returned. We describe how metadata are read, how metadata are cached, and how metadata generated by jobs and the tasks of which they are a part are communicated, associated with data products, and preserved. We also discuss the principles that guide decision-making about metadata storage, replication, and access..

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..