dataesr/scientific-paragraphs-categorization huggingface dataset:
Scope and Challenges Scientific questions are answered by analysing the data obtained from suitably designed experiments and comparing measurements with predictions from models and theories. Such comparisons are typically performed long after data taking, but can sometimes also be executed in near-real time on selected samples of reduced size. The final stages of analysis are undertaken by small groups or even individual researchers. The baseline analysis model utilises successive stages of data reduction, finally reaching a compact dataset for quick real-time iterations. This approach aims at exploiting the maximum possible scientific potential of the data, whilst minimising the "time to insight" for a large number of different analyses performed in parallel. It is a complicated combination of diverse criteria, ranging from the need to make efficient use of computing resources to the management styles of the experiment collaborations.
This lowers the hurdle to start an analysis, enabling the community to communicate using a common analysis language, as well as making common improvements as additions to the toolkit quickly become available. The ongoing ROOT programme of work addresses important new requirements, in both functionality and performance, and this is given a high priority by the HEP community. An important new development in the analysis domain has been the emergence of new analysis tools coming from industry and open-source projects (e. g. Jupyter notebooks  [73] , the scikit-learn package  [74] ), and this presents new opportunities for improving the HEP analysis software ecosystem. The HEP community is very interested in using these software tools, together with established components, in an interchangeable way.
The main challenge will be to enable new open-source tools to be plugged in dynamically to the existing ecosystem and to provide mechanisms that allow the existing and new components to interact and exchange data efficiently. To improve our ability to analyse much larger datasets, R&D will be needed to investigate file formats, compression algorithms, and new ways of storing and accessing data for analysis and to adapt workflows to run on future computing infrastructures. Reproducibility is the cornerstone of scientific results. It is currently difficult to repeat most HEP analyses in exactly the manner they were originally performed. This difficulty mainly arises due to the number of scientists involved, the large number of steps in a typical HEP analysis workflow, and the complexity of the analyses themselves.
An often-stated requirement of the data reduction steps is to arrive at a dataset that "can fit on a laptop", in order to facilitate low-latency, high-rate access to a manageable amount of data during the final stages of an analysis. Creating and retaining intermediate datasets produced by data reduction campaigns, bringing and keeping them "close" to the analysers, is designed to minimise latency and the risks related to resource contention. At the same time, disk space requirements are usually a key constraint of the experiment computing models. The LHC experiments have made a continuous effort to produce optimised analysis-oriented data formats with enough information to avoid the need to use intermediate formats. Another effective strategy has been to combine analyses from different users and execute them within the same batch jobs (so-called "analysis trains"), thereby reducing the number of times data must be read from the storage systems.
This has improved performance and usability, and simplified the task of the bookkeeping. There has been a huge investment in using C++ for performance-critical code, in particular in event reconstruction and simulation, and this will continue in the future. However, for analysis applications, Python has emerged as the language of choice in the data science community, and its use continues to grow within HEP. Python is highly appreciated for its ability to support fast development cycles, for its ease-of-use, and it offers an abundance of well-maintained and advanced open source software packages. Experience shows that the simpler interfaces and code constructs of Python could reduce the complexity of analysis code, and therefore contribute to decreasing the "time to insight" for HEP analyses, as well as increasing their sustainability.
Increased HEP investment is needed to allow Python to become a first class supported language. One new model of data analysis, developed outside of HEP, maintains the concept of sequential reduction, but mixes interactivity with batch processing. These exploit new cluster management systems, most notably Apache Spark  [53, 75] , which uses open-source tools contributed both by industry and the data-science community. Other products implementing the same analysis concepts and workflows are emerging, such as TensorFlow  [76] , Dask  [77, 78] , Pachyderm  [79] , Blaze  [80] , Parsl  [81] , and Thrill  [82]. This approach can complement the present and widely adopted Grid processing of datasets. It may potentially simplify the access to data and the expression of parallelism, thereby improving the exploitation of cluster resources.
Machine Learning Machine Learning (ML) is a rapidly evolving approach to characterising and describing data with the potential to radically change how data is reduced and analysed. Some applications will qualitatively improve the physics reach of datasets. Others will allow much more efficient use of processing and storage resources, effectively extending the physics reach of experiments. Many of the activities in this area will explicitly overlap with those in the other focus areas, whereas others will be more generic. As a first approximation, the HEP community will build domain-specific applications on top of existing toolkits and ML algorithms developed by computer scientists, data scientists, and scientific software developers from outside the HEP world. Work will also be done to understand where problems do not map well onto existing paradigms and how these problems can be recast into abstract formulations of more general interest.
3. • Extend the physics reach of experiments by extending the role of ML at the analysis stage: handling data/MC or control/signal region differences, interpolating between mass points, training in a systematics-aware way, etc. • Compress data significantly with negligible loss of fidelity in terms of physics utility. As already discussed, many particle physics detectors produce much more data than can be moved to permanent storage. The process of reducing the size of the datasets is managed by the trigger system. ML algorithms have already been used very successfully for triggering, to rapidly characterise which events should be selected for additional consideration and eventually saved to long-term storage. In the era of the HL-LHC, the challenges will increase both quantitatively and qualitatively as the number of proton-proton collisions per bunch crossing increases.
Current Practices The use of ML in HEP analyses has become commonplace over the past two decades, and the most common use case has been in signal/background classification. The vast majority of HEP analyses published in recent years have used the HEP-specific software package TMVA  [87]  included in ROOT. Recently, however, many HEP analysts have begun migrating to non-HEP ML packages such as scikit-learn  [74]  and Keras  [88] , although these efforts have yet to result in physics publications from major collaborations. Data scientists at Yandex created a Python package that provides a consistent API to most ML packages used in HEP  [89]. Packages like Spearmint  [90]  and scikit-optimize  [91]  perform Bayesian optimisation and can improve HEP Monte Carlo work. This shift in the set of ML techniques and packages utilised is especially strong in the neutrino physics community, where new experiments such as DUNE place ML at the very heart of their reconstruction algorithms and event selection.
A particularly important application is to Liquid Argon TPCs (LArTPCs), which is the chosen detection technology for DUNE, the new flagship experiment in the neutrino programme. A proof of concept and comparison of DL architectures should be finalised by 2020. Particle identification can also be explored to tag the flavour of jets in collider experiments (e. g. , so-called b-tagging). The investigation of these concepts, which connect to Natural Language Processing  [93] , has started at the LHC and is to be pursued on the same timescale. • ML middleware and data formats for offline usage: HEP relies on the ROOT format for its data, wheras the ML community has developed several other formats, often associated with specific ML tools. A desirable data format for ML applications should have the following attributes: high read-write speed for efficient training, sparse readability without loading the entire dataset into RAM, compressibility, and widespread adoption by the ML community.
In devising experiment computing models for this era many factors have to be taken into account. In particular, the increasing availability of very high-speed networks may reduce the need for CPU and data co-location. Such networks may allow for more extensive use of data access over the wide-area network (WAN), which may provide failover capabilities, global and federated data namespaces, and will have an impact on data caching. Shifts in data presentation and analysis models, such as the use of event-based data streaming along with more traditional dataset-based or file-based data access, will be particularly important for optimising the utilisation of opportunistic computing cycles on HPC facilities, commercial cloud resources, and campus clusters. This can potentially resolve currently limiting factors such as job eviction.
With direct access, applications may use alternative protocols to those used by data transfers between sites. In addition, LHC experiments have been increasingly using remote access to the data, without any stage-in operations, using the possibilities offered by protocols such as xrootd or http. • Data granularity: the data is split into datasets, as defined by physics selections and use cases, consisting of a set of individual files. While individual files in datasets can be processed in parallel, the files themselves are usually processed as a whole. Before LHC turn-on, and in the first years of the LHC, these four areas were to first order optimised independently. As LHC computing matured, interest has turned to optimisations spanning multiple areas. For example, the recent use of "Data Federations" mixes up Data Management and Access.
These can overlap in functionality. Some are very HEP specific and recognised as over-complex: work is in progress to get rid of them. The acceptable architectures and operating systems are also defined at the WLCG level (currently x86 64, running Scientific Linux 6 and compatible), and sites can deploy these either directly onto "bare metal" or can use an abstraction layer, such as virtual machines or containers. There are different logical networks being used to connect sites: LHCOPN connects CERN with the Tier-1 centres and a mixture of LHCONE and generic academic networks connect other sites. Almost every experiment layers its own customised workload and data management system on top of the base WLCG provision, with several concepts, and a few lower-level components, in common. The pilot job model for workloads is ubiquitous, where a real workload is dispatched only once a job slot is secured.
Data management layers aggregate files in the storage systems into datasets and manage experimentspecific metadata. In contrast to the MONARC model, sites are generally used more flexibly and homogeneously by experiments, both in workloads and in data stored. In total, WLCG currently provides experiments with resources distributed at about 170 sites, in 42 countries, which pledge every year the amount of CPU and disk resources they are committed to delivering. The pledge process is overseen by the Computing Resource Scrutiny Group (CRSG), mandated by the funding agencies to validate the experiment requests, and to identify mismatches with site pledges. These sites are connected by 10-100 Gb links, and deliver approximately 500k CPU cores and 1 EB of storage, of which 400 PB is disk. More than 200M jobs are executed each day  [105].
Efficient running on heterogeneous resources will require a tighter integration with the computing models' higher-level systems of workflow and data management. Experiment frameworks must also successfully integrate and marshall other HEP software that may have its own parallelisation model, such as physics generators and detector simulation. Common developments across experiments are desirable in this area, but are hampered by many decades of legacy work. Evolving our frameworks also has to be done recognising the needs of the different stakeholders in the system. This includes physicists, who are writing processing algorithms for triggering, reconstruction or analysis; production managers, who need to define processing workflows over massive datasets; and facility managers, who require their infrastructures to be used effectively.
Only recently has CMS broken this tradition starting at the beginning of Run 2, by utilising all available cores in one process space using threading. ATLAS is currently using a multi-process fork-and-copy-onwrite solution to remove the constraint of one core/process. Both experiments were driven to solve this problem by the ever-growing need for more memory per process brought on by the increasing complexity of LHC events. Current practice manages systemwide (or facility-wide) scaling by dividing up datasets, generating a framework application configuration, and scheduling jobs on nodes/cores to consume all available resources. Given anticipated changes in hardware (heterogeneity, connectivity, memory, storage) available at computing facilities, the interplay between workflow and workload management systems and framework applications need to be carefully examined.
For these experiments, a subset of the conditions data is linked to the luminosity, leading to an interval of granularity down to the order of a minute. Insufficient or inefficient caching may impact the efficiency of the reconstruction processing. Another important challenge is ensuring the long-term maintainability of the conditions data storage infrastructure. Shortcomings in the initial approach used in LHC Run 1 and Run 2, leading to complex implementations, helped to identify the key requirements for an efficient and sustainable condition data handling infrastructure. There is now a consensus among experiments on these requirements  [118] : AT-LAS and CMS are working on a common next-generation conditions database  [119]. The Belle II experiment, which is about to start its data taking, has already developed a solution based on the same concepts and architecture.
A system tag consists of many intervals of validity or entries in the IOV table. Finally, each entry in the IOV table maps to a payload via its unique hash key. A relational database is a good choice for implementing this design. One advantage of this approach is that a payload has a unique identifier, its hash key, and this identifier is the only way to access it. All other information, such as tags and IOV, is metadata used to select a particular payload. This allows a clear separation of the payload data from the metadata, and may allow use of a different backend technology to store the data and the metadata. This has potentially several advantages: • Payload objects can be cached independently of their metadata, using the appropriate technology, without the constraints linked to metadata queries.
Research and Development Programme R&D actions related to Conditions databases are already in progress, and all the activities described below should be completed by 2020. This will provide valuable input for the future HL-LHC TDRs, and allow these services to be deployed during Run 3 to overcome the limitations seen in today's solutions. • File-system view of conditions data for analysis jobs: study how to leverage advanced snapshotting/branching features of CVMFS for efficiently distributing conditions data as well as ways to optimise data/metadata layout in order to benefit from CVMFS caching. Prototype production of the file-system view from the conditions database. • Identify and evaluate industry technologies that could replace HEP-specific components. • ATLAS: migrate current implementations based on COOL to the proposed REST-based approach; study how to avoid moving too much complexity on the client side, in particular for easier adoption by subsystems, e.
However, such engines are meant to be used as development frameworks and their usage in HEP code is not always evident. Code should be developed within them, while in HEP framework-based applications we often want to use graphics libraries that can be integrated in existing code. A number of HEP collaborations have started experimenting in building event display tools with such engines, among them Belle II and ATLAS, but their use is currently limited to the display of simplified data only. The new client-server architecture proposed as one of the visualisation R&D activities will ease the usage of WebGL technologies and game engines in HEP. For statistical data, ROOT has been the tool of choice in HEP for many years and satisfies most use cases. However, increasing use of generic tools and data formats means Matplotlib (Python) or JavaScript based solutions (used, for example, in Jupyter notebooks) have made the landscape more diverse.
Scope and Challenges Modern HEP experiments are often large distributed collaborations with several hundred people actively writing software. It is therefore vital that the processes and tools used for development are streamlined to ease the process of contributing code and to facilitate collaboration between geographically separated peers. At the same time, we must properly manage the whole project, ensuring code quality, reproducibility, and maintainability with the least effort possible. Making sure this happens is largely a continuous process and shares a lot with non-HEP specific software industries. Work is ongoing to track and promote solutions in the following areas: • Distributed development of software components, including the tools and processes required to do so (code organisation, documentation, issue tracking, artefact building), and the best practices in terms of code and people management.
Due to significant variations between experiments at various stages of their lifecycles, there is a huge variation in practice across the community. Thus, here we describe best practice, with the understanding that this ideal may be far from the reality for some developers. It is important that developers can focus on the design and implementation of the code and do not have to spend a lot of time on technical issues. Clear procedures and policies must exist to perform administrative tasks in an easy and quick way. This starts with the setup of the development environment. Supporting different platforms not only allows developers to use their machines directly for development, it also provides a check of code portability. Clear guidance and support for good design must be available in advance of actual coding.
To maximise productivity, it is very beneficial to use development tools that are not HEP-specific. There are many open source projects that are of similar scale to large experiment software stacks and standard tools are usually well documented. For source control HEP has generally chosen to move to git [123], which is very welcome, as it also brings an alignment with many open source projects and commercial organisations. A major benefit that has come with this technical choice is the use of social coding sites, such as GitHub [124] and GitLab  [125] , where code sharing and code review are far superior compared to previous solutions. Likewise, CMake  [126]  is widely used for the builds of software packages, both within HEP and outside. Packaging many build products together into a software stack is an area that still requires close attention with respect to active developments (the HSF has an active working group here).
Proper testing of changes to code should always be done in advance of a change request to be accepted. Continuous integration, where 'merge' or 'pull' requests are built and tested in advance, is now standard practice in the open source community and in industry. Continuous integration can run unit and integration tests, and can also incorporate code quality checks and policy checks that help improve the consistency and quality of the code at low human cost. Further validation on different platforms and at large scales must be as automated as possible, including the deployment of build artefacts for production. Training (Section 4) and documentation are key to efficient use of developer effort. Documentation must cover best practices and conventions as well as technical issues. For documentation that has to be specific, the best solutions have a low barrier of entry for new contributors, but also allow and encourage review of material.
Consequently, it is very useful to host documentation sources in a repository with a similar workflow to code, and to use an engine that translates the sources into modern web pages. Recognition of software work as a key part of science has resulted in a number of journals where developers can publish their work  [127]. Journal publication also disseminates information to the wider community in a permanent way and is the most established mechanism for academic recognition. Publication in such journals provides proper peer review, beyond that provided in conference papers, so it is valuable for recognition as well as dissemination. However, this practice is not widespread enough in the community and needs further encouragement.
This should be modeled along the lines of the Concurrency Forum  [116] , which was very successful in establishing demonstrators and prototypes that were used as experiments started to develop parallel data processing frameworks. • Continue the HSF working group on Packaging, with more prototype implementations based on the strongest candidates identified so far. • Provide practical advice on how to best set up new software packages, developing on the current project template work, and working to advertise this within the community. • Strengthen links with software communities and conferences outside of the HEP domain, presenting papers on the HEP experience and problem domain. The Scientific Computing with Python (SciPy), the Supercomputing Conferences (SCxx), the Conference of Research Software Engineers (RSE), and the Workshops on Sustainable Software for Science: Practice and Experiences (WSSSPE) would all be useful meetings to consider.
• Write a paper that looks at case studies of successful and unsuccessful HEP software developments and that draws specific conclusions and advice for future projects. • Strengthen the publication record for important HEP software packages. Both peer-reviewed journals [127] and citable software version records (such as DOIs obtained via Zenodo  [131] ). Longer term projects, to conclude by 2022, include the following: • Prototype C++ refactoring tools, with specific use cases in migrating HEP code. • Prototyping of portable solutions for exploiting modern vector hardware on heterogenous platforms. • Support the adoption of industry standards and solutions over HEP-specific implementations whenever possible. • Develop tooling and instrumentation to measure software performance where tools with sufficient capabilities are not available from industry, especially in the domain of concurrency.