dataesr/scientific-paragraphs-categorization huggingface dataset:
When terms make their first or other crucial appearances in the text, we cross-link them to their entries in the glossary. To the end of this arXiv submission, we also append the published Addendum to this paper, which describes the changes implemented in GAMBIT 1. 1 compared to GAMBIT 1. 0, including support for calling external Mathematica codes from GAMBIT. Within the 'manual' part of the paper, Sec. 3 describes in detail how a physics module in GAMBIT works, Sec. 4 details the system GAMBIT uses for interfacing with external codes, and Sec. 5 covers the internal model database and its influence on analyses and the rest of the code. Sec. 6 explains the user interface to GAMBIT and documents the available settings in the master initialisation file. Sec. 7 details the GAMBIT system for instigating scans by automatically activating different calculations, depending on the models scanned and the observables requested by the user.
Models The models already implemented in GAMBIT 1. 0. 0 are shown in Fig. 2 , and described in detail in Sec. 5. 4. Instructions for adding new models are given in Sections 5. 1 and 11. 1. GAMBIT automatically activates or disables module and backend functions 2  according to their compatibility with the BSM model under investigation. It does this using a hierarchical model database, where each model is defined as a set of free parameters and a series of relations to other models. Models can be declared as children of existing models, which implies that there exists a mapping from the child parameter space to some subspace of the parent space. Each child model comes with a function that defines the transformation required to take a parameter point in its space to a corresponding point in the parent parameter space.
When a user requests a scan of a particular BSM model, that model and its entire model ancestry are activated. This makes all module and backend functions that are compatible with any model in the activated ancestry available as valid building blocks of the scan. This provides maximum safety by forbidding any calculations that are not valid for the model under consideration, and maximum re-usability of modules, backends and their functions with new models, by providing certainty about which existing functions are 'safe' to use with new additions to the model hierarchy. A basic example of model and backend function activation/deactivation can be seen in Fig. 1. Functions A1 and C2 have been specifically declared as modeldependent and therefore require activation or deactivation by the model database.
GAMBIT computes this ordering, and uses it to determine the optimal order in which to evaluate the module functions, such that each module function is guaranteed to run before any other function that depends on its results. GAMBIT further optimises the ordering beyond the constraint implied by this condition, considering the typical evaluation time of each function as a scan progresses, and its role in ruling out previous parameter combinations. We explain this overall dependency resolution process in detail in Sec. 7. With a specific module function evaluation order in hand, GAMBIT passes the problem of actually sampling the parameter space to ScannerBit (Sec. 8). ScannerBit engages whichever statistical scanning algorithm and output method a user has selected in their input file (see Sec.
Linking this to a hierarchical model database then provides the means for GAMBIT to automatically adapt existing likelihood and observable calculations to new models, to the largest extent theoretically possible. New components of course need to be added when different physics is to be considered for the first time, but the level of automation allows the user to immediately identify the precise gaps in the theoretical chain in need of new work, rather then wasting time by coding almost identical functions for every new model. This is facilitated by extensive and informative error messages presented when a scan is attempted but some link in the dependency chain cannot be fulfilled. These messages explain, for example, when a given dependency cannot be filled by any known function, if a requisite backend appears to be missing, if appropriate functions seem to exist but are not compatible with the model being scanned, if multiple permitted options exist for resolving a given dependency or backend requirement, and so on.
gambit_backend_name = "MyBackend" gambit_backend_version = "1. 2" Then follows a set of path variables. All paths must be given either as absolute paths or relative to the main BOSS directory. Consider the following example: Here we assume that our example backend MyBackend 1. 2 is located in Backends/installed/MyBackend/1. 2 9 http://github. com/CastXML/CastXML The input_files variable is a list of the header files that contain the declarations for the classes and functions that are to be used from GAMBIT. Next, include_paths lists the paths where CastXML should search for any header files that are included from one of the input files. Finally, base_paths is a list of the base directories of the backend library. This is used by BOSS to differentiate between classes that are native to the backend and classes that are pulled in from external libraries.
Hierarchical model database In GAMBIT, a model is defined to be a collection of named parameters. These parameters are intended to be sampled by some scanning algorithm, according to some chosen prior probability distribution. 10 The physical meaning of these parameters is defined entirely by how they are interpreted by module functions. It is up to the writers of modules to ensure that parameters are used in a consistent manner. Consistent usage is facilitated by the GAMBIT model database that the dependency resolver (Sec. 7) employs in order to automatically determine which module functions are compatible with which models. Module functions that are incompatible with the model(s) selected for scanning are disabled at runtime, and not considered during dependency resolution.
The "family tree" of any given model is thus a directed rooted tree graph, with the root of the tree being the common ancestor of all other models in the graph. The complete model database consists of a disconnected set of such family trees, see Fig. 2. When assessing the compatibility of module function with the model(s) being scanned, the GAMBIT dependency resolver automatically treats all module functions that declare compatibility with a given model as also compatible with all descendents of that model. To declare that a model has a parent model parent, and assign a function to_parent capable of performing the translation from the child to the parent parameter set, the model declaration can be expanded to the following: #define PARENT parent #define MODEL my_model START_MODEL DEFINEPARS(my_par1, my_par2) INTERPRET_AS_PARENT_FUNCTION(to_parent) #undef MODEL #undef PARENT If a model is declared to have a parent but no translation function, any attempt to use another function that depends on the translation will trigger a runtime error from the dependency resolver.
GAMBIT 1. 0. 0 ships with two printers: ascii and hdf5. The ascii printer outputs data as a simple ASCII table, whereas the hdf5 printer writes data to a binary file in HDF5 format  17. The former format is useful for its simplicity, however the latter is far superior when dealing with large datasets, particularly in terms of disk usage and read/write speed. We have also upgraded the external analysis tool pippi  [182]  to accept GAMBIT input in these formats; it can be easily retrieved via the GAMBIT build system (Sec. 11. 3). Most options that affect the output system are entered in the Printer section of the master YAML file. The basic layout of this section is: Printer: printer: plugin_name options: option_1: value_1 option_2: value_2. That is, one chooses a plugin plugin_name and sets its options, which vary with the plugin.
Specific options: hdf5 printer There are three specific options for this plugin: Printer: printer: hdf5 options: group: "/" delete_file_on_restart: false The first is group, which defaults to "/". This option specifies the name of the group within the host HDF5 output_file in which data will be stored. HDF5 files are structured similarly to a filesystem (i. e. hierarchically) and a 'group' is analogous to a directory. Various objects (such as datasets, and other groups) are then stored within groups  18  The default value of "/" specifies the root group, and this option should rarely need to be set to anything else. A deeper-layer group can be specified e. g. as "/group1/group2/etc/". Absent groups at any layer will be automatically created. The second option is delete_file_on_restart. This option is mainly a convenience for performing repeated test scans, and causes the file specified by output_file to be deleted if it already exists when a run restarts (i.
The role of ScannerBit To launch a GAMBIT run, a user requests a parameter scan of a certain model, specifying ranges and priors of the model parameters, how to sample them, and the quantities that should be calculated and included in the scan. The GAMBIT model database activates the relevant model ancestry, which the dependency resolver uses together with the capabilities and types of the user's requested quantities to select and connect appropriate module and backend functions into a dependency tree. Choosing which values of the model parameters to run through this dependency tree is the job of Scanner-Bit, the sampling and statistics module  [112]. Scanner-Bit applies any prior transformations requested by the user, and activates the appropriate scanner plugin in order to run the requested sampling algorithm.
HDF5 output The output file produced by the hdf5 printer is set with the output_file option (Sec. 6. 6. 3). It contains a separate data record for every output quantity, each of length equal to the number of parameter space points evaluated during the scan. These datasets are located according to the group option (Sec. 6. 6. 3). The command-line utility h5ls (included in most HDF5 library distributions) can be used to probe the internal layout of an HDF5 file. This can be useful for inspecting the names given to each dataset, which are derived from the label supplied via the print commands (see Sec. 9. 1). The same information can also be obtained using the probe command in pippi  [182]. All datasets in the resulting HDF5 files are synchronised, meaning that items at index i in every dataset have been obtained from the same model point.
Each dataset comes with a second dataset of matching length, containing a flag indicating whether the data at the given index of the host dataset has been identified as valid or not. The labels for these datasets match their hosts, with _isvalid appended. For example, if an observable quantity some_obs was registered as invalid by GAMBIT for that point (perhaps because the result was unphysical), then the entry in the some_obs_isvalid dataset will be set to 0 (false). The _isvalid entries can thus be used as a mask for filtering out invalid or missing entries from the main dataset. This is done automatically in pippibut a simple example Python script that uses h5py to inspect the HDF5 output of a GAMBIT run serves to illustrate the above concepts: import h5py import numpy as np #Open the hdf5 file f = h5py.
Particle database The GAMBIT particle database provides standardised particle definitions for use throughout the code, in particular for referring to states in GAMBIT Spectrum, DecayTable and ProcessCatalog objects, which catalogue particle masses, decay and annihilation rates. It can be found in Models/src/particle_database. cpp. Declaring new particles can be done either in singular form add_particle("∼g", (1000021,0) ) or in sets, as add_particle_set("h0", ((25, 0),  (35, 0) ) ) In the first example, the gluino is declared with name "∼g", PDG code 1000021, and context integer 0. The context integer provides an additional index beyond the PDG code. This can be used to distinguish different particles that might employ the same PDG code under different circumstances, e. g. (s)fermion mass and gauge eigenstates.
In the second example, two new particles are declared, corresponding to the two neutral Higgses in the MSSM. The names of the new particles are constructed from the string "h0" and the indices of the individual particles in the set, such that "h0_1" is created with PDG code 25 and context zero, and "h0_2" is created with PDG code 35 and context zero. Essentially any number of particles can be placed together into a set in this manner. Equivalent versions of both add_particle and add_particle_set exist for adding SM particles in particular; these are add_SM_particle and add_SM_particle_set. SM particles are given special treatment and saved as such inside the database, so that filters to e. g. decay final states can be applied according to whether one of the final states is or is not part of the SM.
A special version of add_particle also exists for defining broad particle classes like 'quarks', 'baryons', 'mesons', etc, add_generic_particle("quark", (9900084, 0)) These generic states have rather limited applicability, as they cannot participate in mass spectrum calculations, but they can prove useful for specifying generic decay channels. Within the rest of GAMBIT, particles defined in the particle database can be referred to in three equivalent ways: 1. using their full name (e. g. "∼g", "h0_1", "h0_2", etc) 2. using their PDG-context integer pair (e. g. {35, 0}) 3. using their short name and set index (e. g. {"h0", 2}) The particle database itself contains various other helper functions for converting between these three conventions, and for converting particles into their corresponding anti-particles.
hpp, which must then be included from z /include/gambit/z /z _rollcall. hpp. The build system will automatically include the new header in Elements/include/gambit/Elements/module_types_rollcall. hpp. The above discussion applies not only to new types, but also to typedefs associated with different components of GAMBIT. One challenge in performing dependency resolution is that types are matched entirely as strings at runtime, meaning that the dependency resolver cannot recognise typedefs a priori. To allow it to understand typedefs and treat two types as equivalent for dependency resolution purposes, GAMBIT features a type equivalency database config/resolution_type_equivalency_classes. yaml. Entries in this file are equivalency classes of different types, such that the dependency resolver considers each type within an equivalency class to be identical to all the others in the same class.
Component databases and documentation Although this paper serves as a user and design guide to GAMBIT, as do Refs. [108] [109] [110] [111] [112]  for each module, GAMBIT also features two additional documentation systems. The first is a standard Doxygen documentation system, which gives basic information about classes, functions, variables, namespaces and macros defined in GAMBIT. The documentation can be generated with make docs, and is also available online at http://gambit. hepforge. org. The second is a set of descriptive databases, which document individual models, capabilities, scanners, objective test functions and priors. These are the descriptions that are brought up by the GAMBIT free-form diagnostic (cf. Sec. These files are in fact written in YAML, albeit much simpler YAML than the input file.
Configuration and automatic component registration GAMBIT uses the open-source cross-platform build system CMake 25  to configure and build the package. The configuration step identifies the system architecture, available compilers, libraries and GAMBIT components present on a user's system, and creates appropriate makefiles. CMake and GAMBIT support in-source and out-of-source builds, but we recommend the latter for ease of organisation. The canonical way to configure and make GAMBIT is therefore mkdir build cd build cmake. make The build system also incorporates a series of Python harvester scripts for code generation. These are used at both configuration and compile time to automatically detect modules, models, backends, printers, scanners, priors, test functions and associated types present in a user's personal GAMBIT configuration.
Codes written in Python and other languages can only be backended by GAMBIT 1. 0. 0 if they ship with a C API; supporting 'native language' backending of such codes is a high priority for future versions. This system provides a make target for each installed version of each scanner and backend, along with a corresponding make clean-name target (where name is the name of the backend or scanner), which calls distclean or similar in the backend source. Each scanner and backend also gets a target make nuke-name, which completely erases all downloaded and installed content for the component in question. The make scanners target installs and builds the latest versions of all registered external scanning algorithms, and the make backends target does the same for backends. All scanners or backends can be cleaned or nuked in one command with the make targets clean-scanners, nuke-scanners, clean-backends or nuke-backends.
Summary GAMBIT is a powerful, general, flexible and extensible tool for phenomenological and statistical analysis of particle theories Beyond the Standard Model. It includes modules specialised for spectrum and decay calculations, collider, flavour, DM and precision physics, a hierarchical model database of popular BSM theories, flexible interfaces to many of the most popular existing phenomenology codes, extensive statistical and parameter scanning options, and an automatic system for connecting different calculations to their required inputs, outputs and models. Here we have outlined the main features of the GAMBIT package itself; accompanying papers lay out the details of the individual modules  [108] [109] [110] [111] [112]  and present first BSM results  [119] [120] [121]  Multiple versions of this object exist (and new ones can be written), for handling output to different formats.
Users select which printer they want to use via the master initialisation file (Sec. 6. 6) purpose A tag attached to a request made by a user in the ObsLikes section of their YAML file. The tag is used by the scanner and likelihood container to select which module functions to include in the combined likelihood and use for directing the scan. nested module function A module function that must be run by a loop manager rather than directly by GAMBIT itself -usually in parallel inside an OpenMP block managed by the loop manager. parent model A model from which a child model descends, implying that any point in the parameter space of the child model can be interpreted as a point in (some subspace of) the parent parameter space. particle database An internal database in GAMBIT containing the names and PDG codes of all particles recognised by GAMBIT.
GAMBIT users can now access both public and private Mathematica packages from within GAMBIT modules. This new feature provides a seamless interface to Mathematica, indistinguishable from the existing GAMBIT backend interfaces to codes written in C, C++ and Fortran. Mathematica is proprietary software. It is the responsibility of the user to acquire a license in order to use the Mathematica framework. The number of Mathematica Kernel instances and that can be launched per Mathematica license is limited, and can be found by evaluating the variables $MaxLicenseProcesses and $MaxLicenseSubprocesses (typically 8 and 16 respectively for a standard Mathematica license). This addendum describes our implementation of the Mathematica interface. Sec. 1. 1 describes the mechanism used to communicate with the Mathematica Kernel from GAMBIT.
The first argument in each of these must be a C++ object with the appropriate type, e. g. for symbols and functions this is a C++ string, and the argument n_args corresponds to the number of arguments of the Mathematica function function_name. To interpret data received from the WSGet functions, one must also receive the packets sent by the Kernel. We use WSNextPacket(WSlink) to find the next packet head, WSNewPacket(WSlink) to skip the rest of the current packet, and WSError(WSlink) to check for errors during packet reception. All these messaging functions live in the header wstp. h, native to the Mathematica installation, and will be used by GAMBIT for different purposes, as described below. 1. 2 Preparing and configuring Mathematica backends.
context integer An integer assigned to a particular particle definition in the GAMBIT particle database, in order to distinguish it from another similar particle having the same PDG code. dependency A declaration that a given module function needs to be able to access the result of another module function, identified according to its capability and type. Dependencies are declared in module functions' entries in rollcall headers. dependency resolution The process by which GAM-BIT determines the module functions, backend functions and backend variables needed and allowed for a given scan, connects them to each others' dependencies and backend requirements, and determines the order in which they must be called. dependency resolver The component of the GAMBIT Core that performs dependency resolution.
Acknowledgements 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 ), NO-TUR (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 ),  European Commission Horizon 2020  ( Marie Skłodowska-Curie  actions  H2020-MSCA-RISE-2015-691164 ,  European Research Council Starting  Grant  ERC-2014-STG-638528 ), the  ERA-CAN+ Twinning Program  ( EU & Canada ), the  Netherlands Organisation for Scientific Research  ( NWO-Vidi 016.
scanners Add a scanner plugin declaration header ScannerBit/include/gambit/ScannerBit/scanners/ scanner_name/scanner_name. hpp. ScannerBit/include/gambit/ScannerBit/priors. needed, add source files in ScannerBit/src/priors. If See Ref. [112] for more details. objective test functions Add source files to ScannerBit/src/objectives/test_functions. See Ref. [112] for more details. types Exactly what to do depends on which compo-nent(s) the type is associated with; see the above entries and Secs. 4. 4 and 10. 5 for more information. When adding any of these components, developers should also add a description of the new component to the relevant component database (see Sec. 10. 7). Backends/include/gambit/Backends/backend_types/ backend_name_types. hpp.
Search methods for identification of studies We compiled the search strategy by combining tobacco-related terms with packaging-related terms. We adapted the terms used in the search in accordance with each database's search terminology. The MEDLINE search strategy is contained in Appendix 1. We included studies regardless of language. We only included published, peer-reviewed articles (see Discussion). Our searches started from 1980, as the concept of standardised packaging was introduced in 1986 and the first study published in 1987.