bluuebunny/crossref_metadata_2025_split huggingface dataset:
Production Operations Management System (POMS) for Fermilab Experiments
Authors: Mengel Marc , White Stephen , Podstavkov Vladimir , Wiersma Margherita , Mazzacane Anna , Herner Kenneth 
Published: November 2020

The Production Operations Management System (POMS) software allows production teams and analysis groups across multiple Fermilab experiments to launch, modify and monitor large scale campaigns of related Monte Carlo or data processing jobs, and currently manages the majority of production computing of experiments at Fermilab.
POMS provides a web service interface that enables automated job submission on distributed resources according to customers’ requests, as well as subsequent monitoring of those submissions as well as recovery of failed submissions, debugging and record keeping.
POMS interfaces with existing HEP data access, processing, movement and monitoring tools at Fermilab, including Jobsub (for job submission), SAM (for data management), and Landscape (for monitoring), and in combination with them handles the creation of intermediate datasets of files for multistage campaigns.
POMS visualizes these campaigns with an interactive GUI interface. An important feature of POMS is a one-to-one connection between the GUI campaign visualizer and a text based representation of the complete campaign configuration. An extensible library of template campaign configurations is available. The templates are user modifiable and map cleanly to and from the GUI description of the campaign.
This paper will discuss the current usage, history, and some technical details of POMS, as well as planned future extensions, particularly interfacing with Rucio as well as SAM for file movement.
A Lightweight Submission Frontend Toolkit HepJob
Authors: JIANG Xiaowei , Du Ran , Shi Jingyan , Zou Jiaheng , Hu Qingbao 
Published: November 2020

A typical HEP Computing Center normally runs at least one batch system. As an example, at IHEP (Institute of High Energy Physics, Chinese Academy of Sciences), we’ve used three batch systems: PBS, HTCondor and SLURM. After running PBS as a local batch system for 10 years, we replaced it by HTCondor (for HTC) and SLURM (for HPC). During that period, problems came up on both user and admin sides.
Introduction of the new batch systems implies necessity for users to acquire additional knowledge specific for every batch system, in particular, batch commands. In some cases, users have to use both HTCondor and SLURM in parallel. Furthermore, HTCondor and SLURM provide more functionality, which means more complicated usage mode, compared to the simple PBS commands. On admin side, HTCondor gives more freedom to users, which brings an additional challenge to site administrators. Site administrators have to find the solutions for many problems: preventing users from requesting the resources they are not allowed to use, checking if the required attributes are correct, deciding where requested resources are located (SLURM cluster, the cluster of the virtual machines, the remote sites, etc).
To meet the above requirements, HepJob was designed and developed. HepJob provides a set of simple user commands, for example: hep_sub, hep_q, hep_rm, etc. In the submission process, HepJob checks all the attributes and ensures all attributes are correct; assigns proper resources to users (the user and group info is obtained from the management database); routes jobs to the target site; performs other steps as required.
Users can start with HepJob very easily and administrators can take the necessary management actions in HepJob.
Transitioning CMS to Rucio Data Managment
Authors: Vaandering Eric 
Published: November 2020

Following a thorough review in 2018, the CMS experiment at the CERN LHC decided to adopt Rucio as its new data management system. Rucio is emerging as a community software project and will replace an aging CMSonly system before the start-up of LHC Run 3 in 2021. Rucio was chosen after an evaluation determined that Rucio could meet the technical and scale needs of CMS. The data management system for CMS needs to manage the current data sample of approximately 200 PB of data with 1 PB of transfers per day. The data management system must also have a development path suitable for LHC Run 4 (2026) data rates, which are expected to be 50 times larger.
This contribution details the ongoing CMS adoption process as we replace our legacy system with Rucio, focusing on the challenges of integrating Rucio into an established set of experimental tools and procedures. This will include the migration of metadata, the construction of interfaces to the rest of the CMS computing tools, scale tests, operations, monitoring, and the plan to gradually turn over primary responsibility for the management of data to Rucio. A description of CMS user data management with Rucio will also be provided.
Data-centric Graphical User Interface of the ATLAS Event Index Service
Authors: Hřivnáč Julius , Alexandrov Evgeny , Alexandrov Igor , Baranowski Zbigniew , Barberis Dario , Dimitrov Gancho , Fernandez Casani Alvaro , Gallas Elizabeth , García Montoro Carlos , Gonzalez de la Hoz Santiago , Kazymov Andrei , Mineev Mikhail , Prokoshin Fedor , Rybkin Grigori , Sanchez Javier , Salt Jose , Villaplana Perez Miguel 
Published: November 2020

