Using Xrootd to Federate Regional Storage Bauerdick, L; Benjamin, D; Bloom, K ...
Journal of physics. Conference series,
01/2012, Letnik:
396, Številka:
4
Journal Article, Conference Proceeding
Recenzirano
Odprti dostop
While the LHC data movement systems have demonstrated the ability to move data at the necessary throughput, we have identified two weaknesses: the latency for physicists to access data and the ...complexity of the tools involved. To address these, both ATLAS and CMS have begun to federate regional storage systems using Xrootd. Xrootd, referring to a protocol and implementation, allows us to provide data access to all disk-resident data from a single virtual endpoint. This “redirector” discovers the actual location of the data and redirects the client to the appropriate site. The approach is particularly advantageous since typically the redirection requires much less than 500 milliseconds and the Xrootd client is conveniently built into LHC physicists’ analysis tools. Currently, there are three regional storage federations - a US ATLAS region, a European CMS region, and a US CMS region. The US ATLAS and US CMS regions include their respective Tier 1, Tier 2 and some Tier 3 facilities; a large percentage of experimental data is available via the federation. Additionally, US ATLAS has begun studying low-latency regional federations of close-by sites. From the base idea of federating storage behind an endpoint, the implementations and use cases diverge. The CMS software framework is capable of efficiently processing data over high-latency links, so using the remote site directly is comparable to accessing local data. The ATLAS processing model allows a broad spectrum of user applications with varying degrees of performance with regard to latency; a particular focus has been optimizing n-tuple analysis. Both VOs use GSI security. ATLAS has developed a mapping of VOMS roles to specific file system authorizations, while CMS has developed callouts to the site's mapping service. Each federation presents a global namespace to users. For ATLAS, the global-to-local mapping is based on a heuristic-based lookup from the site's local file catalog, while CMS does the mapping based on translations given in a configuration file. We will also cover the latest usage statistics and interesting use cases that have developed over the previous 18 months.
A Third Party Copy (TPC) mechanism has existed in the pure XRootD storage environment for many years. However, using the XRootD TPC in the WLCG environment presents additional challenges due to the ...diversity of the storage systems involved such as EOS, dCache, DPM and ECHO, requiring that we carefully navigate the unique constraints imposed by these storage systems and their site-specific environments through customized configuration and software development. To support multitenant setups seen at many WLCG sites, X509 based authentication and authorization in XRootD was significantly improved to meet both security and functionality requirements. This paper presents architecture of the pull based TPC with optional X509 credential delegation, and how it is implemented in native XRootD and dCache. The paper discusses technical requirements, challenges, design choices and implementation details in the WLCG storage systems, as well as in FTS/gfal2. It also outlines XRootD’s plan to support newer TPC and security models such as token based authorization.
The shared memory architecture of multicore CPUs provides HEP developers with the opportunity to reduce the memory footprint of their applications by sharing memory pages between the cores in a ...processor. ATLAS pioneered the multi-process approach to parallelize HEP applications. Using Linux fork() and the Copy On Write mechanism we implemented a simple event task farm, which allowed us to achieve sharing of almost 80% of memory pages among event worker processes for certain types of reconstruction jobs with negligible CPU overhead. By leaving the task of managing shared memory pages to the operating system, we have been able to parallelize large reconstruction and simulation applications originally written to be run in a single thread of execution with little to no change to the application code. The process of validating AthenaMP for production took ten months of concentrated effort and is expected to continue for several more months. Besides validating the software itself, an important and time-consuming aspect of running multicore applications in production was to configure the ATLAS distributed production system to handle multicore jobs. This entailed defining multicore batch queues, where the unit resource is not a core, but a whole computing node; monitoring the output of many event workers; and adapting the job definition layer to handle computing resources with different event throughputs. We will present scalability and memory usage studies, based on data gathered both on dedicated hardware and at the CERN Computer Center.
In this contribution, the model of shared ATLAS Tier-2 and Tier-3 facilities is explained. Data taking in ATLAS has been going on for more than two years. The Tier-2 and Tier-3 facility setup, how do ...we get the data, how do we enable at the same time Grid and local data access, how Tier-2 and Tier-3 activities affect the cluster differently and process of hundreds of millions of events, are described. Finally, an example of how a real physics analysis is working at these sites is shown, and this is a good occasion to see if we have developed all the Grid tools necessary for the ATLAS Distributed Computing community, and in case we do not, to try to fix it, in order to be ready for the foreseen increase in ATLAS activity in the next years.
The shared memory architecture of multicore CPUs provides HEP developers with the opportunity to reduce the memory footprint of their applications by sharing memory pages between the cores in a ...processor. ATLAS pioneered the multi-process approach to parallelize HEP applications. Using Linux fork() and the Copy On Write mechanism we implemented a simple event task farm, which allowed us to achieve sharing of almost 80% of memory pages among event worker processes for certain types of reconstruction jobs with negligible CPU overhead. By leaving the task of managing shared memory pages to the operating system, we have been able to parallelize large reconstruction and simulation applications originally written to be run in a single thread of execution with little to no change to the application code. The process of validating AthenaMP for production took ten months of concentrated effort and is expected to continue for several more months. Besides validating the software itself, an important and time-consuming aspect of running multicore applications in production was to configure the ATLAS distributed production system to handle multicore jobs. This entailed defining multicore batch queues, where the unit resource is not a core, but a whole computing node; monitoring the output of many event workers; and adapting the job definition layer to handle computing resources with different event throughputs. We will present scalability and memory usage studies, based on data gathered both on dedicated hardware and at the CERN Computer Center.
AthenaMP is the multi-core implementation of the ATLAS software framework and allows the efficient sharing of memory pages between multiple threads of execution. This has now been validated for ...production and delivers a significant reduction on the overall application memory footprint with negligible CPU overhead. Before AthenaMP can be routinely run on the LHC Computing Grid it must be determined how the computing resources available to ATLAS can best exploit the notable improvements delivered by switching to this multi-process model. A study into the effectiveness and scalability of AthenaMP in a production environment will be presented. Best practices for configuring the main LRMS implementations currently used by grid sites will be identified in the context of multi-core scheduling optimisation.
Using data collected with the CLEO detector operating at the CESR e+e- collider at sqrts=3.97-4.26 GeV, we investigate 15 charmonium decay modes of the psi(4040), psi(4160), and Y(4260) resonances. ...We confirm, at 11 sigma significance, the BABAR Y(4260)-->pi+pi- J/psi discovery, make the first observation of Y(4260)--> pi(0)pi(0) J/psi (5.1 sigma), and find the first evidence for Y(4260)-->K+K- J/psi(3.7 sigma). We measure e+e- cross sections at sqrts=4.26 GeV as sigma(pi+pi- J/psi)=58(+12)(-10)+/-4 pb, sigma(pi(0)pi(0) J/psi)=23(+12)(-8)+/-1 pb, and sigma(K+K- J/psi)=9(+9)(-5)+/-1 pb, in which the uncertainties are statistical and systematic, respectively. Upper limits are placed on other decay rates from all three resonances.
We present various properties of the production of the X(3872) and ψ(2S) states based on 10.4 fb−1 collected by the D0 experiment in Tevatron pp collisions at √s = 1.96 TeV. For both states, we ...measure the nonprompt fraction fNP of the inclusive production rate due to decays of b-flavored hadrons. We find the fNP values systematically below those obtained at the LHC. The fNP fraction for ψ(2S) increases with transverse momentum, whereas for the X(3872) it is constant within large uncertainties, in agreement with the LHC results. The ratio of prompt to nonprompt ψ(2S) production, (1 − fNP)=fNP, decreases only slightly going from the Tevatron to the LHC, but for the X(3872), this ratio decreases by a factor of about 3. We test the soft-pion signature of the X(3872) modeled as a weakly bound charm-meson pair by studying the production of the X(3872) as a function of the kinetic energy of the X(3872) and the pion in the X(3872)π center-of-mass frame. For a subsample consistent with prompt production, the results are incompatible with a strong enhancement in the production of the X(3872) at the small kinetic energy of the X(3872) and the π in the X(3872)π center-of-mass frame expected for the X þ soft-pion production mechanism. For events consistent with being due to decays of b hadrons, there is no significant evidence for the soft-pion effect, but its presence at the level expected for the binding energy of 0.17 MeV and the momentum scale Λ ¼ M(π) is not ruled out.
Flex circuits for the ATLAS pixel detector Skubic, P.; Boyd, G.; Krishnama, S. ...
Nuclear instruments & methods in physics research. Section A, Accelerators, spectrometers, detectors and associated equipment,
06/2001, Letnik:
465, Številka:
1
Journal Article
Recenzirano
Recent progress on designs of flexible circuits for the ATLAS pixel detector will be discussed. Thin flexible circuits can be used to provide power and signal connections between front-end (FE) ...readout chips and data acquisition chips on the pixel detector module. Fabrication of a prototype design has been completed and test beam measurements with a 16 FE chip flex module gave an efficiency of 98.4% and a position resolution of
13.8
μm
for clusters consisting of one or two pixels.
PDF
