bluuebunny/crossref_metadata_2025_split huggingface dataset:
Detection and characterisation of 54 massive companions with the SOPHIE spectrograph
Authors: Kiefer F. , Hébrard G. , Sahlmann J. , Sousa S. G. , Forveille T. , Santos N. , Mayor M. , Deleuil M. , Wilson P. A. , Dalal S. , Díaz R. F. , Henry G. W. , Hagelberg J. , Hobson M. J. , Demangeon O. , Bourrier V. , Delfosse X. , Arnold L. , Astudillo-Defru N. , Beuzit J.-L. , Boisse I. , Bonfils X. , Borgniet S. , Bouchy F. , Courcol B. , Ehrenreich D. , Hara N. , Lagrange A.-M. , Lovis C. , Montagnier G. , Moutou C. , Pepe F. , Perrier C. , Rey J. , Santerne A. , Ségransan D. , Udry S. , Vidal-Madjar A. 
Published: September 2019

Context. Brown dwarfs (BD) are substellar objects intermediate between planets and stars with masses of ~13–80 MJ. While isolated BDs are most likely produced by gravitational collapse in molecular clouds down to masses of a few MJ, a non-negligible fraction of low-mass companions might be formed through the planet-formation channel in protoplanetary discs. The upper mass limit of objects formed within discs is still observationally unknown, the main reason being the strong dearth of BD companions at orbital periods shorter than 10 yr, also known as the BD desert.
Aims. To address this question, we aim at determining the best statistics of companions within the 10–100 MJ mass regime and located closer than ~10 au to the primary star, while minimising observation and selection bias.
Methods. We made extensive use of the radial velocity (RV) surveys of northern hemisphere FGK stars within 60 pc of the Sun, performed with the SOPHIE spectrograph at the Observatoire de Haute-Provence. We derived the Keplerian solutions of the RV variations of 54 sources. Public astrometric data of the HIPPARCOS and Gaia missions allowed us to constrain the masses of the companions for most sources. We introduce GASTON, a new method to derive inclination combining RVs and Keplerian and astrometric excess noise from Gaia DR1.
Results. We report the discovery of 12 new BD candidates. For five of them, additional astrometric data led to a revision of their mass in the M-dwarf regime. Among the seven remaining objects, four are confirmed BD companions, and three others are likely also in this mass regime. Moreover, we report the detection of 42 M-dwarfs within the range of 90 MJ–0.52 M⊙. The resulting M sin i-P distribution of BD candidates shows a clear drop in the detection rate below 80-day orbital period. Above that limit, the BD desert appears rather wet, with a uniform distribution of the M sin i. We derive a minimum BD-detection frequency around Solar-like stars of 2.0 ± 0.5%.
Dust production in the debris disk around HR 4796 A
Authors: Olofsson J. , Milli J. , Thébault P. , Kral Q. , Ménard F. , Janson M. , Augereau J.-C. , Bayo A. , Beamín J. C. , Henning Th. , Iglesias D. , Kennedy G. M. , Montesinos M. , Pawellek N. , Schreiber M. R. , Zamora C. , Carbillet M. , Feautrier P. , Fusco T. , Madec F. , Rabou P. , Sevin A. , Szulágyi J. , Zurlo A. 
Published: September 2019

Context. Debris disks are the natural by-products of the planet formation process. Scattered or polarized light observations are mostly sensitive to small dust grains that are released from the grinding down of bigger planetesimals.
Aims. High angular resolution observations at optical wavelengths can provide key constraints on the radial and azimuthal distribution of the small dust grains. These constraints can help us better understand where most of the dust grains are released upon collisions.
Methods. We present SPHERE/ZIMPOL observations of the debris disk around HR 4796 A, and we modeled the radial profiles along several azimuthal angles of the disk with a code that accounts for the effect of stellar radiation pressure. This enabled us to derive an appropriate description for the radial and azimuthal distribution of the small dust grains.
Results. Even though we only modeled the radial profiles along, or close to, the semi-major axis of the disk, our best-fit model is not only in good agreement with our observations but also with previously published datasets (from near-infrared to sub-mm wavelengths). We find that the reference radius is located at 76.4 ± 0.4 au, and the disk has an eccentricity of 0.076−0.010+0.016 with the pericenter located on the front side of the disk (north of the star). We find that small dust grains must be preferentially released near the pericenter to explain the observed brightness asymmetry.
Conclusions. Even though parent bodies spend more time near the apocenter, the brightness asymmetry implies that collisions happen more frequently near the pericenter of the disk. Our model can successfully reproduce the shape of the outer edge of the disk without requiring an outer planet shaping the debris disk. With a simple treatment for the effect of the radiation pressure, we conclude that the parent planetesimals are located in a narrow ring of about 3.6 au in width.
Alice Overwatch: Online Monitoring and Data Quality Assurance Using Hlt Data
Authors: Ehlers Raymond , Mulligan James 
Published: September 2019