The Event Index service of the ATLAS experiment at the LHC keeps references to all real and simulated events. Hadoop Map files and HBase tables are used to store the Event Index data, a subset of data is also stored in the Oracle database. Several user interfaces are currently used to access and search the data, from a simple command line interface, through a programmable API, to sophisticated graphical web services. It provides a dynamic graph-like overview of all available data (and data collections). Data are shown together with their relations, like paternity or overlaps. Each data entity then gives users a set of actions available for the referenced data. Some actions are provided directly by the Event Index system, others are just interfaces to different ATLAS services. In many cases, specialized views are offered for detailed data inspection, such as histograms, Venn diagrams, etc.
This paper documents the current status of the service, its features and performance. The future system evolution to the new Event Index architecture based on the Apache Phoenix is also described as well as possible extension to a more general framework for giving a new, more intuitive access to experiment data.
Recent developments in histogram libraries
Authors: Dembinski Hans Peter , Pivarski Jim , Schreiner Henry 
Published: November 2020

Boost.Histogram, a header-only C++14 library that provides multidimensional histograms and profiles, became available in Boost 1.70. It is extensible, fast, and uses modern C++ features. Using template metaprogramming, the most efficient code path for any given configuration is automatically selected. The library includes key features designed for the particle physics community, such as optional under- and overflow bins, weighted increments, reductions, growing axes, thread-safe filling, and memory-efficient counters with high-dynamic range.
Python bindings for Boost.Histogram are being developed in the Scikit-HEP project to provide a fast, easy-to-install package as a backend for other Python libraries and for advanced users to manipulate histograms. Versatile and efficient histogram filling, effective manipulation, multithreading support, and other features make this a powerful tool. This library has also driven package distribution efforts in Scikit-HEP, allowing binary packages hosted on PyPI to be available for a very wide variety of platforms.
Two other libraries fill out the remainder of the Scikit-HEP Python histogramming effort. Aghast is a library designed to provide conversions between different forms of histograms, enabling interaction between histogram libraries, often without an extra copy in memory. This enables a user to make a histogram in one library and then save it in another form, such as saving a Boost.Histogram in ROOT. And Hist is a library providing friendly, analyst-targeted syntax and shortcuts for quick manipulations and fast plotting using these two libraries.
SpackDev: Multi-Package Development with Spack
Authors: Green Chris , Amundson James , Garren Lynn , Gartung Patrick , Sexton-Kennedy Elizabeth 
Published: November 2020

High Energy Physics (HEP) software environments often involve ∼ hundreds of external packages and libraries, and similar numbers of experiment-specific, science-critical packages—many under continuous development. Managing coherent releases of the external software stack is challenging enough, but managing the highly-collaborative—and distributed—development of a large body of code against such a stack adds even more complexity and room for error.
Spack is a popular Python-based package management tool with a specific focus on the needs of High Performance Computing (HPC) systems and system administrators whose strength is orchestrating the discrete download, build, testing, and installation of pre-packaged or tagged third-party software against similarly stable dependencies. As such it is becoming increasingly popular within HEP as that community makes increasing use of HPC facilities, and as efforts to develop future HPC systems utilize Spack to provide scientific software on those platforms [1].
SpackDev is a system to facilitate the simultaneous development of interconnected sets of packages. Intended to handle packages without restriction to one internal build system, SpackDev is integrated with Spack as a command extension in order to leverage features such as dependency calculations and build system configuration, and is generally applicable outside HEP. We describe SpackDev’s features and development over the last two years, initial experience using SpackDev in the context of the LArSoft liquid argon detector toolkit, and work remaining before it can be considered a fully-functional multi-package build system for HEP experiments utilizing Spack.
Evolution of the LHCb Continuous Integration system
Authors: Currie Robert , Mataev Rosen , Clemencic Marco 
Published: November 2020

