Campus Grids: Bringing Additional Computational Resources to HEP Researchers

The Open Science Grid(OSG) is a world-wide computing system which facilitates distributed computing for scientific research. It can distribute a computationally intensive job to geo-distributed clusters and process job's tasks in parallel. For compute clusters on the OSG, physical resources may be shared between OSG and cluster's local user-submitted jobs, with local jobs preempting OSG-based ones. As a result, job preemptions occur frequently in OSG, sometimes significantly delaying job completion time. We have collected job data from OSG over a period of more than 80 days. We present an analysis of the data, characterizing the preemption patterns and different types of jobs. Based on observations, we have grouped OSG jobs into 5 categories and analyze the runtime statistics for each category. we further choose different statistical distributions to estimate probability density function of job runtime for different classes.

We present a system that allows individual researchers and virtual organizations (VOs) to access allocations on Stampede2 and Bridges through the Open Science Grid (OSG), a national grid infrastructure for running high throughput computing (HTC) tasks. Using this system, VOs and researchers are able to run larger workflows than can be done with OSG resources alone. This system allows a VO or user to run on XSEDE resources (with their allocation) using the same framework used with OSG resources. The system consists of two parts: the compute element (CE) that routes workloads to the appropriate user accounts and allocation on XSEDE resources, and simulated access to the CernVM Filesystem (CVMFS) servers used by OSG and VOs to distribute software and data. This allows jobs submitted through this system to work on a homogeneous environment regardless of whether they run on XSEDE HPC resources (like Stampede2 and Bridges) or OSG.

Throughout the last decade the Open Science Grid (OSG) has been fielding requests from user communities, resource owners, and funding agencies to provide information about utilization of OSG resources. Requested data include traditional accounting - core-hours utilized - as well as users certificate Distinguished Name, their affiliations, and field of science. The OSG accounting service, Gratia, developed in 2006, is able to provide this information and much more. However, with the rapid expansion and transformation of the OSG resources and access to them, we are faced with several challenges in adapting and maintaining the current accounting service. The newest changes include, but are not limited to, acceptance of users from numerous university campuses, whose jobs are flocking to OSG resources, expansion into new types of resources (public and private clouds, allocation-based HPC resources, and GPU farms), migration to pilot-based systems, and migration to multicore environments. In order to have a scalable, sustainable and expandable accounting service for the next few years, we are embarking on the development of the next-generation OSG accounting service, GRACC, that will be based on open-source technology and will be compatible with the existing system. It will consist of swappable, independent components, such as Logstash, Elasticsearch, Grafana, and RabbitMQ, that communicate through a data exchange. GRACC will continue to interface EGI and XSEDE accounting services and provide information in accordance with existing agreements. We will present the current architecture and working prototype.

The Open Science Grid (OSG) is a large, robust computing grid that started primarily as a collection of sites associated with large HEP experiments such as ATLAS, CDF, CMS, and DZero, but has evolved in recent years to a much larger user and resource platform. In addition to meeting the US LHC community’s computational needs, the OSG continues to be one of the largest providers of distributed high-throughput computing (DHTC) to researchers from a wide variety of disciplines via the OSG Open Facility. The Open Facility consists of OSG resources that are available opportunistically to users other than resource owners and their collaborators. In the past two years, the Open Facility has doubled its annual throughput to over 200 million wall hours. More than half of these resources are used by over 100 individual researchers from over 60 institutions in fields such as biology, medicine, math, economics, and many others. Over 10% of these individual users utilized in excess of 1 million computational hours each in the past year. The largest source of these cycles is temporary unused capacity at institutions affiliated with US LHC computational sites. An increasing fraction, however, comes from university HPC clusters and large national infrastructure supercomputers offering unused capacity. Such expansions have allowed the OSG to provide ample computational resources to both individual researchers and small groups as well as sizable international science collaborations such as LIGO, AMS, IceCube, and sPHENIX. Opening up access to the Fermilab FabrIc for Frontier Experiments (FIFE) project has also allowed experiments such as mu2e and NOvA to make substantial use of Open Facility resources, the former with over 40 million wall hours in a year. We present how this expansion was accomplished as well as future plans for keeping the OSG Open Facility at the forefront of enabling scientific research by way of DHTC.

The Open Science Grid (OSG) ties together individual experiments’ computing power, connecting their resources to create a large, robust computing grid; this computing infrastructure started primarily as a collection of sites associated with large HEP experiments such as ATLAS, CDF, CMS, and DZero. In the years since, the OSG has broadened its focus to also address the needs of other US researchers and increased delivery of Distributed High Through-put Computing (DHTC) to users from a wide variety of disciplines via the OSG Open Facility. Presently, the Open Facility delivers about 100 million computing wall hours per year to researchers who are not already associated with the owners of the computing sites; this is primarily accomplished by harvesting and organizing the temporarily unused capacity (i.e. opportunistic cycles) from the sites in the OSG. Using these methods, OSG resource providers and scientists share computing hours with researchers in many other fields to enable their science, striving to make sure that these computing power used with maximal efficiency. We believe that expanded access to DHTC is an essential tool for scientific innovation and work continues in expanding this service.

