dataesr/scientific-paragraphs-categorization huggingface dataset:
This program currently has 8 ATLAS and 1 CMS supersymmetry (SUSY) analyses implemented, which it re-interprets based on fast simulation. Another tool, XQCAT  [13] , is designed specifically for testing scenarios with heavy extra quarks, based on a CMS search for top partners as well as two SUSY searches. Finally, ATOM  [14]  is being developed for calculating the efficiencies of signal and control regions of various LHC searches based on the Rivet  [15]  toolkit. 2  In addition to these stand-alone tools, developed mostly by theorists, one should note the RECAST framework  [16] , which aims at providing a generic platform for requests of re-interpretation of existing analyses; in this case the re-interpretation would be done by the experimental collaboration itself, using the official full simulation software.
In this paper, we follow a complementary approach. We present the implementation of several ATLAS and CMS SUSY analyses in MadAnalysis 5  [17, 18] , with simulation of detector effects based on Delphes 3  [19] , and propose to create a public analysis database (PAD) within this framework. MadAnalysis 5 offers a userfriendly platform for collider phenomenology, and the PAD we propose will be easily accessible to and extendible by the whole community. Our proposal is complementary to the existing tools mentioned above in that i) it is based on event simulation, thus avoiding the shortcomings of the Simplified Models approach; ii) the output is the number of events in the different experimental regions of an analysis , which can then be statistically interpreted by the user for a variety of tasks, including limit setting or developing efficiency maps for Simplified Models; and iii) it is a completely Open Source initiative.
In Section 2, we briefly recall some new features in MadAnalysis 5, which are pertinent for implementing LHC analyses, and describe the modifications to the Delphes 3 detector simulation which we adopted for this project. In Section 3, we present some ATLAS and CMS analyses which we implemented in the MadAnalysis 5 framework and report in detail on their validation. The relevant C++ codes are all publicly available and may thus constitute the foundation of the PAD. A module for a simplified statistical interpretation of the simulated signals is presented in Section 4. In Section 5 we provide some guidelines, on the one hand for the experimental collaborations regarding what material is needed for a reliable implementation and validation of an analysis, on the other hand for potential contributors to the framework as to how to validate a new analysis implementation.
Dealing with multiple signal regions in MadAnalysis 5 In most experimental analyses performed at the LHC, and in particular the searches considered in this work, a branching set of selection criteria ("cuts") is used to define several different sub-analyses ("regions") within the same analysis. In conventional coding frameworks, multiple regions are implemented with a nesting of conditions checking these cuts, which grows exponentially more complicated with the number of cuts. The scope of this project has therefore motivated us to extend the MadAnalysis 5 package to facilitate the handling of analyses with multiple regions, as first presented in  [21]  and described in detail in  [18]. From version 1. 1. 10 onwards, the implementation of an analysis in the MadAnalysis 5 framework consists of implementing three basic functions: -Initialize, dedicated to the initialization of the signal regions, histograms, cuts and any user-defined variables; -Execute, containing the analysis cuts and weights applied to each event; and -Finalize, controlling the production of the results of the analysis, i.
) syntax guarantees that a given event is discarded as soon as all regions fail the cuts applied so far. Histogramming is as easy as applying a cut. For example, as we are interested in the transverse-momentum distribution of the leading lepton, our code contains Manager()->FillHisto("pT(l)", SignalLeptons[0]->pt()); This results in the filling of a histogram, previously declared with the name "pT(l)" in the Initialize method, but only when all cuts applied to the relevant regions are satisfied. Finally, event weights often need to be applied at the analysis level to correct for the efficiency with which physical objects, such as electrons or jets, are identified or likely to trigger the event. In MadAnalysis 5, the weight of an event can easily be modified, if necessary, by using the SetCurrentEventWeight method of the manager class.
The 'MA5tune' of Delphes 3 Delphes  [19]  is a C++ framework dedicated to the simulation of a generic detector such as those used in collider experiments. Contrary to full detector simulation software, Delphes does not simulate the particle-matter interactions, but uses instead a parameterization of the detector response and reconstructs the main physics objects considered in the analyses. This simplified picture results in much faster simulations, while the accuracy level is maintained suitable for realistic phenomenological investigations. From the computing side, Delphes is a modular framework where developers can both add their own contributions and tune the default parameterization according to their needs. This modularity is based on a division of the simulation process into modules inspired by the TTask Root class, and the addition and removal of new elements are easily achievable through a Tcl configuration file.
Similarly, the content of the output Root files can be configured at will. In order to properly recast ATLAS and CMS analyses, a tuning of the version 3 of Delphes has been performed. In the original version of Delphes, an isolation criterion is applied to both leptons and photons, and only particles satisfying this requirement are stored in the output files. We have designed a new Delphes module named CalculationIsolation that allows one to move the isolation requirements in the analysis selection. This module computes several variables useful for the implementation of isolation cuts. Defining cone sizes of ∆R = 0. 2, 0. 3, 0. 4 and 0. 5, the number of tracks with a transverse momentum larger than a given threshold, the scalar sum of the transverse momenta of these tracks and the scalar sum of the calorimetric transverse energy deposits lying in the cones are evaluated and saved.
In addition, the default module of Delphes dedicated to the filtering of non-isolated lepton and photon candidates is switched off so that all candidates are kept in the output Root files. For consistency reasons, the Delphes module UniqueObject-Finder giving a unique identification to all reconstructed objects is bypassed. Isolation selection cuts can then be performed at the analysis level by means of the isolCones method of the RecLeptonFormat class of MadAnalysis 5, described in the previous subsection and in  [18]. Adding the isolation information to the output format yields an increase of the size of the output files. A cleaning of all collections is therefore in order to reduce the file sizes. First, collections such as calorimeter towers and particle-flow objects are not stored. Next, the (heavy) collection of all particles that have been generated at the different level of the simulation chain (hard scattering process, parton showering and hadronization) is pruned.
Only particles produced at the hard-scattering process level, as well as final-state leptons and b quarks present after parton showering, are stored. In addition, the relations between generated and reconstructed leptons have been retained, together with information on the origin (the mother particle) of each lepton. All these changes result in a reduction of the size of the produced Root files by about a factor of ten when compared to the files produced with the original configuration of Delphes. This tailored version of Delphes 3, which we internally call Delphes-MA5tune to avoid confusion with the original version, can conveniently be installed locally from the MadAnalysis 5 interpreter by typing in the command install delphesMA5tune Even if Delphes 3 is already installed on a given system, one will need this modified 'MA5tune' version of the program in order to run the MadAnalysis 5 analyses that we are presenting in this paper.
Note however that for the moment MadAnalysis 5 is not able to run with both Delphes and Delphes-MA5tune installed in parallel. This means that the user must take care that only the directory tools/delphesMA5tune (but not the directory tools/delphes) be available in his/her local installation of MadAnalysis 5. In order to process an (hadronized) event sample with the 'MA5tune' of Delphes, it is sufficient to start Mad-Analysis 5 in the reconstructed mode, import the considered sample and type set main. fastsim. package = delphesMA5tune set main. fastsim. detector = cms submit where cms can be replaced by atlas according to the needs of the user. Default detector parameters are employed and can be modified by the user, following the guidelines displayed on the screen. The output Root file can then be retrieved from the automatically generated working directory.
CMS: -Search for stops in the single-lepton final state  [23] : CMS-SUS-13-011; -Search for gluinos and squarks in events with three or more jets and E miss T  [26] : CMS-SUS-13-012; -Search for gluinos in opposite-sign dilepton events, large number of jets, b-jets and E miss T  [27] : CMS-SUS-13-016. Several more analyses are currently being implemented and validated. Below we give some details on these analyses, the level of documentation by the experimental collaboration, and the validation of our MadAnalysis 5 implementations. We begin with the CMS stop search in the single-lepton channel, which also served as our template analysis for developing the extensions of MadAnalysis 5 described briefly in Section 2 and in detail in  [18]. The related recast code  [22]  contains extensive comments, which should allow the interested reader to easily use it as template for implementing a different analysis.
CMS-SUS-13-011: search for stops in the single-lepton final state The CMS search for stops in the single lepton and missing energy, + E miss T , final state with full luminosity at √ s = 8 TeV  [23]  has been taken as a "template analysis" to develop a common language and framework for the analysis implementation. It also allowed us to test the new developments in MadAnalysis 5 which were necessary for carrying out this project. The analysis targets two possible decay modes of the stop: t → t χ0 1 and t → b χ+ 1. Since the stops are pairproduced, their decays give rise to two W -bosons in each event, one of which is assumed to decay leptonically, whilst the other one is assumed to decay hadronically. In the cutbased version of the analysis, 3  two sets of signal regions with different cuts, each dedicated to one of the two decay modes, are defined.
These two sets are further divided into "low ∆M " and "high ∆M " categories, targeting small and large mass differences with the lightest neutralino χ0 1 , respectively. Finally, each of these four categories are further sub-divided using four different E miss T requirements. In total, 16 different, potentially overlapping SRs are defined. Two cuts are based on rather complex and specific kinematic variables designed to reduce the dilepton t t background: a χ 2 resulting from the full reconstruction of the hadronic top and M W T 2 -a variant of the m T 2 observable. The implementation of the χ 2 quantity in our code was straightforward thanks to the C++ Root code provided on the CMS Twiki page. The M W T 2 variable is calculated with the standard MadAnalysis 5 method, see  [18] , according to the algorithm presented in  [31].
Explicitly, H T = jets p T , / H T = | / H T | = jets p T. (1) The event selection was primarily determined from the documentation in  [26]. This document describes six baseline selection criteria on the events, named MET Cleaning, No Lepton, n j > 2, H T > 500 GeV, / H T > 200 GeV, and Min ∆φ(jets, / H T ). We note that the MET Cleaning cut involves a detailed consideration of spurious signals in the CMS detector, which we cannot simulate with Delphes. Instead, we simply multiply our event count by the efficiency given by CMS. (We stress again that such efficiencies being publicly available is extremely helpful. ) We validated the recast code against cut-flow tables and distributions of the kinematic variables provided by the CMS analysis team as per our request. The benchmark scenarios used are (m g , m χ0 1 ) = (1100, 125) GeV for the T1qqqq, T1tttt and T5VV topologies, and (m q , m χ0 1 ) = (700, 100) GeV for the T2qq topology, with production cross sections of 10.
The MadAnalysis 5 implementation is available as  [43] , and a detailed validation note comparing the recast results to the CMS ones can be found at  [28]. 3. 3 CMS-SUS-13-016: search for gluinos in events with opposite-sign leptons, b-tagged jets and large missing energy The CMS analysis  [27]  searches for new physics in the multi-top final state. The primary target is gluino-pair production followed by g → t t χ0 1 , i. e. the T1tttt topology in the CMS simplified-model nomenclature. The dataset used corresponds to a total integrated luminosity of L = 19. 7 fb -1 at √ s = 8 TeV. The analysis is not published yet but available as a Public Analysis Summary (PAS), which is overall welldocumented. The signal selection requires two isolated leptons of opposite sign, a large number of jets, at least three b-tagged jets, and large missing transverse energy (E miss T > 180 GeV).
6  In SRB, the sensitivity to small squark-neutralino mass difference is increased by selecting events whose leading jet has a very large p T , which is likely to have been produced by ISR, recoiling against the squark-pair system. High thresholds on the leading jet and on the missing 6 This peculiar kinematic variable is not yet implemented as a standard method in MadAnalysis 5. We thus used the public code computing this quantity, including the correction due to ISR, available at http://projects. hepforge. org/mctlib. transverse momentum, which are required to be almost back-to-back in φ, are imposed. The leading jet is required to be non-b-tagged and two additional jets are required to be b-tagged. Just like for SRA, large values of ∆φ min and E miss T /m eff are required, thereby suppressing the multijet background.
The selection for SRB is finally completed by demanding that the additional hadronic activity is bounded from above, H T,3 < 50 GeV. Here, H T,3 is defined as the scalar sum of the p T of the jets, without including the three leading jets. The analysis is very well documented regarding physics, but for recasting purposes more information than provided in the physics paper  [24]  and on the analysis Twiki  page  [46]  was needed. Indeed this made the validation of the recast code seriously difficult in the earlier stages of the project. Since then, fortunately, two cut-flow tables were made public. Moreover, the ATLAS SUSY group provided us with general SUSY Les Houches Accord (SLHA)  [48]  input files which we used to simulate the signal, as well as with the exact versions of the MC tools used to generate the SUSY samples, which were not given in  [24].
Limit setting For the statistical interpretation of the results, we provide on [28] a Python code, exclusion CLs. py, for computing exclusions using the CL s prescription  [61]. 8 This code 8 The Python code requires SciPy libraries to be installed. can also be installed on a user system by typing in, from the MadAnalysis 5 interpreter, the command install RecastingTools which results in the file exclusion CLs. py being present at the root of any working directory created in the expert mode of MadAnalysis 5. We refer to  [18, 28]  for details on the creation of MadAnalysis 5 working directories. The exclusion CLs. py code takes as input the acceptance × efficiency information from the cut flow Saf files generated when executing an analysis implemented in MadAnalysis 5 (see Section 2. 1). Moreover, an Xml file, named analysis name.
txt, stored in the Input folder of the working directory, is the input file for running the analysis under consideration. Alternatively, the cross section can be given as argument when calling exclusion CLs. py. Concretely, the limit-setting code is called as. /exclusion_CLs. py analysis_name mypoint. txt \ [run_number] [cross section in pb] where the run number and cross section value are optional arguments. The run number x (default zero) identifies the output directory to use, as each execution of the analysis code yields the creation of a new output directory, analysis name x, for the x th execution of the analysis code (starting from 0). The procedure of exclusion CLs. py starts by selecting the most sensitive SR (i. e. , the one that yields the best expected exclusion, assuming that the number of observed events is equal to the nominal number of background events).
This is a standard procedure at the LHC whenever the SRs defined in the analysis are overlapping; here we use it as the default for all analyses. Then the actual exclusion is calculated, and the confidence level with which the tested scenario is excluded using the CL s prescription  [61]  is printed on the screen together with the name of the most sensitive SR. The same information is also stored in the file analysis name x. out, located in the working directory of the Output folder. Last but not least, if a negative number is given for the cross section, the code returns instead the nominal cross section that is excluded at 95% CL, computed using a root-finding algorithm. The core of the calculation works as follows. First, the number of signal events (n s ) is obtained as the product of the luminosity, signal cross section and acceptance × efficiency for the SR of interest.
We have tested the limit-setting code on the analyses presented in this paper and generally found good agreement with the official exclusions from ATLAS and CMS. Figures  13 14 15 give some illustrative examples. In particular, Fig. 13  shows the 95% CL exclusion limit in the neutralino versus gluino mass plane for the g → t t χ0 1 topology reproduced with the MadAnalysis 5 implementation  [45]  of CMS-SUS-13-016. This analysis has only one SR and thus provides a good test for our implementation of the CL s prescription. To prove that our procedure also works well for analyses with many SRs, Fig. 14  shows the 95% CL exclusion limit for the g → q q χ0 1 topology (T1qqqq) reproduced with the MadAnalysis 5 implementation  [43]  of CMS-SUS-13-012. We also find good agreement for the T1tttt and T5VV topologies for this analysis; the one case that works less well is the T2qq topology (squark-pair production with q → q χ0 1 ) for which the reproduced limit becomes unreliable for neutralino masses above about 200-250 GeV.
This is the case where the largest differences are encountered in the kinematic distributions, see Section 3. 4. None the less we see that the limit is reasonably well reproduced (note that the ±1σ uncertainty quoted by ATLAS is based only on the theory uncertainty of the cross section). Last but not least it is important to note that the module exclusion CLs. py is intended only as a lightweight tool for the user who wants an approximate but fast evaluation of the results of his/her simulation. Users who want to go beyond the simplifications made in exclusion CLs. py are encouraged to use e. g. the RooFit and RooStats machinery [62] adopted by ATLAS and CMS.
as validation material: unambiguously defined benchmark points, e. g. in the form of SLHA files (including the full mass spectrum and decay tables) and/or parton-level MC event files; exact configuration of MC tools: the ideal would be if the run cards and input scripts for MadGraph, Pythia, etc. were made available; if this is not the case, we need at least the exact versions of the MC tools and their basic settings; detailed cut flows for all benchmark points, showing each step of the analysis; histograms of kinematic distributions after specific cuts. Only if complete information is provided for an analysis can the recasting be done in a reliable way. In this respect is should also be noted that for any analysis in which SRs are combined the corresponding likelihood model should be made available by the collaboration.
Some more comments are in order. First, we note that code modules for special kinematical variables, as currently provided by CMS, are extremely useful. We highly appreciate this practice. Second, we note that having to read efficiencies, event numbers or other data off paper plots is very tedious and introduces unwarranted uncertainties, especially when dealing with log-scale plots. We therefore strongly encourage the collaborations to always provide their plots also in numerical form, be it on Hep-Data or on the analysis Twiki page. Finally, one could also imagine that the experimental collaborations directly provide validated MadAnalysis 5 implementations for certain analyses. While this would be an excellent way of documenting an analysis, this is of course left to the initiative and decision of the respective search groups.
Conclusions We have presented a new scheme for developing and deploying implementations of LHC analyses based on fast simulation within the MadAnalysis 5 framework. This can serve to create a public analysis database, which may be used and developed further by the whole community. The codes for the five analyses  [22, 43, 45, 51, 60]  that we published together with this paper are intended as a starting point for this database and may conveniently be used as templates for other analyses. We propose that the C++ codes of new implementations within this scheme be published via Inspire [63], as done here, best together with the physics paper they have been developed for. This way, each analysis implementation is assigned a Digital Object Identifier (DOI)  [30] , ensuring that it is uniquely identifiable, searchable and citable.
Acknowledgements We thank our experimental colleagues, in particular  Alessandro Gaz ,  Benjamin Hooberman ,  Christian Sander ,  Niki Saoulidou ,  Nadia Strobbe ,  Keith A. Ulmer ,  Frank Würthwein  from  CMS , as well as  Jamie Boyd ,  Marie-Helene Genest  and  Monica d'Onofrio  from  ATLAS  for help in the validation process and for providing additional information where needed. Moreover, we thank  Daniel Schmeier  and  Jamie Tattersall  for extremely useful discussions. This work originated from the  2013 Les Houches "Physics at TeV Colliders " workshop; the inspiring and open-minded atmosphere of this workshop has been crucial for this project. Partial financial support by the  French ANR  projects  12-BS05-0006 DMAstroLHC  and  12-JS05-002-01 BATS@ LHC , the  Theory-LHC-France initiative of CNRS/IN2P3 , and the " Investissements d'avenir, Labex ENIGMASS " is gratefully acknowledged.
4  in section 4) and finally instantiated when applied to the real industrial case (Fig. 6  in section 5). The architecture proposed in Fig. 2  represents a conceptual solution to the scientific problems identified through the framework presented in Fig. 1. Functionalities can be defined as follows: i) coloured symbols represent different interoperability issues; ii) the dark colour (process integration) indicates the problems that will be explicitly treated in this paper; iii) the light colour (GIS integration) represents problems that will be not addressed in this paper. This latter choice is justified by the estimated level of complexity, which is greater when considering a process integration framework. For each connection, two different perspectives are considered: model interoperability (unifying models to consider a common perspective to the interoperating software tools) and technical interoperability (including technical approaches, data formats, and interfaces).