dataesr/scientific-paragraphs-categorization huggingface dataset:
The average performance of the MRI WHS methods is not as good as that of the CT methods, concluded from the submissions. The challenges could mainly come from the low image quality and inconsistent appearance of the images, as well as the large shape variation of the heart which CT WHS also suffers from. Enlarging the size of training data is a commonly pursued means for improving the learning-based segmentation algorithms. However, availability of whole heart training images can be as challenging as the task itself. One potential solution is to use artificial training data, such as by means of data augmentation or image synthesis using generative adversarial networks  (Goodfellow et al. , 2014). Alternately, shape constraints can be incorporated into the training and prediction framework, which is particularly useful for the DL-based methods to avoid generating results of unrealistic shapes.
Conclusion Knowledge of the detailed anatomy of the heart structure is clinically important as it is closely related to cardiac function and patient symptoms. Manual WHS is laborintensive and also suffers from poor reproducibility. A fully automated multi-modality WHS is therefore highly in demand. However, achieving this goal is still challenging, mainly due to the low quality of whole heart images, complex structure of the heart and large variation of the shape. This manuscript describes the MM-WHS challenge which provides 120 clinical MRI/ CT images, elaborates on the methodologies of twelve evaluated methods, and analyzes their evaluated results. The challenge provides the same training data and test dataset for all the submitted methods. Note that these data are also open to researchers in future.
The diagrammatic rule in question constitutes a novel finding allowing for the straight summation of large classes of time-ordered diagrams at play in the time-independent formulation of BMBPT. Correspondingly, the traditional resolvent rule employed to compute time-ordered diagrams happens to be a particular case of the general rule presently identified. The code ADG is written in Python2. 7 and uses the graph manipulation package NetworkX. The code is also able to generate and evaluate Hartree-Fock-MBPT (HF-MBPT) diagrams and is made flexible enough to be expanded throughout the years to tackle the diagrammatics at play in various many-body formalisms that already exist or are yet to be formulated.
The algorithms developped to achieve this goal have been implemented in a numerical code called ADG for Automatic Diagram Generator, written in Python2. 7 and using the graph manipulation package NetworkX [37], which will be detailed as well. The program is also able to produce standard MBPT diagrams using similar techniques as those detailed below. Given that MBPT is indeed a subcase of BMBPT, we have chosen not to detail this feature of the code in the body of the paper. Extensions of the program to tackle other diagrammatic flavors are to be considered in the future. The paper is organized as follows. Section 2 recalls the basics of BMBPT and of the associated diagrammatic, underlining the difficulties to be overcome in order to achieve an automated generation and evaluation of diagrams of arbitrary orders.
Drawing associated BMBPT diagrams Once all allowed (p + 1) × (p + 1) adjacency matrices have been produced, the corresponding BMBPT diagrams can be drawn by simply reading the matrices, as each matrix element encodes the number of propagators going from one vertex to another. As the number of generated diagrams quickly increases with p, it is of interest to design a program to do it automatically. The program reads the content of the matrix and writes in a text file the appropriate drawing instructions for FeynMP [41], a L A T E X package used to draw Feynman diagrams. Although adjacency matrices are sufficient to draw the diagrams, one may want to perform operations on the diagrams. We thus chose to make use of a graph theory package for Python called NetworkX [37]. The package takes adjacency matrices as input and produces graph objects on which different operations can be performed.
For example, the check for topologically equivalent diagrams is performed using the built-in NetworkX function is_isomorphic and its related interfaces. Combining the MultiDiGraph object from NetworkX and object-oriented programming, it was possible to implement this test in a time-savy way, first checking that two graphs share basic structures properties (degree of the different nodes, twobody only or three-body operators character, etc. ) before performing the costly permutations eventually needed to check if they are indeed topologically equivalent. With topologically distinct NetworkX BMBPT diagrams at hand, we could adapt the program running through adjacency matrices to make it iterate through the nodes of the graph and obtain the FeynMP instructions accordingly. As an example, the output displaying the drawing instructions of the BMBPT diagram displayed in Fig.
Use of the ADG program ADG has been designed to work on any computer with a Python2. 7 distribution, and successfully tested on recent GNU/Linux distributions and on MacOS. Additionally to Python, setuptools and distutils packages must already be installed, which is the case on most standard recent distributions. Having pip installed eases the process but is not technically required. The NumPy, NetworkX and SciPy libraries are automatically downloaded during the install process. Additionally, one needs a L A T E X distribution installed with the PDFL A T E X compiler for ADG to produce the pdf file associated to the output if desired.
Run the program 6. 2. 1. Batch mode The most convenient way to use ADG is to run it in batch mode with the appropriate flags. For example, to run the program and generate BMBPT diagrams at order 4 for example, one can use adg -o 4 -t BMBPT -d -c where the -o flag is for the order, -t for the type of theory, -d indicates that the diagrams must be drawn and -c that ADG must compile the L A T E X output. A complete list of the program's options can be obtained via the program's documentation (see Sec. 6. 4) or through.
Steps of a program run Let us briefly recapitulate the different steps of a typical ADG run • Run options are set either by using the command-line flags entered by the user or during the interactive session via keyboard input. • ADG creates a list of adjacency matrices for the appropriate theory and perturbative order, and via NumPy, feeds them to NetworkX that creates MultiDiGraph objects. • Checks are performed on the list of graphs to remove topologically equivalent or anomalous graphs. • The list of topologically unique graphs is used to produce Diagram objects that store the graph as well as some of its associated properties depending on the theory (HF status, excitation level, etc. ). The expression associated to the graphs are extracted. • The program then prints on the terminal the number of diagrams per category and writes the L A T E X output file, the details of which depend on the options selected by the user, as well as a list of adjacency matrices associated to the diagrams.
The automated evaluation of all BMBPT diagrams of order p relies both on the application of algebraic Feynman's rules and on the design of a systematic method to perform the remaining p-tuple time integral. This method provides a novel diagrammatic rule allowing for the straight summation of large classes of time-ordered diagrams at play in the time-independent formulation of BMBPT. The standard resolvent rule employed to compute time-ordered diagrams one by one happens to be a particular case of the general rule presently identified. The code ADG is written in Python2. 7 and uses the graph manipulation package NetworkX. It is made flexible enough to be expanded throughout the years to tackle the diagrammatics at play in various many-body formalisms that either already exist or are yet to be formulated.
the operators as well as other features regarding output formatting. The function is designed to be as theory-agnostic as possible, calling for wrapper functions defined in the run module to generate the appropriate adjacency matrices, which are then recasted as NumPy matrices and fed to NetworkX to produce graphs that are then used to initialize the actual Diagram objects that the program uses. A few tests are applied to make sure only appropriate matrices are kept (corresponding to connected graphs, etc. ) before MBPT or BMBPT diagrams are produced, which encapsulate the NetworkX graph as well as other related properties stored as attributes (two-or three-body character, various tags, degrees of the vertices,. ). Checks for topologically identical diagrams are then performed. As this part of the program scales factorially with the number of diagrams considered, it constitutes the more time-costly part of the program when going to higher orders.
Especially, the is_isomorphic interface of NetworkX is itself time-costly as it performs permutations between the graph nodes. Consequently, the algorithm has been optimize to call it as rarely as possible. Diagrams are therefore first selected based on their two-or three-body character and Hartree-Fock or non-Hartree-Fock status, such that comparisons are done within a smaller set of diagrams. Additionally, checks on the set of in-and out-degrees of the vertices of the two graphs are made, leaving the need for a call to is_isomorphic to the fewest possible cases. Once only topologically distinct diagrams are kept, the program extracts the expressions associated to the diagrams depending of the formalism involved, and stores them as attributes of the diagram objects. Finally, output L A T E X files are produced, the exact content and formatting of which depend on user's input.
Computer-readable files are available as well for MBPT diagrams. Compilation of the main L A T E X file is then proposed to the user, and useless files produced by the program and the L A T E X compilation are deleted before exiting. • propagator_style selects the appropriate drawing instructions for propagators. • draw_diagram recovers the drawing instructions of a given diagram and copies them in the L A T E X file. • to_skeleton returns only the non-redundant links in a diagram, i. e. , only the minimal set of edges to infer the time relations. It is mostly used for time-structure diagrams, though its scope could be more general. • extract_denom returns the appropriate denomiantor for a diagram using the subgraph rule. • print_adj_matrices prints a computer-readable file with the adjacency matrices of the diagrams.
Acknowledgments This publication is based on work supported in part by the framework of the  Espace de Structure et de réactions Nucléaires Théorique (ESNT)  at  CEA. The authors thank  C. Drischler ,  M. Drissi ,  A. Gallo  and  C. Wellenhofer  for fruitful discussions,  B. Bally  and  V. Somà  for beta-testing the program as well as  J. Ripoche  and  V. Somà  for proofreading the manuscript.
Particle physics has an ambitious and broad experimental programme for the coming decades. This programme requires large investments in detector hardware, either to build new facilities and experiments, or to upgrade existing ones. Similarly, it requires commensurate investment in the R&D of software to acquire, manage, process, and analyse the shear amounts of data to be recorded. In planning for the HL-LHC in particular, it is critical that all of the collaborating stakeholders agree on the software goals and priorities, and that the efforts complement each other. In this spirit, this white paper describes the R&D activities required to prepare for this software upgrade.
Working groups were established on various topics which were expected to be important parts of the HL-LHC roadmap: Careers, Staffing and Training; Conditions Database; Data Organisation, Management and Access; Data Analysis and Interpretation; Data and Software Preservation; Detector Simulation; Data-Flow Processing Frameworks; Facilities and Distributed Computing; Machine Learning; Physics Generators; Security; Software Development, Deployment and Validation/Verification; Software Trigger and Event Reconstruction; and Visualisation. The work of each working group is summarised in this document. This document is the result of the CWP process. Investing in the roadmap outlined here will be fruitful for the whole of the HEP programme and may also benefit other projects with similar technical challenges, particularly in astrophysics, e.
Each experiment has developed its own workflow management and data management software to manage its share of WLCG resources. In order to process the data, the 4 largest LHC experiments have written tens of millions of lines of program code over the last 15 years  [25] [26] [27] [28]. This has involved contributions from thousands of physicists and many computing professionals, encompassing a wide range of skills and abilities. The majority of this code was written for a single architecture (x86 64) and with a serial processing model in mind. There is considerable anxiety in the experiments that much of this software is not sustainable, with the original authors no longer in the field and much of the code itself in a poorly maintained state, ill-documented, and lacking tests. This code, which is largely experiment-specific, manages the entire experiment data flow, including data acquisition, high-level triggering, calibration and alignment, simulation, reconstruction (of both real and simulated data), visualisation, and final data analysis.
Physics simulation is supported by a wide range of event generators provided by the theory community (PYTHIA  [31] , SHERPA  [32] , ALPGEN  [33] , MADGRAPH  [34] , HERWIG  [35] , amongst many others). There is also code developed to support the computing infrastructure itself, such as the CVMFS distributed caching filesystem  [36] , the Frontier database caching mechanism  [37] , the XRootD file access software  [38]  and a number of storage systems (dCache, DPM, EOS). This list of packages is by no means exhaustive, but illustrates the range of software employed and its critical role in almost every aspect of the programme. Already in Run 3 LHCb will process more than 40 times the number of collisions that it does today, and ALICE will read out Pb-Pb collisions continuously at 50 kHz. The upgrade to the HL-LHC for Run 4 then produces a step change for ATLAS and CMS.
Network bandwidth will probably continue to increase at the required level, but the ability to use it efficiently will need a closer integration with applications. This will require software developments to support distributed computing (data and workload management, software distribution and data access) and an increasing awareness of the extremely hierarchical view of data, from long latency tape access and medium-latency network access through to the CPU memory hierarchy. Taking advantage of these new architectures and programming paradigms will be critical for HEP to increase the ability of our code to deliver physics results efficiently, and to meet the processing challenges of the future. Some of this work will be focused on re-optimised implementations of existing algorithms. This will be complicated by the fact that much of our code is written for the much simpler model of serial processing, and without the software engineering needed for sustainability.
Proper support for taking advantage of concurrent programming techniques, such as vectorisation and thread-based programming, through frameworks and libraries, will be essential, as the majority of the code will still be written by physicists. Other approaches should examine new algorithms and techniques, including highly parallelised code that can run on GPUs or the use of machine learning techniques to replace computationally expensive pieces of simulation or pattern recognition. The ensemble of computing work that is needed by the experiments must remain sufficiently flexible to take advantage of different architectures that will provide computing to HEP in the future. The use of high performance computing sites and commercial cloud providers will very likely be a requirement for the community and will bring particular constraints and demand flexibility.
These technical challenges are accompanied by significant human challenges. Software is written by many people in the collaborations, with varying levels of expertise, from a few experts with precious skills to novice coders. This implies organising training in effective coding techniques and providing excellent documentation, examples and support. Although it is inevitable that some developments will remain within the scope of a single experiment, tackling software problems coherently as a community will be critical to achieving success in the future. This will range from sharing knowledge of techniques and best practice to establishing common libraries and projects that will provide generic solutions to the community. Writing code that supports a wider subset of the community than just a single experiment will almost certainly be mandated upon HEP and presents a greater challenge, but the potential benefits are huge.
The LArSoft Collaboration develops and supports a shared base of physics software across Liquid Argon (LAr) Time Projection Chamber (TPC) experiments, which includes providing common digitisation code. Similarly, an effort exists among the LHC experiments to share code for modeling radiation damage effects in silicon. As ATLAS and CMS expect to use similar readout chips in their future trackers, further code sharing might be possible. The Geant4 simulation toolkit will also evolve over the next decade to include contributions from various R&D projects, as described in the following section. This is required to ensure the support of experiments through continuous maintenance and improvement of the Geant4 simulation toolkit. This is necessary until production versions of potentially alternative engines, such as those resulting from ongoing R&D work, become available, integrated, and validated by experiments.
Research and Development Programme To meet the challenge of improving the performance by a large factor, an ambitious R&D programme is underway to investigate each component of the simulation software for the long term. In the following we describe in detail some of the studies to be performed in the next 3-5 years. • Particle Transport and Vectorisation: the study of an efficient transport of particles (tracks) in groups so as to maximise the benefit of using SIMD operations. • Modularisation: improvement of Geant4 design to allow for a tighter and easier integration of single sub-packages of the code into experimental frameworks. • Physics Models: extensions and refinements of the physics algorithms to provide new and more performant physics capabilities. • Other activities: integration of multi-threading capabilities in experiment applications; experiment-agnostic software products to cope with increased pileup, fast simulation, digitisation, and efficient production of high-quality random numbers.
These are developed as independent libraries so that they can also be used together with the current Geant4 transport engine. Of course, when used with the current Geant4 they will not expose their full performance potential, since transport in Geant4 is currently sequential, but this allows for a preliminary validation and comparison with the existing implementations. The benefit of this approach is that new developments can be delivered as soon as they are available. The new vectorised geometry package (VecGeom), developed as part of GeantV R&D and successfully integrated into Geant4, is an example that demonstrated the benefit of this approach. By the end of 2018 it is intended to have a proof-of-concept for the new particle transport engine that includes vectorised EM physics, vectorised magnetic field propagation and that uses the new vectorised geometry package.
A further use case is the possibility to use one of the Geant4 components in isolation, e. g. , to use hadronic interaction modeling without kernel components from a fast simulation framework. As a first step a preliminary review of libraries' granularity is being pursued, which will be followed by a review of intra-library dependencies with the final goal of reducing their dependencies. • 2019: Redesign of some Geant4 kernel components to improve the efficiency of the simulation on HPC systems, starting from improved handling of Geant4 databases on large core-count systems. A review will be made of the multithreading design to be closer to task-based frameworks, such as Intel's Threaded Building Blocks (TBB)  [62]. Physics Models It is intended to develop new and extended physics models to cover extended energy and physics processing of present and future colliders, Intensity Frontier experiments, and direct dark matter search experiments.
Experiment Applications The experiment applications are essential for validating the software and physics performance of new versions of the simulation toolkit. ATLAS and CMS have already started to integrate Geant4 multithreading capability in their simulation applications; in the case of CMS the first Full Simulation production in multithreaded mode was delivered in the autumn of 2017. Specific milestones are as follows: • 2020: LHC, Neutrino, Dark Matter, and Muon experiments to demonstrate the ability to run their detector simulation in multithreaded mode, using the improved navigation and electromagnetic physics packages. This should bring experiments more accurate physics and improved performance. • 2020: Early integration of the beta release of the GeantV transport engine in the experiments' simulation, including the implementation of the new user interfaces, which will allow the first performance measurements and physics validation to be made.
Research and Development Programme Seven key areas, itemised below, have been identified where research and development is necessary to enable the community to exploit the full power of the enormous datasets that we will be collecting. Three of these areas concern the increasingly parallel and heterogeneous computing architectures that we will have to write our code for. In addition to a general effort to vectorise our codebases, we must understand what kinds of algorithms are best suited to what kinds of hardware architectures. It is an area where collaboration with the computer science community is required. We also need to develop benchmarks that allow us to compare the physics-per-dollar-perwatt performance of different algorithms across a range of potential architectures, and find ways to optimally utilise heterogeneous processing centres.
• Computing architectures using technologies beyond CPUs offer an interesting alternative for increasing throughput of the most time-consuming trigger or reconstruction algorithms. Examples such as GPUs and FPGAs could be integrated into dedicated trigger or specialised reconstruction processing facilities, in particular online computing farms. The goal is to demonstrate how the throughput of toolkits or algorithms can be improved in a production environment and to understand how much these new architectures require rethinking the algorithms used today. In addition, it is necessary to assess and minimise possible additional costs coming from the maintenance of multiple implementations of the same algorithm on different architectures. • HEP experiments have extensive continuous integration systems, including varying code regression checks that have enhanced the quality assurance (QA) and quality control (QC) procedures for software development in recent years.