We present a novel computational framework that connects Blue Waters, the NSF-supported, leadership-class supercomputer operated by NCSA, to the Laser Interferometer Gravitational-Wave Observatory (LIGO) Data Grid via Open Science Grid technology. To enable this computational infrastructure, we configured, for the first time, a LIGO Data Grid Tier-1 Center that can submit heterogeneous LIGO workflows using Open Science Grid facilities. In order to enable a seamless connection between the LIGO Data Grid and Blue Waters via Open Science Grid, we utilize Shifter to containerize LIGO's workflow software. This work represents the first time Open Science Grid, Shifter, and Blue Waters are unified to tackle a scientific problem and, in particular, it is the first time a framework of this nature is used in the context of large scale gravitational wave data analysis. This new framework has been used in the last several weeks of LIGO's second discovery campaign to run the most computationally demanding gravitational wave search workflows on Blue Waters, and accelerate discovery in the emergent field of gravitational wave astrophysics. We discuss the implications of this novel framework for a wider ecosystem of Higher Performance Computing users.

The HTCondor-CE is the next-generation gateway software for the Open Science Grid (OSG). This is responsible for providing a network service which authorizes remote users and provides a resource provisioning service (other well-known gateways include Globus GRAM, CREAM, Arc-CE, and Openstacks Nova). Based on the venerable HTCondor software, this new CE is simply a highly-specialized configuration of HTCondor. It was developed and adopted to provide the OSG with a more flexible, scalable, and easier-to-manage gateway software. Further, the focus of the HTCondor-CE is not job submission (as in GRAM or CREAM) but resource provisioning. This software does not exist in a vacuum: to deploy this gateway across the OSG, we had to integrate it with the CE configuration, deploy a corresponding information service, coordinate with sites, and overhaul our documentation.

Grids enable uniform access to resources by implementing standard interfaces to resource gateways. In the Open Science Grid (OSG), privileges are granted on the basis of the user's membership to a Virtual Organization (VO). However, Grid sites are solely responsible to determine and control access privileges to resources using users' identity and personal attributes, which are available through Grid credentials. While this guarantees full control on access rights to the sites, it makes VO privileges heterogeneous throughout the Grid and hardly fits with the Grid paradigm of uniform access to resources. To address these challenges, we are developing the Scalable Virtual Organization Privileges Management Environment (SVOPME), which provides tools for VOs to define and publish desired privileges and assists sites to provide the appropriate access policies. Moreover, SVOPME provides tools for Grid sites to analyze site access policies for various resources, verify compliance with preferred VO policies, and generate directives for site administrators on how the local access policies can be amended to achieve such compliance without taking control of local configurations away from site administrators. This paper discusses what access policies are of interest to the OSG community and how SVOPME implements privilege management for OSG.

MCwrapper is a set of systems that manages the entire Monte Carlo production workflow for GlueX and provides standards for how that Monte Carlo is produced. MCwrapper was designed to be able to utilize a variety of batch systems in a way that is relatively transparent to the user, thus enabling users to quickly and easily produce valid simulated data at home institutions worldwide. Additionally, MCwrapper supports an autonomous system that takes user’s project submissions via a custom web application. The system then atomizes the project into individual jobs, matches these jobs to resources, and monitors the jobs status. The entire system is managed by a database which tracks almost all facets of the systems from user submissions to the individual jobs themselves. Users can interact with their submitted projects online via a dashboard or, in the case of testing failure, can modify their project requests from a link contained in an automated email. Beginning in 2018 the GlueX Collaboration began to utilize the Open Science Grid (OSG) to handle a bulk of simulation tasks; these tasks are currently being performed on the OSG automatically via MCwrapper. This talk will outline the entire system of MCwrapper, its use cases, and the unique challenges facing the system.