The physics software stack of LHCb is based on Gaudi and is comprised of about 20 interdependent projects, managed across multiple GitLab repositories. At present, the continuous integration (CI) system used for regular building and testing of this software is implemented using Jenkins and runs on a cluster of about 300 cores.
LHCb CI pipelines are python-based and relatively modern with some degree of modularity, i.e. the separation of test jobs from build jobs. However, these still suffer from obsoleted design choices that prevent improvements to scalability and reporting. In particular, the resource use and speed have not been thoroughly optimized due to the predominant use of the system for nightly builds, where a feedback time of 8 hours is acceptable. We describe recent work on speeding up pipelines by aggressively splitting and parallelizing checkout, build and test jobs and caching their artifacts. The current state of automatic code quality integration, such as coverage reports, is shown.
This paper presents how feedback time from change (merge request) submission to build and test reports is reduced from “next day” to a few hours by dedicated on-demand pipelines. Custom GitLab integration allows easy triggering of pipelines, including linked changes to multiple projects, and provides immediate feedback as soon as ready. Reporting includes a comparison to tests on a unique stable reference build, dynamically chosen for every set of changes under testing. This work enables isolated testing of changes that integrates well into the development workflow, leaving nightly testing primarily for integration tests.
The use of Convolutional Neural Networks for signal-background classification in Particle Physics experiments
Authors: Ayyar Venkitesh , Bhimji Wahid , Gerhardt Lisa , Robertson Sally , Ronaghi Zahra 
Published: November 2020

The success of Convolutional Neural Networks (CNNs) in image classification has prompted efforts to study their use for classifying image data obtained in Particle Physics experiments. Here, we discuss our efforts to apply CNNs to 2D and 3D image data from particle physics experiments to classify signal from background.
In this work we present an extensive convolutional neural architecture search, achieving high accuracy for signal/background discrimination for a HEP classification use-case based on simulated data from the Ice Cube neutrino observatory and an ATLAS-like detector. We demonstrate among other things that we can achieve the same accuracy as complex ResNet architectures with CNNs with less parameters, and present comparisons of computational requirements, training and inference times.
Running ALICE Grid Jobs in Containers A new approach to job execution for the next generation ALICE Grid framework
Authors: Storetvedt Maxim , Betev Latchezar , Helstrup Håvard , Fanebust Hetland Kristin , Kileng Bjarte 
Published: November 2020

The new JAliEn (Java ALICE Environment) middleware is a Grid framework designed to satisfy the needs of the ALICE experiment for the LHC Run 3, such as providing a high-performance and high-scalability service to cope with the increased volumes of collected data. This new framework also introduces a split, two-layered job pilot, creating a new approach to how jobs are handled and executed within the Grid. Each layer runs on a separate JVM, with a separate authentication token, allowing for a finer control of permissions and improved isolation of the payload. Having these separate layers also allows for the execution of job payloads within containers. This allows for the further strengthening of isolation and creates a cohesive environment across computing sites, while avoiding the resource overhead associated with traditional virtualisation.
This contribution presents the architecture of the new split job pilot found in JAliEn, and the methods used to achieve the execution of Grid jobs while maintaining reliable communication between layers. Specifically, how this is achieved despite the possibility of a layer being run in a separate container, while retaining isolation and mitigating possible security risks. Furthermore, we discuss how the implementation remains agnostic to the choice of container platform, allowing it to run within popular platforms such as Singularity and Docker.
Cosmos : A Unified Accounting System both for the HTCondor and Slurm Clusters at IHEP
Authors: Du Ran , Shi Jingyan , Jiang Xiaowei , Zou Jiaheng 
Published: November 2020

