dataesr/scientific-paragraphs-categorization huggingface dataset:
Loading the model file After the FeynRules package has been loaded 9  , the model can be loaded using the command LoadModel, LoadModel[ < file. fr >, < file2. fr >,. ] The model may be contained in one model file or split among several files. For FeynRules to run properly, the extension of each model file should be. fr. If the model description is entered directly in the Mathematica notebook, the list of files is then empty. In this case, LoadModel[] has to be executed after all the lines of the model description are loaded into the kernel. Any time the model description changes, the model must be reloaded. Currently, this means that the Mathematica kernel must be quit and the Feyn-Rules package and model must be reloaded from the beginning. An exception to this is the Lagrangian. It can be changed and extended without having to reload the model information.
6 Functions dedicated to superspace computations The FeynRules package comes with a set of predefined functions dedicated to superspace computations. First, FeynRules offers the possibility to employ the generators Q α and Q α of the supersymmetric algebra as well as the superderivatives D α and D α to perform superspace computations. In our con-ventions  [54] , these operators read Q α = -i ∂ ∂θ α + iσ µ α α θ α∂ µ , Q α = i ∂ ∂ θ α + iθ α σ µ α α∂ µ , D α = ∂ ∂θ α -iσ µ α α θ α∂ µ , D α = ∂ ∂ θ α -iθ α σ µ α α∂ µ. (4. 22) and can be called in FeynRules by typing Q α (expression) ↔ QSUSY[expression,alpha] , Q α(expression) ↔ QSUSYBar[expression,alphadot] , D α (expression) ↔ DSUSY[expression,alpha] , D α(expression) ↔ DSUSYBar[expression,alphadot]. The expression on which these operators act must be provided in its canonical form, employing the nc environment.
7). In that case, the FlavorIndex option singles out the one type of index in the Indices list which labels the ClassMembers. any Feynman diagram calculators (which in general work at the level of mass eigenstates). Secondly, we use the Definitions option to define a replacement rule that rotates the gauge basis to the mass basis. This teaches FeynRules to replace every occurrence of phi[i_], where i_ is a Mathematica pattern representing some arbitrary index, by the expression UU[i,j] Phi  [j]. Note the appearance of the environment Module in the right-hand side of the replacement rule. A Module is an internal Mathematica command that takes two arguments (1) a list of symbols {a,b,c,. }, (2) an expression X. The Module evaluates X and replaces every occurrence of the symbols in the list {a,b,c,.
The Lagrangian and the Feynman rules After we have defined the parameters and the fields of the model, we can write down its Lagrangian. It is sufficient to translate Eq. (5. 29) in terms of the symbols introduced in the previous subsections, Lscal = del[phibar[i], mu] del[phi[i], mu] - phibar[i] MM[i,j] phi[j] + (phibar[i1] lam[i1, i2] phi[i2]) * (phibar[j1] lam[j1, j2] phi[j2]) Let us note that we cannot write (phibar[i1] lam[i1, i2] phi[i2])^2 because this expression is ambiguous, (φ i λ ij φ j ) 2 = φ 2 i λ 2 ij φ 2 j. (5. 36) The first thing we should do is check that our mass matrix diagonalization worked properly. After loading the FeynRules package and the model, as presented in Sections 4. 1 and 4. 2, we issue the command.
CheckMassSpectrum[ Lscal ] If everything was done properly, FeynRules will state that all mass terms are diagonal and will check their numerical values against the numerical values for M1 and M2, which were set as the masses of Phi1 and Phi2, respectively. We have now all the ingredients to compute the Feynman rules of the model. Loading the FeynRules package and the model, as presented in Sections 4. 1 and 4. 2, issuing then the command FeynmanRules[ Lscal ] returns the vertex (all particles are considered in-going) Φ i 1 , Φ i 2 , Φ † i 3 , Φ † i 4 : iλ jk λ lm (U ki 1 U mi 2 + U mi 1 U ki 2 ) (U ji 3 U li 4 + U ji 4 U li 3 ). By default the vertex is outputted for particle classes, i.
Implementing the mixing declaration Another possible way to implement this model into FeynRules is to let it handle automatically the mixings among the gauge eigenstates. In order to do so, one should remove the option Definitions from the declaration of the scalar field S  [2]  and, instead, provide the list M$MixingsDescription with the right options. This alternative allows FeynRules to extract automatically the mass matrix M and further export it to the ASperGe package for a numerical diagonalization. In practice the M$ClassesDescription should only comprise the following two declarations S[1] == { ClassName -> Phi, ClassMembers -> {Phi1, Phi2}, RunASperGe[]; in order to generate the source code for ASperGe, diagonalize the mass matrix UU and update the values for M1, M2 and all the components of the mixing matrix UU.
FR$Parallelize = False This commands keeps all the slave Mathematica kernels running but only   28  Table  28 : Running time associated with the three FeynRules commands FeynmanRules (second line), WriteCHOutput (third line) and WriteUFO (fourth line), where the decay widths are not calculated. For this comparison, we use the Standard Model whose Lagrangian has been calculated before calling these commands. We compare version 1. 6 of FeynRules (second column) to version 2. 0 when using one (third column), two (fourth column), four (fifth column) and eight (last column) CPU cores. employs one of them for the computations. In Table  28 , Table  29  and Table  30 , we compare the running times of the code in three different contexts. Table  28  is dedicated to the Standard Model. We first compute the model Lagrangian and then execute the FeynmanRules command without performing the full expansion over flavor indices,.
Conclusions The FeynRules package allows a model builder to implement his/her new theoretical model in a unified format, independent of the matrix element generator it will be used in. The user inputs a list of fields, parameters, symmetry groups and Lagrangian. FeynRules then computes the Feynman rules and outputs them to the format appropriate for the Feynman diagram calculator of choice. Interfaces for CalcHep/CompHep, FeynArts/FormCalc, Mad-Graph Sherpa and Whizard/Omega are currently available which allow FeynRules models to be used natively with these Feynman diagram calculational packages without any modification to the packages. This has made these model implementations more robust, dependable and transferable. Since the first version of FeynRules, many new features have been added to Feyn-Rules requiring the release of a new major version with this accompanying manual.
Acknowledgments We are grateful to  Johan Alwall ,  Priscila de Aquino ,  Karen de Causmaecker ,  Nicolas Deutschmann ,  Jorgen D'Hondt ,  Camilo Garcia-Cely ,  David Grellscheid ,  Thomas Hahn ,  Valentin Hirschi ,  Fabio Maltoni ,  Olivier Mattelaer ,  Kentarou Mawatari ,  Bettina Oexl ,  Gizem Öztürk ,  Michel Rausch de Traubenberg ,  Thomas Reiter ,  Jürgen Reuter ,  Christian Speckner ,  Tim Stelzer  and  Yoshitaro Takaesu  for discussion and collaborations on the different interfaces. We acknowledge the support of the  IT team at UCLouvain  ( Vincent Boucher ,  Jerôme de Favereau ,  Pavel Demin ). The FeynRules team is grateful to the  IPHC laboratory  for support in organizing the 2010 and 2012 FeynRules meetings at  Mont Sainte-Odile. This work was supported in part by the  Research Executive Agency (REA)  of the  European Union  under the Grant Agreement number  PITN-GA-2010-264564  ( LHCPhenoNet ) and MCnetITN  FP7 Marie Curie Initial Training Network   PITN-GA-2012-315877.
A. A. acknowledges partial support of a PhD fellowship of the French ministry for education and research. A. A. and B. F were supported in part by the  French ANR   12 JS05 002 01 BATS@LHC  and by the  Theory-LHC-France initiative of the CNRS/IN2P3. Ce. D. was supported in part by the  U. S. Department of Energy  under Contract No. DE-FG02-13ER42001  and by the  NSF  grant  PHY-0757889. N. D. C. was supported in part by the  LHC-TI  under  U. S. National Science Foundation , grant  NSF-PHY-0705682 , by  PITT PACC , and by the  U. S. Department of Energy  under grant No. DE-FG02-95ER40896  and C. D. was supported by the  ERC  grant " IterQCD ".
DECENTMON2: a Benchmark for Generalized Decentralized Monitoring DECENTMON2 is an benchmark dedicated to decentralized monitoring. DECENTMON2 that consists of: a completely redeveloped version of DECENTMON  [10] , an implementation of the decentralized monitoring algorithm presented in Sec. 5. 2, a trace generator, and an LTL-formula generator. DECENTMON2 consists of 1,300 LLOC, written in the functional programming language OCaml. It can be freely downloaded and run from  [16]. The system takes as input multiple traces (that can be automatically generated), corresponding to the behavior of a distributed system, and a specification given by a deterministic finite-state automaton. Then the specification is monitored against the traces in two different modes: a) by merging the traces to a single, global trace and then using a "centralized monitor" for the specification (i.
The great nation built from people who can respects they history and origins. Reliefs at Borobudur temple contained many stories, including the history and origins of this nation. Starting from the life story of the royal, society, and customs at the time of the building of the temple was made, and so on. This study develops mobile Android software for identification of Borobudur Temple relief image object so that it can help travelers in translating the story and the information contained therein. Feature extraction method used is speeded-Up Robust Feature (SURF) and hierarchical k-means tree nearest-neighbor for identification. Identification testing of relief images is done by different variations, ie angle, distance, rotation, intensity of the light and wholeness of image input to see the effect on the relief image recognition results.
A description is provided of the software algorithms developed for the CMS tracker both for reconstructing charged-particle trajectories in proton-proton interactions and for using the resulting tracks to estimate the positions of the LHC luminous region and individual primary-interaction vertices. Despite the very hostile environment at the LHC, the performance obtained with these algorithms is found to be excellent. For tt events under typical 2011 pileup conditions, the average trackreconstruction efficiency for promptly-produced charged particles with transverse momenta of p T > 0. 9 GeV is 94% for pseudorapidities of |η| < 0. 9 and 85% for 0. 9 < |η| < 2. 5. The inefficiency is caused mainly by hadrons that undergo nuclear interactions in the tracker material. For isolated muons, the corresponding efficiencies are essentially 100%.
In addition, the tracking software must run sufficiently fast to be used not only for offline event reconstruction (of ≈10 9 events per year), but also for the CMS High-Level Trigger (HLT), which processes events at rates of up to 100 kHz. The scientific goals of CMS  [1, 2]  place demanding requirements on the performance of the tracking system. Searches for high-mass dilepton resonances, for example, require good momentum resolution for transverse momenta p T of up to 1 TeV. At the same time, efficient reconstruction of tracks with very low p T of order 100 MeV is needed for studies of hadron production rates and to obtain optimum jet energy resolution with particle-flow techniques  [3]. In addition, it is essential to resolve nearby tracks, such as those from 3-prong τ-lepton decays. Furthermore, excellent impact parameter resolution is needed for a precise measurement of the positions of primary pp interaction vertices as well as for identifying b-quark jets  [4].
Primary vertices from pp collisions are distributed over a luminous region known as the beam spot. Reconstruction of the beam spot and of the primary vertex positions is described in Section 6. This is intimately connected with tracking, since on the one hand, the beam spot and primary vertices are found using reconstructed tracks, and on the other hand, an approximate knowledge of their positions is needed before track finding can begin. All results shown in this paper are based on pp collision data collected or events simulated at a centre-of-mass energy of √ s = 7 TeV in 2011. The simulated events include a full simulation of the CMS detector response based on GEANT4  [6]. All events are reconstructed using software from the same period. The track-reconstruction algorithms have been steadily evolving since then, but still have a similar design now.
The CMS detector  [5]  was commissioned initially using cosmic ray muons and subsequently using data from the first LHC running period. Results obtained using cosmic rays in 2008  [7]  are extensively documented in several publications pertaining to the pixel detector  [8] , strip detector  [9] , tracker alignment  [10] , and magnetic field  [11] , and are of particular relevance to the present paper. Results from the commissioning of the tracker using pp collisions in 2010 are presented in  [12]. The CMS collaboration uses a right-handed coordinate system, with the origin at the centre of the detector, the x-axis pointing to the centre of the LHC ring, the y-axis pointing up (perpendicular to the plane of the LHC ring), and with the z-axis along the anticlockwise-beam direction. The polar angle θ is defined relative to the positive z-axis and the azimuthal angle φ is defined relative to the x-axis in the x-y plane.
The hits from these two modules, known as 'rφ' and 'stereo hits', can be combined into matched hits that provide a measurement of the second coordinate (z in the barrel and r on the disks). The achieved single-point resolution of this measurement is an order of magnitude worse than in rφ. The principal characteristics of the tracker are summarized in Table  1. Figure  2  shows the material budget of the CMS tracker, both in units of radiation lengths and nuclear interaction lengths, as estimated from simulation. The simulation describes the tracker material budget with an accuracy better than 10%  [13] , as was established by measuring the distribution of reconstructed nuclear interactions and photon conversions in the tracker.
The second step involves a search for compatible silicon modules in the layers returned by the navigation step. A module is considered compatible with the trajectory if the position at which the trajectory intercepts the module surface is no more than some given number (currently three) of standard deviations outside the module boundary. The propagation of the trajectory parameters, and of the corresponding uncertainties, to the sensor surface involves mathematical operations and routines that are generally quite time-consuming  [33]. Hence, the code responsible for searching for compatible modules has been optimized to limit the number of sensors that are considered, while preserving an efficiency of >99% in finding the relevant sensors. A complication is that the design of the CMS tracker is such that sensors often slightly overlap their neighbours, meaning that a particle can cross two sensors in the same layer.
Track reconstruction in the high-level trigger The CMS high-level trigger (HLT)  [39]  uses a processor farm running C++ software to achieve large reductions in data rate. The HLT filters events selected at rates of up to 100 kHz using the Level-1 (hardware) trigger. Whereas Level-1 uses information only from the CMS calorimeters and muon detectors, the HLT is also able to capture information from the tracker, thereby adding the powerful tool of track reconstruction to the HLT. Some examples of how this improves the HLT performance are listed below. • Requiring muon candidates that are reconstructed in the muon detectors to be confirmed through the presence of a corresponding track in the tracker greatly reduces the false reconstruction rate and substantially improves momentum resolution. • Energy clusters found in the electromagnetic calorimeters can be identified as electrons or photons through the presence of a track of appropriate momentum pointing to the cluster.
For the sake of simplicity, the number of pileup interactions superimposed on each simulated tt event is randomly generated from a Poisson distribution with mean equal to 8. This amount of pileup corresponds roughly to what was delivered by the LHC, when averaged over the whole 2011 running period. The tt events, and also the minimum-bias events used for the pileup, are generated with the PYTHIA 6 program  [45]. Simulated particles are paired to reconstructed tracks for evaluating tracking efficiency, fake rate, and other quantities discussed in this section. A simulated particle is associated with a reconstructed track if at least 75% of the hits assigned to the reconstructed track originate from the simulated particle. The association of simulated hits with reconstructed hits is possible because the simulation software records the particles responsible for the signal in each channel of the tracker.
Strip and pixel response to electronic noise is also recorded. Reconstructed tracks that are not associated with a simulated particle are referred to as fake tracks. Results for tracking efficiencies and for fake rates are presented in Section 5. 1. While the latter is evaluated only using simulated samples, the former is also measured in data as described in Section 5. 1. 3. The resolution obtained for track parameters is discussed in Section 5. 2. Unless indicated otherwise, all results pertaining to the performance are obtained using the set of 'high-purity' tracks defined in Section 4. 4. Finally, Section 5. 3 provides estimates of the CPU time required for different components of track reconstruction.
Results from simulated pp collision events This section presents the performance of the CTF tracking software for reconstructing trajectories of non-isolated charged particles generated in simulated LHC collisions. Compared to the results shown in the previous section for isolated particles, the tracking performance discussed in this section is affected by an additional important feature of LHC events: the large number of hits produced in the tracker at each LHC bunch crossing. These hits originate from the hundreds of primary particles and their interactions selected by the CMS triggers. Their number is increased by the combined effects of low-energy particles spiralling in the CMS magnetic field ("loopers"), and particles produced in temporally overlapping pileup collisions. In the following, we give examples of the kind of difficulties encountered by the tracking algorithm during the reconstruction of these events.
Resolution in the track parameters In the context of the reconstruction software of CMS, the five parameters used to describe a track are: d 0 , z 0 , φ, cot θ, and the p T of the track, defined at the point of closest approach of the track to the assumed beam axis. This point is called the impact point, with global coordinates (x 0 , y 0 , z 0 ). Thus d 0 and z 0 define the coordinates of the impact point in the radial and z directions (d 0 = -y 0 cos φ + x 0 sin φ). The azimuthal and polar angles of the momentum vector of the track are denoted by φ and θ, respectively. The resolution in the parameters is studied using simulated events, and estimated from track residuals, which are defined as the differences between the reconstructed track parameters and the corresponding parameters of the generated particles.
CPU execution time Track reconstruction is, by far, the most computationally challenging part of CMS data reconstruction: for processing pp events with pileup, it requires almost as much CPU time as all the other reconstruction modules together. Furthermore, as the number of pileup events increases, the number of tracks increases in proportion, but the number of hit combinations that can be assembled into seeds and track candidates increases much more quickly, leading to a far more rapid increase in the required CPU time. The mean CPU time per event for reconstructing tracks is shown in Table  6 , separated into needs for tracking iterations and for computational steps (track seeding, finding, fitting, etc). The CPU times are given for tt events, simulated either without pileup or with an average of 8 pileup events.
The maximum efficiency for the pixel tracks is ∼85%. The ∼15% inefficiency arises mainly from the presence of defective pixel modules (∼2. 4% of the read out chips in the CMS pixel detector are inoperative) and geometric inefficiency. The asymmetry between positive and negative η reflects the non-uniform distribution of the affected pixel modules. In the top-right plot of Fig. 24 , the efficiency drops at low p T because of the p T > 0. 9 GeV requirement on pixel tracks. Figure  24  also shows that the addition of pileup events leads to only a small loss in efficiency. Plots at the bottom left and bottom right in Fig. 24  show the fake rate as a function of η and p T , both with and without the presence of pileup. As observed for the full tracking algorithms in Section 5. 1, the fake rate increases significantly with |η| and p T.
Summary and conclusions CMS has developed sophisticated tracking and vertexing software algorithms, based on the Kalman filter, the Gaussian sum filter, and the deterministic annealing filter, to reconstruct the proton-proton collision data provided by the CMS silicon tracker. The implementation of these algorithms has been optimized for computational efficiency, required to keep up with the high data rates recorded using the CMS apparatus. The flexibility of this software is evident from the fact that, with only few changes, it has been adapted to provide the fast tracking needed for the CMS high-level trigger, which processes events at rates of up to 100 kHz. Furthermore, a dedicated version of the software that accommodates bremsstrahlung energy loss in the tracker material, is used to reconstruct electrons.
The CMS track and primary-vertex reconstruction software has already achieved or surpassed the performance levels predicted at the time that the tracker was originally designed  [21]. Evolution and refinement of tracking and vertexing algorithms will continue in the future, in order to meet the challenges of ever increasing LHC luminosity. Belgium); the Agentschap voor Innovatie door Wetenschap en Technologie (IWT-Belgium); the Ministry of Education, Youth and Sports (MEYS) of the Czech Republic; the Council of Science and Industrial Research, India; the Compagnia di San Paolo (Torino); the HOMING PLUS programme of Foundation for Polish Science, cofinanced by EU, Regional Development Fund; and the Thalis and Aristeia programmes cofinanced by EU-ESF and the Greek NSRF.
Each laboratory has made significant technical improvements at many stages or has adapted the technology for a particular new use. For example, improvements have been reported concerning the substratum and data capture. Functionalized glass  (36, 37) , hydrogel  (38, 39) , PVDF  (40, 41) , macroporous silicon  (42) , nitrocellulose polymers  (43, 44)  (Grace Bio-Labs; Maine Manufacturing; Sartorius), and planar wave guide surfaces (ZEPTOSENS)  (45)  have all been successfully implemented to improve sensitivity, spot morphology, precision, and accuracy. Further marked improvements have been made in informatics approaches to deal with sample handling, regional staining correction, quality control, and the identification of high-quality samples and reagents. In many cases these have been integrated into publicly available algorithms such as "Supercurve"  (46) , "Normacurve"  (31) , and the RPPanalyzer that is available as an R-Package on the CRAN platform  (47).