In 1998, Ian Foster and Carl Kesselman, together with thirty distinguished experts in high-performance computing and networking, laid the foundations of a new computing model called GRID. Their vision was introduced in the book, The GRID: Blueprint for a New Computing Infrastructure (see review, SCPE Vol. 3, No. 3 ). The editors wrote: … A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high-end computational capabilities… allowing new classes of applications to emerge… as yet, we have only a preliminary understanding of what these new applications will look like. Over the next five years, Grid computing became the hottest R&D field. Academia and national labs built experimental infrastructures, new startups were established to develop Grid technologies, and the HPC giant vendors joined the party. Each one pushed in a different direction based on what and how he believed Grid computing should look. It was only a matter of time until people started to ask what the Grid is all about. A survey of ten Grid experts produced ten different answers. The question remains without a clear answer, leaving many people confused. Ian Foster picked up the gloves. In his article, What is the GRID? A three point checklist (GRIDtoday, July 22, 2002: Vol. 1, No. 6), he redefines the Grid model to reflect the trades and changes in the field during the past five years. According to Foster, a Grid is a system that: Coordinates resources that are not subject to centralized control. Uses standard, open, general-purpose protocols and interfaces. Delivers a nontrivial quality of service. But Foster's new definition could not encompass all of the Grid's approaches. Moreover, Foster explained by example what the Grid is not: A cluster management system such as Sun's Sun Grid Engine, Platform's Load Sharing Facility, or Viridian's Portable Batch System can, when installed on a parallel computer or local area network, deliver quality of service guarantees and thus constitutes a powerful Grid resource. However, such a system is not a Grid itself, due to its centralized control of the hosts that it manages Within a week the responses started to come in. The first one was from Wolfgang Gentzsch, Director of Grid computing at Sun Microsystems (GRIDtoday, August 5, 2002: Vol. 1, No. 8). Gentzsch wrote: I very much like Ian's two earlier definitions. Combined, they may provide a very generic Grid definition. The new checklist, however, reduces the potential of a wide and rich variety of Grids, with different architectures, operational models, and applications, and may miss the chance to becoming widely accepted as a standard definition of the Grid. Why do we need a definition for the Grid? Can the Grid be defined? Is a definition is necessary to the Grid's development? The Grid is an open vision and thus cannot be defined. An attempt to define the Grid can only reach the foreseen technology horizon, and this horizon is only one to two years ahead. Grid computing is a paradigm in shift. New architectures and standards are changing the shape and direction of the Grid's development. In the past year one such prominent architecture was Open Grid Services Architecture (OGSA). The OGSA is the first attempt to bridge the gap between two cyberspace worlds: the Internet and the Grid. The Internet and the Grid are two different computing models. There are people who believe that the Grid is the next generation of the Internet and the World Wide Web, saying that the Great Global Grid is still many years away. Others state that the Grid will complement, not replace, the Internet as we know it. In 1998, when the Grid blueprint was published, a new Internet language appeared called eXtensible Markup Language (XML). XML is a development tool for a new Internet computing model known as Web Services. At that time, nobody understood that there is a relationship between Web Services and the Grid. Three years past before Steve Tuecke from Argonne National Laboratory started to write a spec for Grid Services. Later, people from IBM joined the mission and together they created OGSA. The OGSA specification outlines interfaces to grid computing software that comply with Web Services standards. If adopted, Grid services such as job scheduling, authentication, failure-detection, staging of applications and data, and migration of applications and data, will all be accessed through standard Web Services architecture. OGSA is basically where Grid meets Web Services and maybe the first step towards full integration of the Internet and the Grid. The Internet appeared a decade ago. In the beginning, the Net offered primitive applications: a mailing system, ftp services, and a web of home pages. Nobody asked, What is the Internet? The years passed and new emerging Internet technologies were developed. Today we can talk on the phone over the Net, chat with friends, and video conference with colleagues on the other side of the world. New computing and business models were developed: e-commerce, e-learning, e-science, and e-you-name-it. And nobody asks what the Internet is. The Grid is a super-model, a bag of networking models associated with many types of architectures, software packages, applications, and standards. Today, when people talk about the Grid they mention Data Grids, Science Grids, and Campus Grids. And at the same time they mention Farm computing, Peer-to-peer computing, and Utility computing, among others. Ten years from now many of today's technologies will disappear and new ones will be developed. I don't know how Grid computing will look a decade from now, but I know that we will have g-commerce, g-learning, g-science, and g-chat. Nobody will ask what the Grid is. It will be obvious, just as the Internet is today. Ami Marowka The Computer Aided Design Laboratory School of Engineering and Computer Science Hebrew University of Jerusalem

Fermilab supports a scientific program that includes experiments and scientists located across the globe. To better serve this community, in 2004, the (then) Computing Division undertook the strategy of placing all of the High Throughput Computing (HTC) resources in a Campus Grid known as FermiGrid, supported by common shared services. In 2007, the FermiGrid Services group deployed a service infrastructure that utilized Xen virtualization, LVS network routing and MySQL circular replication to deliver highly available services that offered significant performance, reliability and serviceability improvements. This deployment was further enhanced through the deployment of a distributed redundant network core architecture and the physical distribution of the systems that host the virtual machines across multiple buildings on the Fermilab Campus. In 2010, building on the experience pioneered by FermiGrid in delivering production services in a virtual infrastructure, the Computing Sector commissioned the FermiCloud, General Physics Computing Facility and Virtual Services projects to serve as platforms for support of scientific computing (FermiCloud 6 GPCF) and core computing (Virtual Services). This work will present the evolution of the Fermilab Campus Grid, Virtualization and Cloud Computing infrastructure together with plans for the future.

