dataesr/scientific-paragraphs-categorization huggingface dataset:
Particles Particle data (coordinates, orientations, and any additional features and metadata) can be loaded from common formats (. star,. tbl); coordinates are visualised as spheres, and orientations as basis vectors centered on the spheres (Fig  2 ). Both components can be disabled or tweaked (such as color-coded or resized, labeled, etc. ) for better visualisation. As with images, particles can be easily viewed in 3D. shows a plot of a Relion data column. An area of this plot is used to select a subset of the particles, which are then colored differently (in magenta) to highlight them. Since particles are actually simple napari Points layers, everything in the napari ecosystem that works with points will work with particles, such as manual or automated selection based on features, editing and coloring, classification, and so on.
Input/Output The reading, writing and conversion logic used by blik was developed as a standalone library, cryohub. This library has a modular design to allow reuse in other applications and simplify the contribution of new formats. Currently, it supports the following formats for images and segmentations: •. mrc (and the. mrcs,. st,. map variants) •. tif(f) • Dynamo. em • EMAN2. hdf and the following formats for particles: • Relion. star • Dynamo. tbl • CrYOLO. cbox and. box • EMAN2. json Where possible, blik makes use of lazy loading via dask  [24] , which allows working with data that is larger-than-memory and loading full datasets at once for ease of browsing.
This system plays very well with volumetric annotation, but has limits with thin labels such as filaments or surfaces. We plan to add different types of interpolation in order to widen the scope of application and usability of this tool. The morphosamplers code was implemented with two main goals: keeping the manual annotation procedure simple and robust, and generating ordered, regularly spaced poses that can be used both for particle picking for subtomogram averaging and to allow volume resampling (see Resampling). Picking particles as a regularly spaced lattice can significantly improve the results of subtomogram averaging when it reflects the underlying geometry of the sample  [13, 25].
Discussion With blik, we add to the cryo-ET software ecosystem an integratable and interactive data viewer, radicated in the python ecosystem, and a reusable and extensible set of libraries and tools for annotation and picking. There are several existing tools with similar goals and functionality to blik; in this section, we discuss the most popular ones, examine their compatibility with blik and compare their features with our tool. This should provide a starting point for the reader to choose the appropriate tool for their project. blik was tested primarily to work within the Relion&Warp pipeline  [7, 13, 16] , but was designed to be workflow-independent and thanks to cryohub easily extensible with new data formats. Following this workflow, other than the ubiquitous. mrc image format and Relion's.
star particle format, one of the first compatibilities to be developed was with image and particle data from the MATLAB software suite Dynamo  [17]  and its processing pipeline. Dynamo provides its own visualisation and picking tools, which were also the main inspiration for the geometry-based filament and surface particle generation in blik. While particle picking in blik has currently a smaller scope compared to Dynamo, its implementation in Python is intended to be more easily maintained and extended in the future by users, while leveraging the full-featured napari visualisation. IMOD  [15]  is arguably the giant in the field, with a long history of development and a wealth of features for image processing and annotation. With its extensive set of features and the constant development, it is usually the first choice when it comes to cryo-EM/ET processing, visualisation, and annotation.
Many of these features are very useful, and we plan to add support for them in blik or napari in the future. Integration between blik and IMOD is seamless for most common operations, such as working with data processed through IMOD's tomography pipeline etomo. IMOD's 3d viewer 3dmod is full featured and fast, and has several modes for 2D projection and slicing. It has however a more limited 3D renderer compared to napari (no volumetric projections, slicing planes in 3D view, or native particle pick viewer), which limits its applicability for the inherently 3D work of tomography. Being written in C, it is also non-trivial to extend for users with limited programming knowledge. ThermoFisher's Amira  [26]  is also a popular choice for image visualisation and annotation. It is particularly appreciated for its easy-to-use labeling tools to improve manual annotation and tracing, such as label interpolation, and image-guided picking.
Amira's label interpolation was the main inspiration behind napari-label-interpolator, and image-guided picking is in the future plans for blik development. Being an image-focused tool, Amira is more limited when it comes to particle coordinate generation although it has some model-based filament picking that can be repurposed for particle generation with the help of user scripts. However, Amira's closed-source proprietary nature is a big downside for open science practices, making it hard or impossible to extend, contribute to, and freely share within the scientific community. EMAN2  [10]  is a full software suite with an entire tomography pipeline from raw data to reconstruction. I/O compatibility between EMAN2 and blik is partially implemented, allowing to read particles and tomograms. EMAN2 has some tools for visualisation and picking, and is especially powerful for automated picking and segmentation thanks to machine learning tools.
Its 3D visualisation is similar to IMOD in features. Tomviz  [27]  is an open-source application focusing on tomogram reconstruction and visualisation, providing also a few segmentation and analysis tools. When it comes specifically to particle picking and visualisation, a powerful tool recently developed is ArtiaX  [28] , a ChimeraX  [19]  extension for cryo-ET. Thanks to ChimeraX's beautiful ray-tracing renderer, ArtiaX is ideal to make figures for November 23, 2023 11/16 publications. Particle visualisation is also very powerful and allows even to visualise subtomogram averaging results (map isosurfaces) distributed on the tomograms thanks to a performant implementation with instanced rendering. ChimeraX also provides a python API to control its visualisations, but doesn't offer the same level of two-way and direct access to the visualised data as napari with its ipython console.
Conclusion The work presented in this paper aims to reduce the friction of working with cryo-ET data, and to enable developers in the field to share, reuse and contribute as a community. The development of blik and its components is a stepping stone towards these goals. Working within napari allows us to delegate (and share with other fields) many non-cryo-ET-specific components, while retaining interactivity and extensibility; napari is in rapid development, and direct contributions to the community-developed project are always welcome. Even where direct contributions are unfeasible, developers can take advantage of the plugin ecosystem (such as blik does) or simple scripting. Now that blik's core features are established, we aim to reach out to other developers and cryo-ET software users and encourage re-using, adopting or contributing to the work here presented.
cryotypes and cryohub The data structures and input/output (IO) functions used by blik are extracted into two usage-agnostic libraries: no assumptions from blik are carried over, which makes these libraries suitable for adoption by any Python software working with cryo-EM and cryo-ET data. Both libraries live in the github community project teamtomo. November 23, 2023 12/16 • cryotypes: defines simple and extensible data structures for cryo-EM data types and metadata, and provides simple validation and checking functions to ensure a given object conforms to the specification. • cryohub: provides reading and writing functions for popular image formats and particle data, with both fine-grained controls and a higher level "magic" interface (cryohub. open(<anything>)). Data is read to and from cryotypes data structures, easily allowing for conversion between formats and integration in any third-party Python tool.
cryohub provides granular I/O functions such as read_star and read_mrc, which will all return objects following the cryotypes specification. from cryohub. reading import read_star poseset = read_star('/path/to/file. star') A higher-level function called read adds some magic to the IO procedure, guessing file formats and returning a list of cryotypes. from cryohub import read data = read( '/path/to/file. star', '/path/to/directory/', lazy=False, name_regex=r'tomo_\d+' ) See the help for each function for more info. Similarly to the read_* functions, cryohub provides a series of write_* functions, and a magic higher-level write function. from cryohub import write write([poseset1, poseset2], 'particles. tbl') morphosamplers Surface and filament picking and particle generation code are not specific to cryo-ET.
napari and vispy Where possible, napari-specific code was contributed upstream to the napari core repository (or vispy for rendering-related code). Much of this work was distributed and collaborative in nature; here are listed some highlights that were crucial for the proper development of blik and to which significant contributions were made as part of this work. • Improvements to quality, performance and interactivity of 3D rendering for volumes and labels, including work such as proper depth buffer and blending usage, arbitrary plane slicing and clipping, additional 2D and 3D interpolation modes. • Visualisation of points as spheres for more intuitive 3D visualisation. • Improvements to surface mesh visualisation (shading). • Projection of n-dimensional bounding box instead of simple point-slicing.
Acknowledgments This project received funding from  GRAL , the  Grenoble Grenoble Alliance for Integrated Structural and Cell Biology , a programme of the  Chemistry Biology Health Graduate School of Université Grenoble Alpes  ( ANR-17-EURE-0003 ), and from the  Agence Nationale de la Recherche  (grant  ANR DecRisp ANR-19-CE11-0017-01  to I. G. ). We are particularly grateful to  Alister Burt  for stimulating discussions, suggestions and initial guidance.
The sTED detector is designed to overcome all the previous problems that suffer the conventional n_TOF C 6 D 6 detectors. Thanks to a smaller active volume, the counting rate is considerably smaller, leading to a reduction of pile- Table  1. The detection efficiencies for C 6 D 6 detectors in percentage to the isotropic emission of γ-rays of 1 MeV and 5 MeV and the deexcitation γ-ray cascades of 197 Au and 240 Pu. The efficiencies were calculated with Geant4 simulations  [12]  with a detection threshold of 0. 15 MeV and the detectors were placed at 5 cm from the γ-ray sources. At the moment there are 9 sTED modules built, that can be used separately or in cluster mode, see Figure  3. Funding has been already found to buy 27 more sTED modules, thus the total number of sTED modules would be 36.
Characterization of the detector in 2021 In 2021 a dedicated campaign was performed to validate the sTED detector at EAR2. The first step of the work was to characterize the sTED response with various γ-ray sources ( 137 Cs, 88 Y and Am-Be) and Monte Carlo simulations performed with Geant4. The detector resolution and the signal amplitude to energy conversion were obtained by comparing the simulated response and the response obtained experimentally. In Fig. 5  the match between the the detector, the yield for an 197 Au sample of 2 cm diameter and 0. 1 mm thickness is compared with the yield obtained with the evaluated data of JEFF-3. 3  [13]. The experimental yield is calculated by dividing the counting rate in the sTED detector as a function of the neutron energy by the neutron fluence of the EAR2, after subtracting the different background components affecting the measurement.
Introduction The Precision Proton Spectrometer (PPS) detector system has been installed and integrated into the CMS experiment  [1]  during Run 2 of the LHC with 13 TeV proton-proton collisions. It is a joint project of the CMS and TOTEM  [2]  Collaborations and measures protons scattered at very small angles at high instantaneous luminosity  [3]. The scattered protons that remain inside the beam pipe, displaced from the central beam orbit, can be measured by detectors placed inside movable beam pipe insertions, called Roman pots (RP), which approach the beam within a few mm. The PPS detectors have collected data corresponding to an integrated luminosity of 107. 7 fb -1 during the LHC Run 2, which occurred between 2016 and 2018. The physics motivation behind PPS is the study of central exclusive production (CEP), i.
Forward calorimeters extend the pseudorapidity coverage provided by the barrel and endcap detectors. Muons are measured in gas-ionization detectors embedded in the steel flux-return yoke outside the solenoid. Events of interest are selected using a two-tiered trigger system. The first level (L1), composed of custom hardware processors, uses information from the calorimeters and muon detectors to select events at a rate of around 100 kHz within a fixed latency of about 4 𝜇s  [9]. The second level, known as the high-level trigger (HLT), consists of a farm of processors running a version of the full event reconstruction software optimized for fast processing, and reduces the event rate to around 1 kHz before data storage  [10]. A more detailed description of the CMS detector, together with a definition of the coordinate system used and the relevant kinematic variables, is reported in ref.
LHC optics and proton transport PPS is a proton spectrometer that uses the LHC accelerator magnets between the interaction point (IP) and the RPs. Scattered protons are detected in the RPs after having traversed a segment of the LHC lattice containing 29 main and corrector magnets  [14]. Since the protons that reach the PPS detectors travel more than 200 m inside the vacuum pipe of the LHC and very close to the LHC beams, we use the technique normally employed to model beams inside an accelerator. The trajectory of the protons in the vicinity of the central orbit  [15, 16]  can be described as follows. The proton kinematics d at a distance 𝑙 from the IP (e. g. at the RPs) is related to the proton kinematics at the IP, d * , via the transport equation: d(𝑙) = 𝑇 (𝑙, 𝜉) • d *. (3. 1) Superscript * in general is used in the following to denote the value of the given parameter at the interaction point, 𝑧 = 0.
5 𝜎 beam horizontally and at 5 𝜎 beam vertically. At these distances, the horizontal and vertical detectors overlap, as shown in figure  3 , which allows the relative alignment of the RPs in each arm. With the use of the vertical RPs, it is possible to detect elastically scattered protons that are used for horizontal RP alignment with respect to the beam. The alignment procedure is detailed in section 5. In the alignment fills the very small separation of the horizontal RPs from the beam allows the recording of additional data essential for optics calibration (cf. section 6). Typically there are two alignment fills per year of LHC operation. In Run 2, PPS was operated from 2016 to 2018. The PPS data sets are divided in data-taking periods. The PPS performance is often sensitive to the LHC settings (optics, collimators, etc.
(3. 5), namely the horizontal, 𝐿 𝑥 (𝜉), and vertical, 𝐿 𝑦 (𝜉), effective lengths, and the corresponding magnification functions; other optical functions are less relevant for the proton reconstruction. The above optics calibration steps rely on the nominal transport model, which is taken from LHC databases. The transport matrix is defined by the machine settings M, which are obtained -15 -  from several data sources. The proper version of the LHC magnet lattice description, known as "sequence", is used each year. The nominal magnet strength file for a given beam optics is always updated using measured data: the currents of the magnets power converters 𝐼 P𝐶 are first retrieved using TIMBER  [30] , an application to extract data from heterogeneous databases containing information about the whole LHC infrastructure.
Optics matching The purpose of the optics fitting (or "matching") is the calibration of the LHC optics model using the measured dispersion values and other measured constraints. The calibration procedure consists of a 𝜒 2 minimization with MINUIT, where the initial optics model of the fit is taken from the LHC databases, as mentioned in section 6. 2  [35]. The first step is to constrain the quadrupole field model using the elastic candidates from the alignment fills, described in ref. [17]. In the second step the measured dispersion values from table 5 are used as inputs to the 𝜒 2 function, with additional constraints reflecting the LHC optics uncertainties: 𝜒 2 = 𝜒 2 design + 𝜒 2 measured. (6. 10) The following measurements from both LHC beams contribute to 𝜒 2 measured : • the readings of three beam position monitors (BPMs) (at 𝑙 = 22 m, 58 m, 199 m), with an uncertainty 𝜎 𝑥,absolute ≈ 0.
The general expression in eq. (  7. 2) can be decomposed into a set of simpler equations for the conditions relevant to PPS. The minimum of 𝜒 2 from eq. (7. 2) is described by eqs. (6. 13) and (6. 14) when the following conditions are met: (i) if two tracking RPs are used per arm (Run 2 configuration); (ii) if the proton transport can be approximated by the terms explicitly mentioned in eq. (6. 6) (a good approximation for 2017 and 2018); (iii) only 𝑥 * is assumed to be zero (the case with ndf = 0). Each of these equations gives an explicit expression to determine one of the proton kinematic variables. Only the first equation is nonlinear (𝜉 on both sides of the equation), whereas the others are linear (𝜉 is taken from the solution to the first equation). Beyond the usefulness for optics studies as discussed in section 6, this decomposition can speed up the reconstruction software implementation: there is a single nonlinear equation with a single variable that can be solved in different well established ways, e.
section 12; • geometrical acceptance: check if the simulated protons pass through the sensitive area of each sensor; • digitisation: a software "hit" object is created at the nearest strip/pixel -an effective pitch is used to reproduce the spatial RP resolution extracted from data; • for timing sensors, simulation of proton arrival time (with timing resolution extracted from data, cf. section 13). The hit objects created in the simulation are then processed with the standard PPS reconstruction software. The simulation can take into account realistic distributions of parameters of importance: 𝛽 * , crossing angle, optics, RP positions, apertures, resolution and efficiencies. The values of the crossing angle and 𝛽 * are randomly sampled from the 2D histograms extracted from the data, -34 - cf.
The spatial resolutions obtained from the fits (Figure  52 ) for the two categories are 1. 87 ± 0. 21 (1. 87 -1. 93) cm and 2. 77 ± 0. 17. Vertex resolution obtained from the difference of proton arrival times, using data collected during low-pileup runs. Left: resolution for two-arm multi-RP events, using the subset of events with a predicted resolution <100 ps for both arms. Right: resolution for two-arm events using all events with exactly one multi-RP proton in each arm. The fitted signal (red dashed line) and background (blue dashed line) are shown separately, with the means and widths of both components treated as free parameters. The bars on the data points indicate the statistical uncertainties. Table  8. Vertex position resolutions obtained from the proton times measured in the PPS timing detectors, using different selection criteria and background shape assumptions.
JINST 18 P09009 14 Summary The procedures developed to reconstruct the proton tracks from the signals detected in the CMS-TOTEM Precision Proton Spectrometer have been described. The performance of the reconstruction is studied with data from the LHC Run 2 of proton-proton collisions at 13 TeV energy, corresponding to an integrated luminosity of 107. 7 fb -1. A multi-step alignment of the detectors is performed. Alignment with respect to the LHC collimators is followed by relative alignment of the sensor planes within a Roman Pot (RP) and among all RPs. Then, global alignment is performed with respect to the LHC beam with elastic events collected in low luminosity runs, and is extrapolated to the RP's positions in the high luminosity fills. Finally, the timing detectors are aligned with respect to the tracking detectors.
The alignment uncertainties are 150 𝜇m and 100 𝜇m in the horizontal and vertical projections, respectively. The precision of the relative alignment between near and far RPs is better than 10 𝜇m. A precise modelling of the LHC optics is a necessary precondition for the reconstruction. The track horizontal and vertical positions at the RPs can be obtained from the proton kinematics at the interaction point via the optical functions. The horizontal dispersion, 𝐷 𝑥 , is calibrated using the 𝐿 𝑦 = 0 constraint from the data and a sample of (semi)exclusive dimuon events. The horizontal dispersion carries information on the dependence of the optics model on the horizontal crossing angle. The parameters of the optics model (half crossing angle, quadrupole positions and magnet strengths) are determined from a fit to the beam position obtained from the beam position monitors and RPs, and the measured horizontal dispersion.
The data are well described by the simulation. As expected, the multi-RP reconstruction shows a better resolution than the single-RP method. The proton reconstruction efficiency has been measured for the different data taking periods. It depends on different multiplicative factors describing the sensor efficiency, the reconstruction -54 -algorithm efficiency, and the effect of interactions along the proton path. The silicon pixel detector efficiency is caused by the radiation damage. The silicon strip detector efficiency loss is caused by radiation damage and in addition by multiple tracks in the same event. The effect of radiation damage is studied as a function of the integrated luminosity and is significant in the region closest to the detector edge facing the beam. The efficiency of the multi-RP reconstruction is smaller than that for the single-RP reconstruction, because of the sensor efficiency of the extra RP, and the effect of multiple, ambiguous proton combinations between tracks from the near and far detectors.