dataesr/scientific-paragraphs-categorization huggingface dataset:
An approach using look-up tables for efficiencies and extrapolations from simplified models removes the need for time consuming simulation, but tends to give very conservative results as a consequence. This is because the approach misses models that do not resemble the simplified models under consideration, but still have some acceptance to the analysis cuts that are used to generate the simplified model results. Furthermore, generating look-up tables must be repeated for the parameter space of every physics model of interest, making it hard to produce a generic code for the application of LHC constraints. The core strategy of the ColliderBit LHC module is instead to make each step of the simulation chain faster, using a combination of custom speed increases and parallel computing. The package thus performs a cross-section calculation, generates Monte Carlo events, performs an LHC detector simulation and then applies the analysis cuts for a range of LHC analyses, using a custom event analysis framework.
The user can then utilise the GAMBIT statistical routines to return LHC likelihoods. The basic processing chain is illustrated in Figure  1. The code is designed so that the user can choose, among available options, which software performs each step of this process, or, as an alternative, add an interface to an external code in place of an implemented option. Nevertheless, ColliderBit has a default chain implemented, and the current version contains the elements summarised in the following subsections.
Monte Carlo event generation For the ColliderBit event generation, we supply an interface to the Pythia 8  [54, 55]  event generator, alongside custom code that parallelises the main event loop of Pythia using OpenMP. 4 This substantially reduces the runtime, as seen in Table  1. In a parameter scan with GAMBIT the parameter sampling is parallelised using MPI. The additional OpenMP parallelisation of the LHC likelihood calculation in ColliderBit, along with similarly parallelised calculations in other GAMBIT modules, helps GAMBIT's overall scan performance to scale beyond the number of cores that the sampling algorithm alone can make efficient use of. For the purposes of BSM searches, many timeconsuming generator components also add little to the quality of relevant physics modelling, and can therefore be safely disabled.
This is compared with the GAMBIT cutflow obtained using Pythia 8 and BuckFast. Shown are the efficiencies for passing each cut (second and third columns), and the ratio of efficiencies (fourth column). For reference, we also show the cutflow results obtained using the CheckMATE package (taken from their public validation results)  [   [43] , a search for new physics in events with two b jets and missing transverse momentum. The cutflow is generated for a bottom squark pair-production simplified model (in which a pair of bottom squarks is produced with direct decay to a b-quark and a lightest neutralino, all other sparticles being decoupled), with mb = 500 GeV and m χ0 1 = 1 GeV. This is compared with the GAMBIT cutflow obtained using Pythia 8 and BuckFast. Shown are the percentages of the initial event sample after each cut, and the ratio of the GAMBIT and ATLAS numbers.
User interface The GAMBIT code consists of a series of separate code modules that calculate likelihoods for new physics models using data from flavour physics  [41] , astrophysics  [42] , electroweak precision physics  [40]  and collider physics (the present paper). These modules can be used as standalone tools (using a custom C++ driving code), or they can be used via the GAMBIT core framework that resolves dependencies between calculations, and steers scans with the aid of a dedicated scanning and statistics module  [39]. The advantage of using the latter is that it is by far the easiest way to define models, calculate spectra and perform decay width calculations. There are thus two ways to take advantage of the high-energy collider likelihoods provided by ColliderBit: either via the GAMBIT framework or by interfacing to ColliderBit as a standalone tool.
GAMBIT interface The GAMBIT framework  [1]  defines two sorts of function that can be used by each module within the framework: -Module functions: C++ functions within the GAM-BIT code itself. -Backend functions: functions that live within an external code, such as Pythia 8. In GAMBIT, each module function is given a tag, called a capability, that describes what it can calculate, be it an observable, e. g. the number of events expected at the LHC, or a likelihood, e. g. the combined likelihood of a set of LHC searches. Module functions may also have dependencies on other module functionswhich may live either in the same module or in another GAMBIT module -or backend requirements that are satisfied by backend functions or backend variables. A concrete example from ColliderBit is the capability of the combined LHC likelihood calculation (Table  7 ), which has dependencies on the numbers of events expected in CMS and ATLAS searches, and has a backend requirement relating to the functional form of the likelihood required.
Add the initialisation function namespace within SpecializablePythia::resetSpecialization. This function is located at the end of colliders/SpecializablePythia. cpp, and it allows for runtime selection of the Pythia 8 specialisation via a std::string. The namespaces for the new init functions must be included here using the IF_X_SPECIALIZEX macro. Thus, for our example top production init functions above, we would add: IF_X_SPECIALIZEX(Pythia_ttbar_LHC_13TeV) IF_X_SPECIALIZEX(Pythia_alltop_LHC_13TeV) 3. Recompile GAMBIT. (See Appendix A. ) 4. Activate the new init function. The choice of init function is specified within the GAMBIT YAML file in the "Rules" section for the operateLHCLoop module function. For example, to activate our "alltop" Pythia 8 configuration, this would be the YAML entry: -capability: ColliderOperator function: operateLHCLoop options: nEvents: [1000] pythiaNames: ["Pythia_alltop_LHC_13TeV"] silenceLoop: true The last of these options removes much of the output from the Pythia event generator.
We may also supply our chosen configuration with additional options right in the YAML file. We do this in the rules for the getPythia module function: -capability: HardScatteringSim function: getPythia options: Pythia_alltop_LHC_13TeV: ["Print:quiet = on", "PartonLevel:MPI = off", "PartonLevel:ISR = on", "PartonLevel:FSR = on", "HadronLevel:all = on"] We recommend registering commonly-used Pythia 8 configurations in colliders/SpecializablePythia. cpp as described above. However, it is also possible to set up custom Pythia configurations directly in the YAML file by specifying all relevant Pythia options there. In this case the configuration name given in pythiaNames must not match any of the registered init functions in colliders/SpecializablePythia. cpp. For each Pythia configuration, the choice of analyses and detector simulations can be varied.
The new particles have the following mass terms: L mass = - m 2 1 2 φ 2 1 + M U Ū U. ( 8 ) The new fermion interacts with the new scalar via the Lagrangian term L yuk = λ 1 φ 1 Ū P R u + h. c. , ( 9 ) where u is the SM up-quark field. We will simulate the process pp → Ū U where the U subsequently decays via U → uφ 1. To use this model with ColliderBit, we make use of the MadGraph5_aMC@NLO-Pythia 8 interface to generate matrix element code that can be used to supplement the internal processes in Pythia. Sample Mathematica notebook and Feynrules model files for generating UFO output are provided in ColliderBit/data/ExternalModel. The MadGraph5_aMC@NLO commands for generating matrix element code for coloured fermion production in proton collisions are as follows, assuming that the UFO model has been placed in the MadGraph5_aMC@NLO models directory: import model GambitDemo_UFO generate p p > uv uv∼ output pythia8 The resulting C++ code can be found in the src and include subdirectories of Backends/patches/ pythia/8.
212. EM/ExternalModel. This directory also contains two Pythia XML files that declare a new Pythia setting UserModel:all, and a version of the Pythia file ProcessContainer. cc that connects this setting to the generated matrix element code. The GAMBIT build system can be used to make a new version of the Pythia backend (8. 212. EM) with make pythia_8. 212. EM This command performs the following tasks: downloads Pythia in the usual way, but into a new location; copies the new matrix element code to the new location; updates the Pythia XML configuration files to define the new UserModel setting; updates the Pythia file ProcessContainer. cc to allow the user to run the new matrix elements using the setting UserModel:all = on; runs Pythia through BOSS  [1]  to construct the interface to GAMBIT; builds the new Pythia version.
Also, the ColliderBit option Pythia_doc_path (Table  8 ) must be set to Backends/installed/Pythia/8. 212. EM/ share/Pythia8/xmldoc in the input YAML file when ColliderBit is used as part of a GAMBIT run, or directly in the standalone code as shown in This instructs Pythia to produce Ū U pairs in proton collisions, but they will not decay unless instructed to do so via the input SLHA file. An example SLHA file generated with MadGraph5_aMC@NLO is provided in ColliderBit/data/ExternalModel_point. slha. This file contains a decay table for the U particle with a 100% branching ratio to an up quark and a φ 1. We remind the reader that the standalone example is only intended as a minimal way of running single points of a new model through ColliderBit. For a comprehensive study, including scanning over model parameters, the user should add the model in the GAMBIT model database and implement spectrum and decay calculations through the GAMBIT modules SpecBit and DecayBit as required.
Finally, there is an important subtlety regarding invisible particles. At the time of writing, the default PDG ID codes of new particles in Feynrules do not always correspond to those of invisible, uncharged particles. In the ColliderBit simulation chain, this means that the particles will not appear as missing energy in the detector simulation. According to the PDG ID code standard, invisible particles may have a PID of 12, 14 or 16 (SM neutrinos), 1000022 (lightest neutralino in a superysmmetric model), or 50-60 (for generic new BSM particles). The user can thus obtain correct behaviour for an invisible species by including the PDG code definition in the Feynrules field definition as in the following example:.
Conclusions ColliderBit is a new modular software code for the application of high-energy collider constraints to generic BSM physics models, written in the GAMBIT framework. This paper serves as an introduction to the code, and as a reference manual for users wishing to add new analyses or features. The code provides a rigorous and fast implementation of LHC constraints through a parallelised Monte Carlo simulation interfaced with several detector simulation options, including a new simulation based on four-vector smearing. A custom event analysis class allows the user to apply the same LHC analysis code to any level of detector simulation, and we supply likelihood routines capable of reproducing LHC cut and count searches, or binned shape fits. An interface to the Pythia 8 event generator allows the user to add matrix elements for new models.
Acknowledgements We thank the other members of the  GAMBIT Collaboration  for helpful discussions, comments and support. We are very grateful to  Torbjörn Sjöstrand  and  Peter Skands  for helpful discussions on the use of the Pythia event generator, and for code modifications to improve the efficiency and flexibility of its process selection and settings database. We warmly thank the  Casa Matemáticas Oaxaca , affiliated with the  Banff International Research Station , for hospitality whilst part of this work was completed, and the staff at  Cyfronet , for their always helpful supercomputing support. GAMBIT has been supported by  STFC (UK ;  ST/K00414X/1 ,  ST/P000762/1 ), the  Royal Society (UK ;  UF110191 ), Glasgow University (UK; Leadership Fellowship), the  Research Council of Norway  ( FRIPRO 230546/F20 ), NOTUR (Norway;  NN9284K ), the  Knut and Alice Wallenberg Foundation (Sweden; Wallenberg Academy Fellowship) , the  Swedish Research Council  ( 621-2014-5772 ), the  Australian Research Council  ( CE110001004 ,  FT130100018 ,  FT140100244 ,  FT160100274 ),  The University of Sydney (Australia ;  IRCA-G162448 ),  PLGrid Infrastructure (Poland) ,  Polish National Science Center (Sonata   UMO-2015/17/D/ST2/03532 ), the  Swiss National Science Foundation  ( PP00P2-144674 ), the  European Commission Horizon   2020 Marie Skłodowska-Curie actions  ( H2020-MSCA-RISE-2015-691164 ), the  ERA-CAN+ Twinning Program  ( EU & Canada ), the  Netherlands Organisation for Scientific Research  ( NWO-Vidi 680-47-532 ), the  National Science Foundation (USA ;  DGE-1339067 ), the  FRQNT (Québec)  and  NSERC/The Canadian Tri-Agencies Research Councils  ( BPDF-424460-2012 ).
Observations and Definition of Regions for Spectral Analysis Owing to its field of view of 18 arcmin and good energy coverage up to 10 keV, the Suzaku X-ray Imaging Spectrometer (XIS) provides the best existing dataset to study the extended X-ray emission from electrons in the cutoff region from the Vela X cocoon. We use data from three observations performed with Suzaku in 2006. The three observations cover different regions across the cocoon, as illustrated in Fig. 1 , i. e. , from North to South: 0) toward the Vela pulsar and inner PWN (60 ks), 1) and 2) toward the cocoon (61 ks and 18 ks, respectively). We combine Suzaku observations with gamma-ray data accumulated with H. E. S. S. from 2004 to 2016 as described below, for a total of > 100 h of livetime. For each Suzaku pointing we derive the X-ray and gamma-ray spectral energy distributions (SEDs) from the very same extraction region, so that we can subsequently derive the electron and magnetic field properties.
Analysis We process the X-ray data using the Suzaku software and applying standard event screening criteria. We restrict the analysis to energies > 2. 25 keV to exclude thermal emission from the Vela supernova remnant. We note that contamination from the Galactic ridge X-ray emission is negligible in our analysis regions. We evaluate the instrumental background based on night Earth's observations using the xisnxbgen tool. The spectra in all regions are well fitted with a single power law modified by a fixed Galactic interstellar absorption with hydrogen column density N H = 2. 59 × 10 20 cm -2  [3] , on top of the cosmic X-ray background parametrised as in  [4]. Based on this spectral analysis, we derive the X-ray SED in 10 energy bins between 2. 25 keV and 9. 5 keV. We add in quadrature to the statistical uncertainties a 10% systematic uncertainty on flux measurements  [5].
Furthermore, to ensure uniform energy thresholds among different observing times, thus reducing systematics, we include only candidate gamma-ray events with reconstructed energy > 0. 6 TeV in the subsequent analysis. The residual background from cosmic-ray showers is evaluated from data taken within the same pointing, excluding regions of the field of view that display significant gamma-ray emission according to the results of the H. E. S. S. Galactic Plane Survey, or where the brightness temperature at 44 GHz measured by Planck is > 1. 5 mK (indicating the presence of relativistic electron populations that may radiate in gamma rays). The significance image in Fig. 1  (right) is estimated using the ring background method  [8] , and subsequently applying the formula by Li & Ma  [9]. For the extraction of the spectra from the three analysis regions we apply the reflected background method  [8].
Acknowledgments The support of the  Namibian authorities and of the University of Namibia  in facilitating the construction and operation of H. E. S. S. is gratefully acknowledged, as is the support by the  German Ministry for Education and Research (BMBF) , the  Max Planck Society , the  German Research Foundation (DFG) , the  Alexander von Humboldt Foundation , the  Deutsche Forschungsgemeinschaft , the  French Ministry for Research , the  CNRS-IN2P3  and the  Astroparticle Interdisciplinary Programme of the CNRS , the  U. K. Science and Technology Facilities Council (STFC) , the  IPNP of the Charles University , the  Czech Science Foundation , the  Polish National Science Centre , the  South African Department of Science and Technology and National Research Foundation , the  University of Namibia , the  National Commission on.
2 he rest of this paper is organized as follows. In the following section, we introduce our procedure for training the ternary NNs detailing our use of teacher-student paradigm to eliminate the need for multiplications altogether during test time, while still benefiting all state-of-the-art techniques such as batch normalization and dropout during training. In Section III, we provide a survey of related works that we compare our performance with. We present our experimental evaluation on ternarization and the classification performance on five different benchmark datasets in Section IV. In Section V, we describe our purpose-built hardware that is able to handle both fully connected multi-layer perceptrons (MLPs) and convolutional NNs (CNNs) with a high throughput and a low-energy budget. Finally, we conclude with a discussion and future studies in Section VI.
IV. EXPERIMENTAL ASSESSMENT OF TERNARIZATION AND CLASSIFICATION The main goals of our experiments are to demonstrate, (i) the performance of the ternarization procedure with respect to the real-valued teacher network, and (ii) the classification performance of fully discretized ternary networks. We perform our experiments on several benchmarking datasets using both multi-layer perceptrons (MLP) in a permutation-invariant manner and convolutional neural networks (CNN) with varying sizes. For the MLPs, we experiment with different architectures in terms of depth and neuron count. We use 250, 500, 750, and 1000 neurons per layer for 2, 3, and 4 layer networks. For the CNNs, we use the following VGG-like architecture proposed by  [15] : (2 × nC3 ) -M P 2 -(2 × 2nC3 ) -MP2 -(2 × 4nC3 ) - M P 2 -(2 × 8nFC ) -L2SVM where C3 is a 3 × 3 convolutional layer, MP2 is a 2 × 2 maxpooling layer, FC is a fully connected layer.
We use L2SVM as our output layer. We use two different network sizes with this architecture with n = 64 and n = 128. We call these networks CNN-Small and CNN-Big, respectively. We perform our experiments on the following datasets: MNIST database of handwritten digits  [20]  is a well-studied database for benchmarking methods on real-world data. MNIST has a training set of 60K examples, and a test set of 10K examples of 28 × 28 gray-scale images. We use the last 10K samples of the training set as a validation set for early stopping and model selection. CIFAR-10 and CIFAR-100  [21]  are two color-image classification datasets that contain 32×32 RGB images. Each dataset consists of 50K images in training and 10K images in test sets. In CIFAR-10, the images come from a set of 10 classes that contain airplanes, automobiles, birds, cats, deer, dogs, frogs, horses, ships and trucks.
In CIFAR-100, the number of image classes is 100. SVHN (Street View House Numbers)  [22]  consists of 32× 32 RGB color images of digits cropped from Street View images. The total training set size is 604K examples (with 531K less difficult samples to be used as extra) and the test set contains 26K images. GTSRB (German Traffic Sign Recognition Benchmark Dataset)  [23]  is composed of 51839 images of German road signs in 43 classes. The images have great variability in terms of size and illumination conditions. Also, the dataset has unbalanced class frequencies. The images in the dataset are extracted from 1-second video sequences recorded at 30 fps. In order to have a representative validation set, we extract 1 track at random per traffic sign for validation. The number of images in train, validation and test set are 37919, 1290 and 12630 respectively.
In order to allow a fair comparison against related works, we perform our experiments in similar configurations. On MNIST, we only use MLPs. We minimize cross entropy loss using stochastic gradient descent with a mini-batch size of 100. During training we use random rotations up to ±10 degrees. We report the test error rate associated with the best validation error rate after 1000 epochs. We do not perform any preprocessing on MNIST and we use a threshold-based binarization on the input. For other datasets, we use two CNN architectures: CNN-Small and CNN-Big. As before, we train a teacher network before obtaining the student TNN. For the teacher network, we use a modified version of Binarized NN's algorithm  [6]  and ternarize the weights during training. In this way, we obtain a better accuracy on the teacher network and we gain considerable speed-up while obtaining the student network.
Since we already have the discretized weights during the teacher network training, we only mimic the output of the neurons using the step activation function with two thresholds for the student network. During teacher network training, we minimize squared Hinge loss with adam with mini-batches of size 200. We train at most 1000 epochs and report the test error rate associated with the best validation epoch. For input binarization, we use the approach described in  [12]  with either 12 or 24 (on CIFAR100) transduction filters. We do not use any augmentation on the datasets.
On occasion, performance even increases. This is due to teacher network's weight update, that allows the network to escape from local minima. In order to demonstrate the effect of ε in terms of run-time and classification performance, we conduct a detailed analysis without the optional staggered retraining. Figure  2  shows the distribution of the ratio of neurons that are ternarized exhaustively with different ε, together with the performance gaps on training and test datasets. The optimal trade-off is achieved with ε = 0. 95. Exhaustive search is used for only 20% of the neurons, and the expected value of accuracy gaps is practically 0. For the largest layer with 1000 neurons, the ternarization operations take 2 min and 63 min for dichotomic and exhaustive search, respectively, on a 40-core Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.
B. Classification Performance The classification performance in terms of error rate (%) on several benchmark datasets is provided in Table  IV. We compare our results to several related methods that we described in the previous section. We make a distinction between the fully discretized methods and the partially discretized ones because only in the latter, the resulting network is completely discrete and requires no floating points and no multiplications, providing maximum energy efficiency. Since the benchmark datasets we use are the most studied ones, there are several known techniques and tricks that give performance boosts. In order to eliminate unfair comparison among methods, we follow the majority's lead and we do not use any data augmentation in our experiments. Moreover, using an ensemble of classifiers is a common technique for performance boosting in almost all classifiers and is not unique to neural networks  [25].