Data analysis using grid resources is one of the fundamental challenges to be addressed before the start of LHC data taking. The ATLAS detector will produce petabytes of data per year, and roughly one thousand users will need to run physics analyses on this data. Appropriate user interfaces and helper applications have been made available to ensure that the grid resources can be used without requiring expertise in grid technology. These tools enlarge the number of grid users from a few production administrators to potentially all participating physicists. ATLAS makes use of three grid infrastructures for the distributed analysis: the EGEE sites, the Open Science Grid, and Nordu Grid. These grids are managed by the gLite workload management system, the PanDA workload management system, and ARC middleware; many sites can be accessed via both the gLite WMS and PanDA. Users can choose between two front-end tools to access the distributed resources. Ganga is a tool co-developed with LHCb to provide a common interface to the multitude of execution backends (local, batch, and grid). The PanDA workload management system provides a set of utilities called PanDA Client; with these tools users can easily submit Athena analysis jobs to the PanDA-managed resources. Distributed data is managed by Don Quixote 2, a system developed by ATLAS; DQ2 is used to replicate datasets according to the data distribution policies and maintains a central catalog of file locations. The operation of the grid resources is continually monitored by the Ganga Robot functional testing system, and infrequent site stress tests are performed using the Hammer Cloud system. In addition, the DAST shift team is a group of power users who take shifts to provide distributed analysis user support; this team has effectively relieved the burden of support from the developers.

The Compact Muon Solenoid (CMS) is one of the general purpose experiments at the CERN Large Hadron Collider (LHC). CMS computing relies on different grid infrastructures to provide computational and storage resources. The major grid middleware stacks used for CMS computing are gLite, Open Science Grid (OSG) and ARC (Advanced Resource Connector). Helsinki Institute of Physics (HIP) hosts one of the Tier-2 centers for CMS computing. CMS Tier-2 centers operate software systems for data transfers (PhEDEx), Monte Carlo production (ProdAgent) and data analysis (CRAB). In order to provide the Tier-2 services for CMS, HIP uses tools and components from both ARC and gLite grid middleware stacks. Interoperation between grid systems is a challenging problem and HIP uses two different solutions to provide the needed services. The first solution is based on gLite-ARC grid level interoperability. This allows to use ARC resources in CMS without modifying the CMS application software. The second solution is based on developing specific ARC plugins in CMS software.

Single-photon emission computed tomography (SPECT) is the leading medical-imaging method for the study myocardial perfusion, which is important for the diagnosis and treatment of coronary-artery disease, the number-one killer in the western world. C-SPECT is a proposed dedicated cardiac SPECT system designed to achieve at least double the geometric efficiency compared to general-purpose dual-head gamma cameras, for the same resolution. This improvement can be used to reduce patient radiation dose, achieve fast or dynamic imaging, and enhance the quality of images. The system consists of stationary detector modules of pixelated NaI(Tl), a slit-slat collimator with interchangeable slits and collapsible slats, and an integrated CT for attenuation correction. The collimator slits provide pinhole collimation in the transverse plane, whereas the slats offer parallel-beam collimation in the axial direction. The adaptive power of the collimator allows us to adjust, in situ, the sensitivity and resolution depending on the imaging task. This way, superior reconstructed-image resolution could be achieved if the system operates with the usual geometric efficiency of the industry's benchmark. The system gantry wraps around patients' left-front thorax and provides a transverse projection minification of ~50%, for a maximal number of minimally-overlapping projections, given the limitations from the spatial resolution of the pixelated detector. We present the design principles and preliminary imaging performance using three-dimensional iterative reconstruction with resolution recovery and data from the newly-built laboratory prototype as well as Monte-Carlo (MC) simulations of the full system. This work was supported by NIH grant HL108119 and utilized resources provided by the Open Science Grid, which is supported by the National Science Foundation and the U.S. Department of Energy's Office of Science.

Before scientific analyses run on shared infrastructure, such as the Open Science Grid or XSEDE, scientists must often transfer or stage key data sets those resources. Often these datasets consist of many files that may be transferred by multiple clients in parallel. We study two techniques that improve the use of available resources for these large, long-running, multi-file transfers. First, we adapt transfer parameters for multi-file transfers based on recent transfer performance. Second, we use VO and site policies to influence the allocation of system resources for transfers, such as available transfer streams. We describe our system design and summarize its implementation and performance.