dataesr/scientific-paragraphs-categorization huggingface dataset:
In this case, visual estimation by the operator is straightforward. A neural-network approach could potentially replace the operator making the coagulation depth monitoring more robust in this mode. For the moment, the Retrospective Diagnostic mode was implemented in post-processing due to LabVIEW not allowing the creation of an overlayed image and its limited g (2) computing rate. We confirmed that our custom LabVIEW program using only CPU computing (no GPU) was capable of calculating g (2) on a 400x800 pixels frame using ensembles comprising 10 B-scans at a rate of 5 Hz with both noise and motion corrections. We expect that the use of faster programming language and the implementation of GPU-computing would easily allow our method to run in real-time. The depth targeting mode was performed in real time, automatically shutting off the therapy laser when the coagulation had reached the targeted depth.
TESS Photometry TYC 8003-1117-1 (also known as TOI-132) was observed by TESS in Sector 1 on Camera 2 in short-cadence mode (T exp = 2 minutes). The total time baseline of the observations is 27. 87 days, spanning from July 25th to August 22nd 2018. TOI-132 b was identified as a potential transiting planet signature by the Science Processing Operations Center (SPOC) in the transit search run on Sector 1  (Jenkins 2002; Jenkins et al. 2010 ) and promoted to TOI status by the TESS Science Office based on the SPOC Data Validation (DV) reports  (Twicken et al. 2018; Li et al. 2019 ). The target was selected from the TESS alerts website 1  , based on the magnitude of the star (V=11. 2 mag) and period of the candidate, since it presented a good opportunity to be confirmed relatively quickly with HARPS.
In addition, the DV report for TOI-132 b is very clean, and the planetary signature passed all of the diagnostic tests conducted by DV, including the odd/even depth test, the weak secondary test, the ghost diagnostic test, the difference image centroid shift test. We retrieved the photometry provided by the TESS SPOC pipeline  (Jenkins et al. 2016) , and accessed the data from the simple aperture photometry (SAP_FLUX) and the Presearch Data Conditioning simple aperture photometry (PDCSAP_FLUX,  Smith et al. 2012; Stumpe et al. 2014) , which contains systematics-corrected data using the algorithms previously used for Kepler (Jenkins 2017). The median-normalized SAP_FLUX photometry is shown in the top panel of Figure  1. Bottom panel shows the PDCSAP_FLUX photometry, divided by its median value and after applying a 4-σ clipping rejection.
Ground-based time-series photometry We acquired ground-based time-series follow-up photometry of TOI-132 as part of the TESS Follow-up Observing Program (TFOP) to attempt to rule out nearby eclipsing binaries (NEBs) in all stars that could be blended in the TESS aperture as potential sources of the TESS detection. Furthermore, we attempt to i) detect the transit-like event on target to confirm the event depth and thus the TESS photometric deblending factor, ii) refine the TESS ephemeris, iii) provide additional epochs of transit center time measurements to supplement the transit timing variation (TTV) analysis, and iv) place constraints on transit depth differences across filter bands. We used the TESS Transit Finder, which is a customized version of the Tapir software package  (Jensen 2013) , to schedule our transit observations.
We observed TOI-132 continuously for 443 minutes on UTC 2018 September 09 in R c band from the Perth Exoplanet Survey Telescope (PEST) near Perth, Australia. The 0. 3-m telescope is equipped with a 1530 × 1020 pixels SBIG ST-8XME camera with an image scale of 1. 2 pixel -1 resulting in a 31 × 21 field of view. A custom pipeline was used to calibrate the images and extract the differential photometry using an aperture with radius 8. 2. The images have typical stellar point spread functions (PSFs) with a full width at half maximum (FWHM) of ∼4. The data rule out NEBs in stars within 2. 5 of the target star that are fainter by as much as 6. 4 magnitudes in R c band. We also observed full predicted transit durations of TOI-132 continuously in z-short band on UTC 2018 November 14, UTC 2019 June 19, and UTC 2019 July 06 from the Las Cumbres Observatory (LCO) 1.
0 m telescopes  (Brown et al. 2013)  at Cerro Tololo Inter-American Observatory for 277, 335, and 283 minutes, respectively. Another full transit was observed continuously for 232 minutes in B-band on UTC 2019 August 02 from an LCO 1. 0 m telescope at Siding Spring Observatory. The 4096 × 4096 LCO SINISTRO cameras have an image scale of 0. 389 pixel -1 resulting in a 26 × 26 field of view. The images were calibrated by the standard LCO BANZAI pipeline  (McCully et al. 2018 ) and the photometric data were extracted using the AstroImageJ (AIJ) software package  (Collins et al. 2017). The November data rule out NEBs in all stars within 2. 5 of the target star that are fainter by as much as 8. 7 magnitudes in z-short band, which includes all known Gaia DR2 stars that are blended in the TESS aperture.
JOINT ANALYSIS We modeled the radial velocities and the photometry using the juliet 5  package  (Espinoza et al. 2019b). Table  3  shows the priors used in the analysis. We set up the initial priors for the period of the candidate and the time of transit (T 0 ) using the reported values in the TESS DV report document for TOI-132. Preliminary analysis was done by making use of Systemic Console v2  (Meschiari et al. 2009). We analyzed the radial velocities only to get an initial rough estimate of both instrumental and orbital parameters of the system such as the velocity semi-amplitude, eccentricity and minimum mass of the planet. The period and transit time were constrained using the updated values provided by TESS. Initial results for a 1-planet model with eccentricity fixed at zero, yields an RMS∼2.
TTV ANALYSIS In order to search for possible Transit Timing Variations in TOI-132 b, we computed the individual transit time of each light curve using the EXOFASTv2 code  (Eastman et al. 2013; Eastman 2017 ). EXOFASTv2 uses the Differential Evolution Markov chain Monte Carlo method (DE-MCMC) to derive  the values and their uncertainties for the stellar, orbital and physical parameters of the system. So as to obtain the transit time of each light curve, we fixed the stellar and orbital parameters to the values obtained from the global fit performed by juliet, except for the transit time and their baseline flux. If a planet follows strictly a Keplerian orbit, the transit time of a given epoch T c (E) is a linear function of the orbital period P: T c (E) = T c (0) + P × E (2) Where T c (0) is a reference transit time and E is the number of epochs since T c (0).
Nacional-21140646 and Proyecto Basal AFB-170002. JSJ is supported by FONDECYT grant 1161218 and partial support from CATA-Basal (PB06, Conicyt). ZMB acknowledges funds from CONICYT-FONDECYT/Chile Postdoctorado 3180405. JIV acknowledges support of CONICYT-PFCHA/Doctorado Nacional-21191829, Chile. M. E. acknowledges the support of the DFG priority program SPP 1992 "Exploring the Diversity of Extrasolar Planets" (HA 3279/12-1). KWFL, SzCs acknowledge support by DFG grant RA 714/14-1 within the DFG Schwerpunkt SPP 1992, "Exploring the Diversity of Extrasolar Planets". Funding for the TESS mission is provided by NASA's Science Mission directorate. NN acknowledges support by JSPS KAKENHI Grant Numbers JP18H01265 and JP18H05439, and JST PRESTO Grant Number JPMJPR1775. AS acknowledges financial support from the French Programme National de Planétologie (PNP, INSU).
2 ). The Forward Detector covers the polar angle range from 5 • to 40 • , while the Central Detector covers the polar angle range from roughly 35 • to 125 •. The total number of readout channels of CLAS12 is larger than 100k. Typical trigger rates are 15 kHz. In 2018, data rates of 500 MB/s with a live time of >95% were achieved. A total of ∼2 pB of data was accumulated in 2018. The CLAS12 offline reconstruction and analysis framework was developed to cope with the complexity of the spectrometer and the related data volumes. It consists of an extensive library of software tools, of detector reconstruction packages, and a framework to chain the reconstruction and analysis applications for data processing. Software tools have been designed to support and standardize event reconstruction including detector calibration and monitoring, data analysis, I/O functionality, database access, detector geometry, and to handle magnetic field based calculations.
Detector reconstruction packages are designed to extract from the raw data the relevant information for  particle reconstruction, such as tracks, hits, or clusters. These are the input information for the CLAS12 Event Builder, which sifts through the reconstructed detector output to identify particles and form the reconstructed event. The reconstruction components are deployed in a service-oriented platform (see  Section 2) , which provides the functionalities for data processing for both event reconstruction and the subsequent analysis. While the software framework supports multiple programming languages, the CLAS12 reconstruction packages and tools currently in use are developed in Java. This paper is organized as follows. The CLAS12 software framework and tools are described in Section 2.
The raw and reconstructed data formats are presented in Section 3. The monitoring, calibration, and event display applications are described in Sections 4 and 5. Section 6 provides a detailed description of the detector and event reconstruction packages, including selected results from reconstruction of simulated data that have been used to develop and validate the algorithms. The reconstruction performance on beam data is presented in Ref. [1]. Finally, Sections 7 and 8 present the data processing and code management procedures adopted for CLAS12.
Such applications are composed of interlocking building blocks called micro-services, which are linked together by data-stream pipes. The technology (e. g. a high-level programming language or hardware deployment details), as well as the algorithmic solutions used to process data, are encapsulated. The scope of a specific software application implemented in CLARA is determined by the micro-services that are included and by the order of their execution. A micro-service receives input data, processes it, and produces output data, where the I/O is organized into tabular structures called ''banks'' whose structure is configured by the specific service developer. A micro-service reacts to an input data stream, processes it, and passes processed data to the next micro-service in the data-flow path.
As a result, the CLAS12 data processing application is versatile and flexible, since the application building blocks can be improved individually and replaced with no need for structural changes in the framework. The CLAS12 micro-services are extensions of an abstract reconstruction engine, which includes common components such as initialization and event processing methods. This approach reduces and simplifies the development of an individual micro-service and enforces a common structure. The CLARA data-stream pipe is a data bus based on the xMsg messaging system that supports various protocols such as MPI, pub-sub, p2p, inproc, and shared memory. The CLARA orchestrator, i. e. the process level workflow management system, controls the overall process execution. The framework enables execution of software applications in multithreaded mode.
This is implemented via event-level parallelization for the CLAS12 reconstruction. The framework is specifically designed to do thread-based parallelization on multi-core machines, thereby allowing the simultaneous reconstruction of multiple events having as many active threads as the cores on the system. Fig. 3  shows the results of a scaling test on an Intel Xeon node (E5-2697A v4 @ 2. 6 GHz). Comparison with Amdhal's law indicates 99. 5% parallel efficiency over the 32 physical cores of the machine. The CLARA framework provides service interface implementations in Java, C++, and Python languages. At present, all of the CLAS12 reconstruction services deployed using the CLARA framework are written in Java.
Common tools The offline software of the CLAS12 project aims to provide tools that allow design, simulation, and data analysis to proceed in an efficient, repeatable, and understandable way. Most software engineering details are hidden from users, allowing them to concentrate on the algorithms and physics. To facilitate code development for the detector subsystems of CLAS12, the software was designed to provide libraries that are commonly used by all of the reconstruction packages. These libraries, referred to as ''common tools'', contribute to software maintainability by avoiding code replication, which facilitates code maintainability. The common tools consist of various packages, each having a specific purpose and functionality. Below we discuss the main packages used in the reconstruction software.
Geometry Due to the complexity of the geometry of the CLAS12 detector subsystems, an interface was developed to provide classes and software tools that are used to describe the geometry of all subsystems in a unified way. A library of primitives provides geometrical objects needed to represent all detector subsystems (these include lines, planes, and various shapes such as cubes, trapezoids, etc. ) and to provide the necessary transformations to accommodate misalignments and distortions. Furthermore, geometry tools provide methods to track particles through volumes for evaluation of track trajectories, such as line-tosurface intersections, ray tracing through objects, and evaluation of the distance of closest approach to a line or surface. The CLAS12 geometry library is initialized from a database containing key geometry parameters and their variations for every detector.
Databases The Calibration Constant Database (CCDB) software package was developed at Jefferson Lab for the GlueX experiment in Hall D  [17]. CCDB provides the functionality for storing and accessing structured tables in MySQL-based and SQLite portable databases. The CLAS12 reconstruction packages use the CCDB application programming interface to create and access tables that contain detector geometry and calibration constants, as well as maps used for decoding raw data. At the decoding stage, signals are converted from hardware notation (crate, slot, channel) into the CLAS12 notation (sector, layer, component). The constants in CCDB tables are linked to specific runs (using time stamps), so that different variations of constants are stored depending on run conditions. CLAS12 software tools employ an Application Programming Interface (API) that parses database tables and creates structured maps of constants stored in memory by detector sector, layer, and component.
Plotting and analysis tools For ease of integration with the reconstruction software tools and packages, the plotting tools used for data calibration, monitoring, and analysis were developed in the Java programming language. The plotting software, called groot, developed at Jefferson Lab for CLAS12 is tailored to have a programming interface similar to the CERN data analysis package, ROOT, and provides the necessary functionalities for histogram and graph creation, filling, and manipulation, as well as for fitting using the Java-based MINUIT library available from the JHEP repositories. This has been the base for the development of the detector monitoring and calibration suites (see Section 4). These same tools can also be used for physics analysis. An additional analysis package containing classes for four-vector manipulations allows computation of event kinematics (e.
Magnetic field package The magnetic field package, magfield, used by the CLAS12 reconstruction creates binary field maps from engineering models of the CLAS12 torus and solenoid  [18]. It employs a common self-described binary format, with a header containing meta-data describing the pedigree of the field, its grid coordinate system, and the coordinate system of the field components. For example, the CLAS12 torus has a cylindrical grid but Cartesian field components. The same magfield package provides the trilinear interpolation of the field (a method of multivariate interpolation on a 3-dimensional regular grid). Given that the field is often requested at a sequence of points all contained within a single grid cell, magfield uses time-saving software ''probes'' to cache nearest neighbors.
Swimmer package The swimmer package, in conjunction with the magfield package, is used in the CLAS12 reconstruction to propagate charged particles through the CLAS12 solenoid and torus fields. It uses a fourth-order (with fifth-order corrections) adaptive step-size Runge-Kutta integrator with single-step advancement that is achieved through a configurable Butcher tableau advancer. There are a number of convenience methods for swimming to a plane, to the closest point on a line, and to a specified value of a given (, , ) coordinate. For forward swimming in CLAS12, performance is improved by reducing the dimensionality of the track state vector that contains the main track parameters (Section 6. 2. 4), by changing the independent variable from the path length to the coordinate along the beamline, which defines the nominal CLAS12 -axis.
Framework A calibration framework was developed to implement visualization software tools needed for all detector systems. Standard views were developed using the Java Swing application to visualize detector components and to provide call-back mechanisms necessary to display detector-component specific information. These software tools provide functionality for data fitting, plotting, and displaying using a Graphical User Interface (GUI) environment. The calibration framework makes use of the other CLAS12 libraries (the geometry and plotting packages, as well as database utilities) and provides a uniform GUI for all calibration applications. The framework provides a data-processing interface and a calibration constant database interface used for online and offline data analysis. A common data-streaming interface is implemented with softwarelevel abstraction that allows the calibration and monitoring codes to run on all of the supported data formats used in CLAS12, including data read in real-time from the CLAS12 DAQ system  [20].
) ''view'', i. e. a graphical representation of CLAS12 in its entirety or a subset of its detector subsystems. For a given event, the primary purpose is to display the detector components that have recorded a signal, and, if available, the reconstructed tracks, to provide a visualization of the particle passage through the detector. In addition, ced can display information about the event such as the data banks, or information about the detector, such as the magnetic fields. Available views are both 2-and 3-dimensional with the possibility of disabling the latter for faster execution. An illustration of views in ced is shown in Fig. 6 , where a section of CLAS12 is displayed in a cut-view with a specific focus on the Forward Detector. The colored areas in the space around the detectors indicate regions where a significant magnetic field intensity is present from either the solenoid or torus; reconstructed tracks are shown by the orange lines.
Event reconstruction The event reconstruction software has been designed and developed within the CLARA framework. As discussed in Section 2, the reconstruction of events for CLAS12 is separated into micro-services that execute data processing algorithms. The data reader services access the detector decoded data stored in banks (see  Section 2). Each entry for the decoded detector hits is a row in a bank. A row includes detector element identifiers (sector, layer, component, and order), and digitized detector data, such as signal charge, amplitude, time, or pedestal, depending on the specific system. Similar bank structures are created at the decoding stage for the various quantities needed for event reconstruction, such as hits, clusters, tracks, etc. The micro-services that implement the reconstruction algorithms pertaining to the CLAS12 subsystems fill these banks, which are subsequently appended and written out to a file by a data-persistency micro-service.
Electromagnetic calorimeters The Electromagnetic Calorimeters (ECAL)  [7]  of the CLAS12 Forward Detector downstream of the torus and the FTOF are leadscintillator strip sampling calorimeters used for the detection of electrons, photons, and neutrons. A pre-shower calorimeter (PCAL) is positioned in front of the EC calorimeter, which consists of two parts, EC-inner (ECIN) and EC-outer (ECOU). The ECAL reconstruction service provides a fast and efficient algorithm for grouping scintillator strips with hits into multiple peaks and clusters within the three submodules, PCAL, ECIN, and ECOU, for each of the six ECAL modules, while leaving cluster matching and particle identification to the Event Builder service. Within the ECAL reconstruction service, these various elements exist as objects with methods, structures, and data members designed for calibration, pattern recognition, diagnostics, and serial output.
Event builder The Event Builder is the last service in the reconstruction algorithm, and performs a series of functions: • collects information from the upstream services; • correlates information from the sub-detectors into particles; • performs a general particle identification scheme; • organizes the resulting information into a standardized, persistent data bank structure. The service is run twice with identical algorithms, once using hitbased tracks, and later with time-based tracks, where the results of the hit-based Event Builder are used to initialize time-based tracking.
Data summary tapes The final data output is provided by the Event Builder in the form of data summary tapes (DSTs), a standardized selection of HIPO banks for physics analysis. The trains mentioned above are run on input DST files to produce skimmed output DSTs. These include: Fig. 29. Schematic flow of analysis trains. The example shows a train composed of a plugin to correct the ECAL sampling fraction (SF) and several analysis filters for different final states. Events from a HIPO file are read by the IO service and processed through the analysis chain that applies the selected corrections and labels them according to the different filters. The labeled events are written to the corresponding output file. • global event information, e. g. run number and event time stamp, integrated beam charge, beam helicity state, event start time; • particle information, e.
g. momentum four-vector and vertex position, particle type and identification quality, and status words that encode information on the sub-detectors involved in the particle formation; • high-level detector response information associated with each particle, e. g. detector identifier, response position and time, and track trajectory in each detector layer. The DST banks are organized such that the large detector information banks can easily be dropped to leave only the data essential for a high-level physics analysis, without leaving unassociated references or unnecessary information. 3.
Computing resources Reconstruction of all CLAS12 data is performed on Jefferson Lab's batch computing system  [28]. It currently consists of about 400 computing nodes of various types, with a total of about 21,000 available jobs slots and half as many cores. The input raw data and analyzed output data are stored on JLab's tape silo  [29] , which provides sufficient cold storage for all of JLab's activities. Data for physics analysis are also stored live on JLab's Luster filesystems  [30] , which currently amounts about 2 PB of disk, but will be increased to almost 7 PB in the near future. Analysis of the reconstructed data is performed on the JLab batch and interactive farm nodes, and also exported to other institutions for final physics analysis. CLAS12 currently has 450 TB available on different file systems, and a fair share computing resource of 36M core-hr/yr.