ALICE Overwatch is a project started in late 2015 to provide augmented online monitoring and data quality assurance utilizing time-stamped QA histograms produced by the ALICE High Level Trigger. The system receives the data via ZeroMQ, stores it for later review, enriches it with detector specific functionality, and visualizes it via a web application. These provided capabilities are complementary to the existing Data Quality Monitoring system. In addition to basic visualization, additional processing options are accessible to the user, including requests for data within a particular time range or reprocessing of a particular run with different processing parameters. For example, the first ten minutes of a particular run could be investigated for a transient hot trigger channel.Due to similarities between the Overwatch architecture and that which will be used for Quality Control (QC) in LHC Run 3 and beyond, Overwatch will also be utilized to develop and test various QC components during LHC Run 2. Some of the areas of QC development include a new trending and alarm framework. We report on the project᠙s design, development, and status.
FairRoot and ALICE O2 Multithreading Simulation
Authors: Hˇrivnácˇová Ivana 
Published: September 2019

To address the challenges of the major upgrade of the experiment, the ALICE simulations must be able to make efficient use of computing and opportunistic supercomputing resources available on the GRID. The Geant4 transport package, the performance of which has been demonstrated in a hybrid multithreading (MT) and multiprocessing (MPI) environment with up to 1/4 million threads, is therefore of a particular interest.
The O2 simulation framework is based on FairRoot, which itself is based on the Virtual Monte Carlo (VMC). The integration of multithreading into the VMC design and its impact on the Geant4 VMC were presented at CHEP 2014. Geant4 VMC multithreading and the scaling behaviour of the computing time with the number of cores have then been tested using a simplified but realistic multithreaded simulation application.
The focus was then put on the integration of multithreading in FairRoot classes as the necessary step towards multithreading in the FairRoot-based experimental frameworks. The new O2 framework is the first one of which the migration to multithreading is achieved for all actually included detectors. In this paper we present the progress with the integration of multithreading in FairRoot classes, the work for thread-safety in the O2 simulation classes and the experience with the integration of the multithreading mode in testing. We will also discuss plans for the further developments.
Addressing Scalability with Message Queues: Architecture and Use Cases for DIRAC Interware
Authors: Krzemien Wojciech , Stagni Federico , Haen Christophe , Mathe Zoltan , McNab Andrew , Zdybal Milosz 
Published: September 2019

The Message Queue (MQ) architecture is an asynchronous communication scheme that provides an attractive solution for certain scenarios in a distributed computing model. The introduction of MQ as an intermediate component in-between the interacting processes allows to decouple the end-points making the system more flexible and providing high scalability and redundancy. DIRAC is a general-purpose interware software for distributed computing systems, which offers a common interface to a number of heterogeneous providers and guarantees transparent and reliable usage of the resources. The DIRAC platform has been adapted by several scientific projects, including High Energy Physics communities like LHCb, the Linear Collider and Belle2.
A Message Queue generic interface has been incorporated into the DIRAC framework to help solving the scalability challenges that must be addressed during LHC Run3, starting in 2021. It allows to use the MQ scheme for a message exchange among the DIRAC components or to communicate with third-party services. Within this contribution we describe the integration of MQ systems with DIRAC and several use cases are shown. Message Queues are foreseen to be used in the pilot logging system, and as a backbone of the DIRAC component logging system and monitoring.
Evolution of HammerCloud to commission CERN Compute resources
Authors: Schovancová Jaroslava , Di Girolamo Alessandro , Fkiaras Aristeidis , Mancinelli Valentina 
Published: September 2019

HammerCloud is a testing service and framework to commission, run continuous tests or on-demand large-scale stress tests, and benchmark computing resources and components of various distributed systems with realistic full-chain experiment workflows.HammerCloud, used by the ATLAS and CMS experiments in production, has been a useful service to commission both compute resources and various components of the complex distributed systems of the LHC experiments, as well as integral partof the monitoring suite that is essential for the computing operations of the experiments and their automation.In this contribution we review recent developments of the HammerCloud service that allow use of HammerCloud infrastructure to test Data Centre resources in the early phases of the infrastructure and services commissioning process. One of thebenefits we believe HammerCloud can provide is to be able to tune the commissioning of the new infrastructure, functional and also stress testing, as well as benchmarking with "standard candle" workflows, with experiment realistic workloads, that can be heavy for CPU, or I/O, or IOPS, or everything together. This extension of HammerCloud has been successfully usedin CERN IT during the prototype phase of the "BEER" Batch on EOS (Evaluation of Resources) project, and is being integrated with the continuous integration/continuous deployment suite for Batch service VMs.
The data management of heterogeneous resources in Belle II
Authors: Schram Malachi 
Published: September 2019