HTCondor was adopted to manage the High Throughput Computing (HTC) cluster at IHEP in 2016. In 2017 a Slurm cluster was set up to run High Performance Computing (HPC) jobs. To provide accounting services for these two clusters, we implemented a unified accounting system named Cosmos.
Multiple workloads bring different accounting requirements. Briefly speaking, there are four types of jobs to account. First of all, 30 million single-core jobs run in the HTCondor cluster every year. Secondly, Virtual Machine (VM) jobs run in the legacy HTCondor VM cluster. Thirdly, parallel jobs run in the Slurm cluster, and some of these jobs are run on the GPU worker nodes to accelerate computing. Lastly, some selected HTC jobs are migrated from the HTCondor cluster to the Slurm cluster for research purposes.
To satisfy all the mentioned requirements, Cosmos is implemented with four layers: acquisition, integration, statistics and presentation. Details about the issues and solutions of each layer will be presented in the paper. Cosmos has run in production for two years, and the status shows that it is a well-functioning system, also meets the requirements of the HTCondor and Slurm clusters.
Public Engagement - More than just fun
Authors: Corbett Greg , Collier Ian , Palmer Sophy 
Published: November 2020

Public Engagement (PE) with science should be more than “fun” for the staff involved. PE should be a strategic aim of any publically funded science organisation to ensure the public develops an understanding and appreciation of their work, its benefits to everyday life and to ensure the next generation is enthused to take up STEM careers. Most scientific organisations do have aims to do this, but very few have significant budgets to deliver this. In a landscape of ever tightening budgets, how can we develop a sustainable culture of PE within these organisations?
UKRI/STFC’s Scientific Computing Department present how we have worked to embed a culture of PE with the department by developing our early career staff members; highlighting the impact PE makes at the departmental and project level; and linking PE to our competency framework.
We will also discuss how our departmental work interacts with and complements STFC’s organisational-wide PE effort, such as making use of a shared evaluation framework that allows us to evaluate our public engagement activities against their goals and make strategic decisions about the programme’s future direction.
Migrating Engineering Windows HPC applications to Linux HTCondor and Slurm Clusters
Authors: Alandes Pradillo Maria , Høimyr Nils , Llopis Sanmillan Pablo , Tapani Jylhänkangas Markus 
Published: November 2020

The CERN IT department has been maintaining different High Performance Computing (HPC) services over the past five years. While the bulk of computing facilities at CERN are running under Linux, a Windows cluster was dedicated for engineering simulations and analysis related to accelerator technology development. The Windows cluster consisted of machines with powerful CPUs, big memory, and a low-latency interconnect. The Linux cluster resources are accessible through HTCondor, and are used for general purpose parallel but single-node type jobs, providing computing power to the CERN experiments and departments for tasks such as physics event reconstruction, data analysis, and simulation. For HPC workloads that require multi-node parallel environments for Message Passing Interface (MPI) based programs, there is another Linux-based HPC service that is comprised of several clusters running under the Slurm batch system, and consist of powerful hardware with low-latency interconnects.In 2018, it was decided to consolidate compute intensive jobs in Linux to make a better use of the existing resources. Moreover, this was also in line with CERN IT strategy to reduce its dependencies on Microsoft products. This paper focuses on the migration of Ansys [1], COMSOL [2] and CST [3] users from Windows HPC to Linux clusters. Ansys, COMSOL and CST are three engineering applications used at CERN for different domains, like multiphysics simulations and electromagnetic field problems. Users of these applications are in different departments, with different needs and levels of expertise. In most cases, the users have no prior knowledge of Linux. The paper will present the technical strategy to allow the engineering users to submit their simulations to the appropriate Linux cluster, depending on their simulation requirements. We also describe the technical solution to integrate their Windows workstations in order from them to be able to submit to Linux clusters. Finally, we discuss the challenges and lessons learnt during the migration.
Towards a Turnkey Software Stack for HEP Experiments
Authors: Sailer André , Ganis Gerardo , Mato Pere , Petrič Marko , Stewart Graeme A. 
Published: November 2020

