dataesr/scientific-paragraphs-categorization huggingface dataset:
In recent years, a large number of artificial intelligence (AI) studies have been conducted to explore automated landmark locations  [7] [8] [9] [10] [11] [12] [13] [14]. Compared with traditional cephalometric analysis, AI landmark identification shows superiority in repeatability and efficiency  [11, 15]. Although there were several studies comparing the difference of cephalometric analysis between human and AI  [16] [17] [18] [19] [20] , the various automated cephalometric software available to practitioners still need to be evaluated with the development of AI application in orthodontics. Planmeca Romexis software is widely used for cephalometric analysis, and 2-dimensional automatic tracing is feasible and practical with this program. Rather than spending valuable time on training, supporting and monitoring the work of others, clinicians only need a few seconds to obtain the results of cephalometric analysis from it.
Therefore, it is important to evaluate the accuracy of this program as a potentially time-saving tool. Our study was designed to compare the automatic localization program with one of the most frequently used computer-assisted cephalometric analysis programs, Dolphin software. Moreover, as far as we know that there have been only a few studies involving both cephalometric landmark and measurement analysis, the accuracy of landmarks and measurements in terms of bone, teeth and soft tissue were evaluated respectively in this study to explore more comprehensively the potential application of AI cephalometric analysis in clinical work.
Data collection In this observational study, reconstructed lateral cephalograms (RLCs) processed from cone-beam computed tomography (CBCT) scans were assessed. The retrospective CBCT images obtained from the patient database at the Affiliated Hospital of Stomatology, Nanjing Medical University were collected for the purposes of clinical diagnosis and analysis including airway volume analysis, temporomandibular joint or alveolar bone assessment and so on. A statistical power of 80% at a significance level (alpha) of 0. 05 using a two-sided paired t test was assumed by the G*power software (version 3. 1, Heinrich-Heine-University Dusseldorf, Germany). The calculation showed that 35 images were required with an effect size of 0. 49 according to the previous study  [17]. For this study, we searched the patient database and selected 85 patients who underwent CBCT from 2015 to 2020.
RLC acquisition and processing CBCT images were reconstructed into RLCs by using Dolphin software (version 11. 9, Chatsworth, California, USA). The orthogonal projection type was chosen to create non-distorted images. All RLCs were generated with optimal opacity of hard tissue visualization and adjusted with the slider to sharpen the images. Then, the RLCs were entered into the computer-assisted manual analysis program (Dolphin software) and the automatic cephalometric analysis software (Planmeca Romexis software, version 6. 2, Helsinki, Finland).
Statistical analysis Analyses were conducted using IBM SPSS, version 23 (IBM Corp. , Armonk, NY). Statistical significance was defined as a two-sided P value < 0. 05. The Shapiro-Wilk test was used to test the normality of the distributions. The error of landmark positions was identified by superimposing ruler points using the x and y coordinates. The radial error R was calculated between manually detected and AI-detected landmark coordinates: R = ∆x 2 + ∆y 2 The mean radial error (MRE), standard deviation (SD) and successful detection rate (SDR) were calculated as follows (in the following equations, N denotes the sample size, and z refers to the precision ranges of 1, 2, 2. 5, 3, and 4 mm. ) MRE = N i=1 R i N SD = N i=1 (R i -MRE) 2 /(N -1) SDR = the number of successfully detected landmarks or measurements within the range of z N * 100% The MRE; SD; and SDR at 1, 2, 2.
Discussion Cephalometric analysis is essential in every stage of orthodontic treatment. However, manual analysis has low consistency between repetitions and takes a great deal of time. With the rapid development of technology, computer vision allows machines to understand and work with images for cephalometric landmark detection after being trained with a given dataset. In contrast to conventional manual methods, AI can assess images within seconds, helping users save time and increasing the efficiency of repetitive work  [11, 15]. According to our study, humans take an average of nearly 80 times as long as the AI program to complete the task. Using an automatic program saves a great deal of time and frees up orthodontists for other tasks. Additionally, the accuracy of cephalometric landmark digitization depends largely on the operator.
2002). This approach is also flexible in implementing hundreds of chemical reactions and is as efficient as the hard-coding approach. This approach was used in the kinetic preprocessor (KPP) originally developed by  Damian et al. (2002) , which has been widely used for chemical kinetic models for Earth's atmosphere (e. g. ,  Roldin et al. 2019). In this paper, we present a new integrated photochemical model named Photochemical and RadiatiOn Transport model for Extensive USe (PROTEUS), with a totally integrated approach. PROTEUS couples Python and Fortran modules, which is designed for adaptability to many planetary atmospheres, for flexibility to deal with thousands of or more chemical reactions with high efficiency, and for intuitive operation with a graphical user interface (GUI). A Python GUI program integrates a list of chemical reactions, GUI functions controlling the behavior of GUI operation, and a string parsing functions analyzing chemical reactions that output a Fortran 90 module.
Fortran 90 modules solve differential equations numerically. Chemical reactions are written in a simple and flexible string format in the Python GUI program, making it easy to add new chemical reactions into the Python GUI program. The feature of PROTEUS that the Python GUI program outputs a Fortran 90 module is similar to the preprocessing approach, leading to a high efficiency, however, the Fortran modules in PROTEUS are not hard-coded but is rather generic. PROTEUS has been newly developed and independent of other photochemical models or KPPs that have been developed so far.
Either v i J +1/2 or � i J +1/2 is given for each i th species as an upper boundary condition, or they are set to zero if not needed. Note that the velocity and flux with positive values at upper boundary conditions also direct vertically upward. The basic equations of the photochemical model are stiff equations in which some of the variables such as the number densities of short-lived species change more quickly than others. Therefore, PROTEUS has applied an implicit scheme described by  Catling and Kasting (2017) , in which the density and flux are solved simultaneously. Note that the production rate P i j and the loss rate L i j are functions of the number density. Jacobian components related to the production and loss rates are analyzed by the Python GUI program. The timestep can gradually increase from an initial value 10 -8 s to ideally more than 10 14 s, allowing us to investigate from a sporadic event response in several minutes to the evolution of planetary atmospheres in a billion-year time scale.
Structure of PROTEUS PROTEUS consists of a Python GUI program and of Fortran 90 modules. The Python GUI program contains a list of chemical reactions for each planet, string parsing functions that parse the reactions and reaction rate coefficients selected in GUI, and GUI functions that control the behavior of GUI. Python language was adopted because of its flexibility in parsing strings and its capability in operating GUI. Fortran language was adopted to solve differential equations numerically. The structure of PROTEUS is illustrated in Fig. 1. Chemical reactions listed in the Python file are first read by GUI functions (arrow 1 in Fig. 1 ). Then, users select reactions on GUI (arrows 2 in Fig. 1 ), which will be analyzed by string parsing functions (arrow 3 in Fig. 1 ) to output a Fortran 90 module named "v__in.
2. It should be noted that each Fortran 90 file contains several modules with distinct functions, but only the Fortran 90 file is indicated for simplicity. The main routine "e__main. f90" consists of three parts, (1) initialization, (2) calculation, and (3) finalization. The description of each parts and each Fortran 90 files are as follows. (1) All derived data types are defined in "v__tdec. f90". Information of the chemical reactions, boundary conditions, and calculation settings are defined in "v__in. f90". Physical constants and parameters of the planetary orbit are given in "c__prm. f90". Production rates calculated by other models (e. g. , ionization rate calculated by a meteoroid model  (Nakamura et al. 2022 )) can be input in "p__Mars. f90" and "p__Jupiter. f90″. The solar EUV flux is calculated by the EUVAC model and the absorption and ionization cross sections are defined in "p__EUVAC.
Graphical user interface The Python GUI program uses the tkinter package, a standard library of Python to use the Tcl/Tk GUI toolkit (https:// docs. python. org/3/ libra ry/ tkint er. html). The Python GUI allows users to easily and intuitively select a planet, chemical reactions of interest, and run the simulation. An example of GUI is shown in Fig. 3 , and the operation of GUI is as follows. Once the user runs the Python GUI program, one can select a planet as indicated ("1" in the upper panel of Fig. 3 ). After selecting a planet, one can create a new project directory, or select or rename a pre-existing project directory as indicated ("2" in the upper panel of Fig. 3 ). Then the chemical reaction list for the selected planet appears in the window (the lower panel of Fig. 3 ). Chemical reactions and their rate coefficients written in the Python GUI program are automatically converted into Unicode and displayed, making them easy to read.
The list of chemical species, the number of chemical species, indices, mass, and charge of each chemical species are automatically determined and written in "v__in. f90" at this time. Those text files are read by the Fortran 90 module "v__in. f90". One can also output those files, compile and run the Fortran codes by pressing "Output f90 module & Run model", which requires the installation of an open source software CMake into user's computer ("5" in the lower panel of Fig. 3 ). All the settings and selected reactions are saved, and users can use the same settings and selected reactions the next time they run GUI. At the end of the simulation, users can quickly plot the density Fig. 3  Overview of GUI and instruction of the operation profiles by pressing "Plot setting" button ("6" in the lower panel of Fig.
Format of chemical reaction list The main feature of PROTEUS is the simple format of chemical reaction list in the Python GUI program and on the GUI. Format of chemical reaction list in the Python GUI program and some examples are illustrated in Fig. 4. Any reactions and their rate coefficients are described in the following string format in the Python GUI program. Reaction and rate coefficient are separated by a colon ":", and left-and right-hand sides of the reaction are separated by an arrow "-> ". Chemical species can be written simply as string. For instance, ionized species "N 2 + ", "CO 2 + ", and "H + (H 2 O) 4 " are simply described as "N2+", "CO2+", and "H+(H2O)4", respectively, and electron is described as "e-". Isotope species such as " 13 CO 2 " can be written as "^13CO2". Each chemical species and an addition operator " + " or an arrow "->" should be separated by at least one space.
Reactions and their rate coefficients selected on GUI are parsed by the string parsing functions in the Python GUI program. Index for each chemical species is automatically determined by the string parsing function, and mass and charge of each chemical species are also automatically identified by the string parsing function. String of each species are automatically divided into constituent elements and mass is calculated by the sum of mass of all the elements, and charge is calculated by counting the number of " + " and "-" in the string of each species. The string parsing function analyzes which reaction produces or lose each chemical species. The rate coefficient expressions written in infix notation are first separated into tokens. Then the order of tokens in infix notation are converted into reverse Polish notation (i.
e. , postfix notation) and automatically labeled. The Fortran 90 modules calculates the reaction rate coefficient using the labeled tokens arranged in reverse Polish notation. This method allows PROTEUS to process a variety of expression of temperature-and altitude-dependent rate coefficients (as seen in Fig. 4 ) at high computational speed. All the information needed to calculate production rate, loss rate and Jacobian matrix are output as text files, which will be read by Fortran 90 module to apply the information about chemical reactions selected. The number of chemical species and reactions, mass and charge of chemical species, rate coefficient of each reaction and contribution of each reaction to production/loss of each species are automatically applied to Fortran 90 modules by reading those text files.
Conclusions We have newly developed a flexible one-dimensional photochemical model named PROTEUS, which consists of a Python GUI program and of Fortran 90 modules. Chemical reactions can be easily implemented into Python code as a simple string format, and users can intuitively select a planet and chemical reactions to be considered in their calculation on GUI. Chemical reactions selected on GUI are automatically analyzed by a string parsing code written in Python, which will be applied to Fortran 90 modules to simulate with selected chemical reactions on a selected planet. This paper presents examples of PROTEUS application to the Martian atmosphere and the Jovian ionosphere, which are in good agreement with previous numerical models. PROTEUS can significantly save time for those who need to develop a new photochemical model; they just need to add chemical reactions in the Python code and just select them on GUI to run a new photochemical model.
Acknowledgements This work is supported by the  International Joint Graduate Program in Earth and Environmental Sciences, Tohoku University  (GP-EES). YN was supported by  JSPS KAKENHI  Grant Number  JP22KJ0280. TY was also supported by  JSPS KAKENHI  Grant Numbers  JP23KJ0093 ,  JP23H04645 , and  JP22KK0044. SS was supported by  JSPS KAKENHI  Grant Number  JP22K03695. HK was supported by  JSPS KAKENHI  Grant Number  JP23KJ0201. SK was supported by  JSPS KAKENHI  Grant Number  JP22KJ0314. NT was supported by  JSPS KAKENHI  Grant Numbers  JP18H05439 ,  JP18KK0093 ,  JP19H00707 ,  JP20H00192 , and  JP22H00164.
Reference  [68] , for example, establishes limits on the electroweakino sector using light gravitino pair-production via electroweakino decay in the context of GMSB in the MSSM. This study shows that while LHC searches specifically designed for such scenarios are important, other LHC searches and measurements provide useful complementary constraints. Using the GAMBIT software  [77, 78] , we here go be-yond previous works by performing the first global fit of electroweakinos in the presence of a light gravitino. We include up-to-date results from LHC Run 2, described in Sec. 3. 1, and for the first time in a global fit we check that our models are allowed by a suite of measurements of SM-like final states using Contur  [79, 80] ; see Sec. 3. 2 for further details. Lastly, we include constraints from the Large Electron-Positron collider (LEP); see Sec.
LHC measurements of SM signatures The complexity of the phenomenology of the model means that the possibility that it may produce events which could contribute to well-measured SM-like final states must also be taken into account. This is the scenario for which Contur  [79, 80]  is designed. Via Rivet [133], Contur has access to an extensive library of measurements from the LHC experiments, mostly corrected for detector effects and thus not requiring explicit detector simulation. Simulated events are passed through Rivet and projected into the fiducial phase space of the measured cross sections. In the release of GAMBIT accompanying this paper, we have interfaced Contur and Rivet to the GAMBIT ColliderBit module. As binned unfolding of detector effects requires statistically stable bin populations, a χ 2 test has proven indistinguishable from Poisson log-likelihood differences for measurement interpretations.
The conclusion is markedly different in the present G-EWMSSM study, where only four distinct scenarios for electroweakinos below 1 TeV remain viable. There are several factors contributing to this result: (1) the overall stronger constraining power due to the now larger LHC data sets; (2) the diminishing of the data excesses that in  [17]  helped improve the fit for low-mass solutions in the EWMSSM; (3) the additional constraining power in the present study, coming from our inclusion of LHC measurements in addition to direct BSM searches; and (4) the distinctive G-EWMSSM collider signatures, in particular the photon signatures, that result in strong constraints on large parts of the G-EWMSSM parameter space.
However, we expect some impact here with increasing statistics in Run 3 and beyond to the High-Luminosity LHC, in particular on the parts of parameter space where there is bino production through the decay of heavier electroweakinos, which could realistically be pushed out beyond 1 TeV. We emphasise the still open interesting possibility of a reverse mass hierarchy of charginos and neutralinos, with m χ± 1 < m χ0 1 , with distinct signal predictions for LHC Run 3 searches. Although the base production cross section is not so high given their Higgsino nature, the preferred region of this scenario should be within reach of Run 3 statistics and the slightly higher centreof-mass energy, when considering all final states W W , W Z and W h. We make all our generated parameter samples available from Zenodo for further study  [201].
C. 3 Additions to ColliderBit ColliderBit  [182]  is the GAMBIT module that handles anything related to collider physics, 9 such as LHC searches, LEP limits and Higgs measurements. It is naturally the most relevant module used in a collider-focused study such as this one. We extended ColliderBit significantly for this study, implementing new LHC analyses (Appendix B), adding a new LEP limit, and introducing the ability to compute the likelihood for BSM models to agree with LHC SM-like measurements, using the new interfaces to Rivet and Contur. For the most part in this study we reuse the preexisting LEP upper limits on electroweakino production, which we re-interpret for the gravitino model. However, we added a new module function to compute the limit from an L3 multi-photon and missing energy search, which is exclusive of models such as this one.
For this purpose we added a new module function, L3_Gravitino_LLike, providing a capability of the same name, to compute the 95% CL upper limit on the cross section. The new capabilitiy and module function can be found in Table  4. The machinery for computing the likelihood for LHC measurements follows the structure of the existing Collid-erBit, where a Monte Carlo event generator (e. g. Pythia 8) is used to simulate hard scattering events at the LHC, each of those events is passed through a native detector simulation, then a collection of analyses, and a likelihood is computed from the resulting yields. In previous incarnations of ColliderBit, the events generated by Pythia 8 were immediately converted into a HEPUtils::Event type, which is needed for detector simulation and analysis of the events.
The new module function Rivet_measurements provides 9 With the exception of flavour, which is handled by FlavBit  [204]. an eponymous capability and analyses a given HepMC event using Rivet's measurements. Its output, a YODA 10  analysis object written as a stream, is then used by the module function Contur_LHC_measurements_from_stream, which provides the capability LHC_measurements and that runs the YODA analysis object through Contur to compute the likelihood. An additional module function, Contur_LHC_measurements_from_file provides the same capability and performs the same computation but starting from a YODA analysis object read from a file. Both of these functions return a Contur_object structure which contains the output from Contur, including the total likelihood value as well as the likelihood value per pool.
C. 4 New backend interfaces: Rivet and Contur One the major breakthroughs of this study is the simultaneous combination of LHC searches and measurements in the analysis. This is possible due to the newly developed interfaces to Rivet 3. 1. 5 [205] , which contains the extensive library of measurements, and Contur 2. 1. 1  [79] , which takes care of the rigorous statistical combination of the results from individual measurements. Rivet is written in C++, so its interface to GAMBIT is auto-generated using the package BOSS  [77] , to allow dynamic loading of Rivet classes. Although some modifications of BOSS were needed to interface Rivet, these will not be documented here, but in a future publication. This interface provides GAMBIT with access to the classes inside of Rivet and some of its global functions.
In particular, the only class of interest for the interface is the AnalysisHandler class, which handles the analysis of the passed HepMC events. The usage of this class in ColliderBit was described above. Note that at the time of writing, Rivet 3. 1. 5 and, in particular, the class AnalysisHandler, is not threadsafe. This class must therefore be used within a critical section. In addition to the aforementioned class, GAMBIT also uses the global function addAnalysisLibPath. This function is just called once at the beginning of the scan by the backend initialisation function to inform Rivet of the location of the analysis library. The interface to the Python package Contur opens the possibility to compute the likelihood for LHC measurements from a YODA analysis object generated by Rivet. Two backend convenience functions were implemented for this purpose: Contur_LogLike_from_file, which reads the analysis object from a YODA file, and Contur_LogLike_from_stream, which reads it from a standard stringstream.
Both of these functions provide the same capability Contur_Measurements, but with different signatures, as the former takes just a string with the YODA file path, and the latter a shared pointer to the stream. In addition, both functions take as an argument a list of options for Contur (see  [79]  for a list of useful options). The value returned by both functions is an object of the class Contur_output, which is a simple class designed to manage the Python dictionary produced by Contur. Lastly, the backend convenience function Contur_get_analyses_from_beam, which provides the capability Contur_GetAnalyses, is used to inform Rivet of the analyses known to Contur.
C. 5 Adaptations to Rivet and Contur Besides the implementation of the interfaces to Rivet and Contur on the side of GAMBIT, minor modifications of each of these packages were necessary to adapt them to the GAMBIT workflow. Typically, Contur is run on YODA files that have been generated in a separate Rivet run. However, in a high-performance computing environment, the cost of writing and reading from a YODA file at each parameter point would be prohibitive. Therefore, Rivet and Contur were adapted so that the YODA file could be passed between them in memory via stringstream. In Rivet, this means the AnalysisHandler class received a new overload to the write method to output to stringstream. This is also available in the Python interface, and became available as of Rivet 3. 1. 4. The changes to Contur were more significant.