The Belle II experiment at the SuperKEKB collider in Tsukuba, Japan, has started taking physics data in early 2018 and plans to accumulate 50 ab-1, which is approximately 50 times more data than the Belle experiment. The collaboration expects it will require managing and processing approximately 200 PB of data.
Computing at this scale requires efficient and coordinated use of the geographically distributed compute resources in North America, Asia and Europe and will take advantage of high-speed global networks. We present the general Belle II the distributed data management system and computing results from the first phase of data taking.
Disk failures in the EOS setup at CERN
Authors: Duellmann Dirk , Portabales Alfonso 
Published: September 2019

The EOS deployment at CERN is a core service used for both scientific
data processing, analysis and as back-end for general end-user storage (eg
home directories/CERNBOX). The collected disk failure metrics over a period
of 1 year from a deployment size of some 70k disks allows a first systematic
analysis of the behaviour of different hard disk types for the large CERN usecases.
In this contribution we describe the data collection and analysis, summarise
the measured rates and compare them with other large disk deployments. We
further describe initial steps to use the collected failure and SMART metrics to
develop a machine learning model predicting imminent failures and hence avoid
service degradation and repair costs.
LHCb Continuous Integration and Deployment system: a message based approach
Authors: Chitic Stefan-Gabriel , Couturier Ben , Clemencic Marco , Closier Joel 
Published: September 2019

A continuous integration system is crucial to maintain the quality of the 6 millions lines of C++ and Python source code of the LHCb software in order to ensure consistent builds of the software as well as to run the unit and integration tests. Jenkins automation server is used for this purpose. It builds and tests around 100 configurations and produces in the order of 1500 built artifacts per day which are installed on the CVMFS file system or potentially on the developers’ machines.
Faced with a large and growing number of configurations built every day, and in order to ease inter-operation between the continuous integration system and the developers, we decided to put in place a flexible messaging system. As soon as the built artifacts have been produced, the distributed system allows their deployment based on the priority of the configurations.
We will describe the architecture of the new system, which is based on RabbitMQ messaging system (and the pika Python client library), and uses priority queues to start the LHCb software integration tests and to drive the installation of the nightly builds on the CVMFS file system. We will also show how the introduction of an event based system can help with the communication of results to developers.
Testing of complex, large-scale distributed storage systems: a CERN disk storage case study
Authors: Makai Jozsef , Peters Andreas Joachim , Bitzes Georgios , Sindrilaru Elvin Alin , Simon Michal Kamil , Manzi Andrea 
Published: September 2019

Complex, large-scale distributed systems are frequently used to solve extraordinary computing, storage and other problems. However, the development of these systems usually requires working with several software components, maintaining and improving a large codebase and also providing a collaborative environment for many developers working together. The central role that such complex systems play in mission critical tasks and also in the daily activity of the users means that any software bug affecting the availability of the service has far reaching effects.
Providing an easily extensible testing framework is a pre-requisite for building both confidence in the system but also among developers who contribute to the code. The testing framework can address concrete bugs found in the odebase thus avoiding any future regressions and also provides a high degree of confidence for the people contributing new code. Easily incorporating other people's work into the project greatly helps scaling out manpower so that having more developers contributing to the project can actually result in more work being done rather then more bugs added.
In this paper we go through the case study of EOS, the CERN disk storage system and introduce the methods and mechanisms of how to achieve all-automatic regression and robustness testing along with continuous integration for such a large-scale, complex and critical system using a container-based environment.
Evolution of the ALICE Software Framework for Run 3
Authors: Eulisse Giulio , Konopka Piotr , Krzewicki Mikolaj , Richter Matthias , Rohr David , Wenzel Sandro 
Published: September 2019

ALICE is one of the four major LHC experiments at CERN. When the accelerator enters the Run 3 data-taking period, starting in 2021, ALICE expects almost 100 times more Pb-Pb central collisions than now, resulting in a large increase of data throughput. In order to cope with this new challenge, the collaboration had to extensively rethink the whole data processing chain, with a tighter integration between Online and Offline computing worlds. Such a system, code-named ALICE O2, is being developed in collaboration with the FAIR experiments at GSI. It is based on the ALFA framework which provides a generalized implementation of the ALICE High Level Trigger approach, designed around distributed software entities coordinating and communicating via message passing.
We will highlight our efforts to integrate ALFA within the ALICE O2 environment. We analyze the challenges arising from the different running environments for production and development, and conclude on requirements for a flexible and modular software framework. In particular we will present the ALICE O2 Data Processing Layer which deals with ALICE specific requirements in terms of Data Model. The main goal is to reduce the complexity of development of algorithms and managing a distributed system, and by that leading to a significant simplification for the large majority of the ALICE users.
Spack-Based Packaging and Development for HEP
Authors: Green Chris , Amundson James , Garren Lynn , Gartung Patrick , Paterno Marc 
Published: September 2019