Future HEP experiments require detailed simulation and advanced reconstruction algorithms to explore the physics reach of their proposed machines and to design, optimise, and study the detector geometry and performance. To synergize the development of the CLIC and FCC software efforts, the CERN EP R&D roadmap proposes the creation of a “Turnkey Software Stack”, which is foreseen to provide all the necessary ingredients, from simulation to analysis, for future experiments; not only CLIC and FCC, but also for proposed Super-tau-charm factories, CEPC, and ILC. The software stack will facilitate writing specific software for experiments ensuring coherency and maximising the re-use of established packages to benefit from existing solutions and community developments, for example, ROOT, Geant4, DD4hep, Gaudi and podio. As a showcase for the software stack, the existing CLIC reconstruction software, written for iLCSoft, is being to be ported to Gaudi. In parallel, the back-end of the LCIO event data model can be replaced by an implementation in podio. These changes will enable the sharing of the algorithms with other users of the software stack.
We will present the current status and plans of the turnkey software stack, with a focus of the adaptation of the CLIC reconstruction chain to Gaudi and podio, and detail the plans for future developments to generalise their applicability to FCC and beyond.
Terahertz accelerator based electron and x-ray sources
Authors: Kärtner Franz X. 
Published: November 2020

The generation and use of THz radiation for electron acceleration and manipulation of electron bunches has progressed over the last decade to a level where practical devices for THz guns, acceleration and a wide range of beam manipulations have become possible. Here, we present our progress on generation of single-cycle THz pulses at the two-hundred micro-Joule level to drive advanced acceleration and beam manipulation devices. Specifically, we use pulses centered at 0.3 THz to power a segmented terahertz electron accelerator and manipulator (STEAM) capable of performing multiple high-field operations on the 6D-phase-space of ultrashort electron bunches. Using this STEAM device, we demonstrate record THz-acceleration of >60 keV, streaking with <10 𝑓s resolution, focusing with >2 kT/m strength, compression to ~100 𝑓s as well as real-time switching between these modes of operation. The STEAM device demonstrates the feasibility of THz-based electron accelerators, manipulators and diagnostic tools enabling science beyond current resolution frontiers with transformative impact.
Definition, reasons, and risk factors for mortality of patients listed for liver transplantation – a single-center study
Authors: Peschel Georg , Kraft Ina-Christine , Ilkhtchoui Ramin , Schmid Stephan , Sinner Barbara , Scherer Marcus N , Mueller-Schilling Martina , Weigand Kilian 
Published: November 2020

Abstract
Background In Germany, following the principle “sickest first”, patients awaiting liver transplantation (LTPL) are often transplanted with high MELD score and run the risk that they can no longer be transplanted, getting “too sick for transplant”.
Methods In a retrospective single-center study, we analyzed the mortality of adult patients on the waiting list for LTPL during the years 2014 to 2017. To stratify risk factors, we compared characteristics of deceased and transplanted patients.
Results The main reasons for mortality were sepsis (42.9 %), malignancy (24.3 %) and bleeding (10.0 %). Risk factors for mortality (OR, univariate logistic regression, p < 0.05) were acute on chronic liver failure (ACLF), loss of E-MELD, sepsis, pneumonia, proof of pathogens, candidemia, stay at ICU, multiple organ failure and mechanical ventilation. Multivariate analysis revealed pneumonia (p < 0.001) and high MELD (p = 0.031) as risk factors. Transplantation was more likely in patients with E-MELD. We suggest a Waiting List Mortality Index for Transplantation (WMIT), by dividing deceased patients to transplanted patients to assess mortality. Average WMIT in our cohort was 0.65.
Conclusions Mortality on the waiting list is mainly determined by pneumonia and infections in high-MELD patients. Therefore, patients with ACLF after infections should be prioritized for LTPL. A WMIT might suitably represent waiting list mortality.