The art event-based analysis framework is used by multiple Intensity Frontier and other experiments and projects in High Energy Physics (HEP). A system of tools and scripts based around a Fermilab-originated package management system called UNIX Product Support (UPS) has evolved to provide development, packaging, release management, and distribution of the art suite, related experimental software and external dependencies in relocatable binary form.
The existing system has limitations in environments such as macOS with System Integrity Protection (SIP) enabled and the various High Performance Computing (HPC) systems that the field of HEP is increasingly looking to leverage. This has led to a search for other ways of providing experiments with a packaging and build system that meets their needs. We describe our efforts to develop a packaging and release management system based on the Spack HPC package management tool to replace the existing UPS-based system. We additionally describe a companion system: SpackDev and cetmodules, allowing simultaneous development of multiple HEP software packages in a consistent environment. A successful implementation of the intended system would have applicability across HEP rather than merely to the users of the art framework.
Using Big Data Technologies for HEP Analysis
Authors: Cremonesi Matteo , Bellini Claudio , Bian Bianny , Canali Luca , Dimakopoulos Vasileios , Elmer Peter , Fisk Ian , Girone Maria , Gutsche Oliver , Hoh Siew-Yan , Jayatilaka Bo , Khristenko Viktor , Luiselli Andrea , Melo Andrew , Motesnitsalis Evangelos , Olivito Dominick , Pazzini Jacopo , Pivarski Jim , Svyatkovskiy Alexey , Zanetti Marco 
Published: September 2019

The HEP community is approaching an era were the excellent performances of the particle accelerators in delivering collision at high rate will force the experiments to record a large amount of information. The growing size of the datasets could potentially become a limiting factor in the capability to produce scientific results timely and efficiently. Recently, new technologies and new approaches have been developed in industry to answer to the necessity to retrieve information as quickly as possible to analyze PB and EB datasets. Providing the scientists with these modern computing tools will lead to rethinking the principles of data analysis in HEP, making the overall scientific process faster and smoother.
In this paper, we are presenting the latest developments and the most recent results on the usage of Apache Spark for HEP analysis. The study aims at evaluating the efficiency of the application of the new tools both quantitatively, by measuring the performances, and qualitatively, focusing on the user experience. The first goal is achieved by developing a data reduction facility: working together with CERN Openlab and Intel, CMS replicates a real physics search using Spark-based technologies, with the ambition of reducing 1 PB of public data in 5 hours, collected by the CMS experiment, to 1 TB of data in a format suitable for physics analysis.
The second goal is achieved by implementing multiple physics use-cases in Apache Spark using as input preprocessed datasets derived from official CMS data and simulation. By performing different end-analyses up to the publication plots on different hardware, feasibility, usability and portability are compared to the ones of a traditional ROOT-based workflow.
Facilitating Collaborative Analysis in SWAN
Authors: Bocchi Enrico , Castro Diogo , Gonzalez Hugo , Lamanna Massimo , Mato Pere , Moscicki Jakub , Piparo Danilo , Tejedor Enric 
Published: September 2019

SWAN (Service for Web-based ANalysis) is a CERN service that allows users to perform interactive data analysis in the cloud, in a “software as a service” model. It is built upon the widely-used Jupyter notebooks, allowing users to write - and run - their data analysis using only a web browser. By connecting to SWAN, users have immediate access to storage, software and computing resources that CERN provides and that they need to do their analyses.
Besides providing an easier way of producing scientific code and results, SWAN is also a great tool to create shareable content. From results that need to be reproducible, to tutorials and demonstrations for outreach and teaching, Jupyter notebooks are the ideal way of distributing this content. In one single file, users can include their code, the results of the calculations and all the relevant textual information. By sharing them, it allows others to visualize, modify, personalize or even re-run all the code.
In that sense, this paper describes the efforts made to facilitate sharing in SWAN. Given the importance of collaboration in our scientific community, we have brought the sharing functionality from CERNBox, CERN’s cloud storage service, directly inside SWAN. SWAN users have available a new and redesigned interface where theycan share “Projects”: a special kind of folder containing notebooks and other files, e.g., like input datasets and images. When a user shares a Project with some other users, the latter can immediately see andwork with the contents of that project from SWAN.