dataesr/scientific-paragraphs-categorization huggingface dataset:
Database curation Erroneously annotated sequences in the reference database can have serious consequences on taxonomic assignations. Ideally, a reference database should be curated to identify incorrectly assigned sequences. Unfortunately, b oth NCBI and BOLD databases contain mislabeled sequences. Published metho ds aiming to curate databases are not applicable to large database s, since either the run time would be prohibitive or include a manual step for the curation  (Collins et al. , 2021; Kozlov, Zhang, Yi lmaz, Glöckner, & Stamatakis, 2016; Rulik et al. , 2 017). The COInr database is too large to be able to run a curation step, which should be kept in mind when using the full database. However, if a small custom database is created from COInr, this curati on step becomes feasible and strongly reco mmended.
Conclusions The COInr database can be used for taxonomic assignations of COI sequences as it is, since it is not limited in its taxo nomic scope, or to a particular region o n the gene. It is also a good starting point to create local, custom databases, since it saves the most time -intensive and complicated steps of database creation: (i) downloading a large number of sequences (ii) creation of a cohere nt taxID system to avoid ambiguity du e to homonymy and synonymy (iii) and sequence dereplication. The mkCOInr package provides the necessary tools to both to re-create a whole COInr database, between the planned annual updates, and produce custom database starting from COInr. The possibility of refining the taxonomic composition of the database , selectio n of the gene region and formatting the output to widely used database formats (blast, rdp, qiime) are filling the need for an easy way of creating customized COI database s.
The NNBAR detector is simulated with GEANT4  [25] , a standard simulation package used for detector simulations. To make it possible for all these programs to exchange the data produced by each simulation the MCPL  [26]  package is used, which is a binary format storing information on the state of a particle (momentum and position) and allows for interchanging of trajectories, particles, or entire events over different Monte Carlo-based simulation programs. Figure  6  gives an overview of the simulation chain that has been used to construct the full model of the NNBAR experiment. It comprises a number of components, each representing distinct aspects of the experiment and effectively follows the neutron -7 -as it is focused and propagates towards the annihilation detector. The simulation of the neutron source must first be done.
Simulations A scheme of the shield as used for simulation is shown in figure  17. The simulations are based on finite element calculations using the commercial software COMSOL [27]. For the optimization of the parameters, the shield has been placed inside a static background field normal to the shield axis, different static fields from magnets from the ESS instruments LOKI, ESTIA, SKADI, DREAM, HEIMDAL, and T-REX  [17]  have also been considered, as well as exemplary tests of steel rebar of magnetic concrete and structures. A large external coil is placed surrounding the shield, generating a magnetic field perpendicular to the shield axis. The coil is placed closer to one open end of the shield than on the opposite side to also illustrate the effect of fields entering the shield longitudinally.
Trigger The main goal of the NNBAR detector trigger system is the ability to identify and read out neutron-antineutron annihilation candidate events. To minimize overlaid detector hits from unrelated background events the trigger must be able to resolve accepted events in a short time window. To this end, the NNBAR experiment will employ a two-level trigger system. The first level will be hardware based and work in self-trigger mode of individual calorimeter cells and cosmic veto sensors. The required readout bandwidth for the subdetectors is expected to be relatively modest since only self-triggered calorimeter and veto channels will be read-out. This may allow the use of a commercial network switch for connecting the front-end readout with the off-detector processor farm, with PMT samples and timestamp data encoded in compatible network packet formats.
Some studies have analysed the various parameters that influence the surgeon's posture with the aim of proposing solutions to reduce pain and improve the overall surgical ergonomic  [16, 17, 19]. These methods are based on data collected using EMGs and/or Inertial Measurement Units (IMU) directly attached to the surgeon's body. The camera-based method described by Berguer et al. [19]  uses reflective markers visible thanks to incandescent bulbs to capture the surgeon's posture. However, these devices may hinder the surgeon's movements, creating a possible bias, and are time-consuming to attach. Overall, the data obtained with these different devices are similar: movement frequency, angle calculation between body joints, and muscles activity. Human pose estimation (HPE) algorithms have been developed and improved since the 80's and have been used to detect and monitor surgeons' posture detection  [20] [21] [22].
"Bottom-up" approaches move from joints to people  [27] [28] [29] [30] [31]. The most popular deep learning HPE tool is OpenPose because it allows multi-person pose detection, is the most documented method, and is an open-source algorithm  [31, 32]. It can also be used for real-time posture detection  [27, 28]. This "top-down" algorithm was trained to recognize different body joint dataset which is useful for adapting joint detection in function of the available images or videos  [28, [31] [32] [33]. The purpose of the present work was to observe different postural behaviours and to correlate their frequency with surgical expertise. These postural behaviours include those arising from discomfort hesitation, and those due to the surgical tool inference with the desired movement (i. e. "interfering movement").
Recording was done using a Python script (version 3. 7) on a dedicated laptop (16GB RAM, Intel core i7). Each recorded video was anonymized using a standard procedure to enable blind analysis. Tab. A simplified version of OpenPose  [33]  was used to detect the participants' joints in the videos of their training session. This algorithm could be adapted using the detection confidence threshold as parameter to return the orthonormal coordinates of each joint 1. The detection confidence threshold was automatically optimised to detect a precise list of body joints. Indeed, the simulator module hides the participants' lower body part (Fig. 1 ) that therefore cannot be detected by the algorithm in the input RGB images. Fig. 1  Camera view of a surgeon using the KNEE module. The lower limbs and head are not visible or hidden 1 https://github.
The voter's user experience For a voter, the voting process runs as follows (see also Figure  5 ). First of all, their identity and eligibility are verified at the registration desk. This is outside the scope of the protocol, and can for example be accomplished using traditional voter rosters. The voter then picks a smart cart from a pool of cards, one preprinted ballot for each candidate, and one envelope with a window in a specific place (see Figure  1  for the ballot design). These ballots have a special design: the name of the candidate is printed on both sides, while there is a QR-code containing some machinereadable data in the middle, and further numbers and barcodes next to it. Moreover, everything except for the name of the candidate is hidden under an opaque covering that can be scratched away.
The voter then enters the voting booth, which is equipped with a voting terminal with a card reader and an optical reader for QRcodes and barcodes. The voter scratches the covering from the ballot of the candidate they choose, and inserts the smart card into the reader. They then scan the QR-codes and barcodes, and the terminal shows a copy of the ballot, including in particular the name of the candidate the voter selected. They confirm their selection, and insert the ballot into the envelope. When the terminal confirms that their electronic ballot has been successfully created and inserted into the database, they can remove the smart card from the terminal. The smart card now shows an identifier of their electronic ballot and a short identifier of the paper ballot on its screen. Before leaving the voting booth, the voter destroys the unused ballots to prevent deducing who they voted for, by elimination.
Desired security properties and threat model The protocol strives to achieve the following security guarantees: • End-to-End Verifiability: If all checks by the voters and the auditors succeed, and the paper ballots used to vote are well-formed, then voters are assured that ballots containing their intended votes are contained in the database, without having to trust the authorities or the system (often called "individual verifiability"). The correctness of the tallying (often called "universal verifiability") ensures that the final result corresponds to the encrypted electronic ballots. As the tallying is out of scope of this paper, the exact solution will depend on the tallying method chosen, but can be cryptographically guaranteed by the zero-knowledge proofs. End-to-End Verifiability typically also covers "eligibility verifiability", i.
The attacker can thus modify them for all the communications on public channels. • Cryptographic verifications are gathered in function macros. In our example, CheckQRCodesData is a function macro that contains two verifications of cryptographic signatures and a verification of an arithmetic property. As presented in Section 3. 1, cryptographic signatures (and zero-knowledge proofs, for instance) are idealized (as usual) by rewriting rules. However, for the arithmetic property, the situation is more complicated, and we refer to the next section for this. • The role of Observers, described in Section 2. 2. 5 is not modeled in a classical way with a process. We used the restrictions capabilities of ProVerif to directly write consistency properties that are guaranteed by the presence of Observers.
• No-ballot-stuffing: recorded ballots correspond to legitimate voters, and there is at most one electronic ballot per voter. Main difficulties. In order to achieve verifiability, the Themis protocol relies on two peculiarities that make the analyses more complex: probabilistic audits and arithmetic operations. First, unlike the Benaloh audit mechanism  [4] , the Themis protocol enforces that the voter makes an audit before confirming their vote, by auditing one of the two ciphertexts. Attacks against verifiability (mainly recorded-as-intended) will thus be detected with probability 1/2. Unfortunately, ProVerif is not suitable to conduct probabilistic analyses. We thus decided to model the fact that each verification code is audited with the same probability by the voter using a process in which both codes are audited.
g. , predicting, classification, taking actions) will depend on how close was the training data to the actual data used in production environments. The AI-enhanced MANO system for V2X services that we present in this paper, and illustrate in Fig. 1 , consists of two layers, i. e. , cloud and edge. The system enables autonomous MANO operations in each of the domains, but enforces an interplay between them for offloading orchestration decisions, or for retrieving data from distributed data engineering pipelines available in all edge domains. Such a system orchestrates both services and applications developed for various use cases, but also Network Intelligent Functions (NIFs) that are represented by adopted and integrated AI/ML models. Despite the emerging popularity of bringing intelligence to network management and orchestration functions in 5G and beyond, most of the works on validating the impact of AI/ML on MANO are based on simulations.
Two MANO layers communicate with each other in the two following ways: i) via Edge-Cloud reference point, which is used to either offload decision-making tasks between two orchestrators or to pass the already taken decision, and ii) via message brokers, which exchange data in a controlled way depending on the type of AI/ML technique that has been applied in the system, thereby using that data to either perform training or model adjustments and online learning. Thus, depending on the time-scales of optimization (global or local, i. e. , edge-specific), it is required that MEC hosts can connect data to AI/ML models in a transparent and efficient way (e. g. , using Zenoh framework introduced in Section III). In case of federated learning, which is suitable for distributing intelligence across edge nodes, thus deploying AI/ML agents in edge nodes, we consider that each edge orchestrator trains the local model based on the data collected from its own domain.
On the other hand, if security in data sharing between two message brokers laying in two orchestration layers can be preserved, multi-agent reinforcement learning may use data collected from other edge domains to optimize policies. Some examples of V2X services that might benefit from such AI-enhanced NFV MANO system are: • infotainment services, such as vCDN, where cloud orchestrator optimizes distributed vCDN deployment across edge domains, based on the locations of vehicle (e. g. , retrieved from the location service) and computational resource utilization in each of the edges (e. g. , collected from message brokers in edges)  [8, 9] ; • emergency services, such as lane clearance for emergency vehicles, where edge orchestrators optimize service oper- ation on the edge level, while cloud orchestrator makes sure that service is deployed in all edge domains that are on the route affected by emergency situation  [8, 10] ; • maneuver recommendation services, which are services that provide vehicles with recommendations about in which lane to drive, when to merge or exit the lane, etc.
e. , edge-cloud interaction, and ii) receive dynamic triggers from AI/ML models deployed in NIFs for optimizing MANO operations. Such K8s master with extended and enhanced operation deploys services and applications on designated worker nodes. In the PoC, both master and worker nodes can be deployed on the bare metal, as well as in Linux containers (LXC), which is a more suitable practice for shared experimentation environments as testbeds. For each type of data that is collected, i. e. , computational and network resource utilization, energy consumption, KPIs measured at users' side, and users' locations, we also deploy MEC value-added services, as per definition in ETSI MEC  [12] , which perform data retrieval and pre-processing before publishing them on Zenoh  [13]. Given its minimal network overhead (as little as 5B), and its small footprint (around 60kB on Arduino board), Zenoh is adopted in our PoC as a framework for data engineering pipeline.
Cloud orchestrator is running on the bare metal on top of the Virtual Wall testbed, located in Ghent, Belgium (Fig. 2 ). It is deployed as a web server (using Flask framework in python), which is capable of i) processing decision-offloading requests coming from the edge orchestrators, ii) location data processing and publishing on Zenoh, iii) injecting decisions on the north-bound interface of edge orchestrators to instruct them to proactively migrate/relocate services from one edge to another, and iv) receiving notifications from NIFs deployed on the cloud, which enhance their operations and help them make efficient decisions on managing underlying resources and edge orchestrators. In Fig. 3  we show the result of average response time, and CPU utilization, of the vCDN server deployed on the MEC host in our PoC.
2003; Browne et al. 2003)  and the SDSS Quasar Lens Search (SQLS,  Oguri et al. 2006). In contrast, lens-selected searches look for signs of a lensed high-redshift source in imaging or spectroscopy in known samples of massive galaxies. Some of the most well-studied Fig. 1. Illustration of the planned and current CFIS footprint. The contours of the final CFIS-r footprint is shown in red and CFIS-u footprint is shown in blue. The current areas covered in the r-band for DR2 are shown as colored areas in red, while the blue area corresponds to the u-band coverage. In violet is shown the area where both r-band and u-band data are available simultaneously. In this work, the u-band is used when available, for visual inspection purpose only. We also indicate the position of the 32 best quality candidates (marked with stars) and the 101 maybe lenses (crosses) obtained after the joint visual inspection of the CNN-committee candidates.
Data The Canada France Imaging Survey (CFIS) is an ongoing legacy survey using the Canada-France-Hawaii Telescope (CFHT), a 3. 6 m telescope at the summit of Mauna Kea in Hawaii. CFIS is a component of the multi-band Ultraviolet Near Infrared Optical Northern Survey (UNIONS). This effort will the provide the necessary ground-based optical counter parts of the forthcoming Euclid space mission, along with stand-alone immediate scientific applications  (Ibata et al. 2017; Fantin et al. 2019, Guinot et al in prep). When completed, the survey will have imaged 8 000 deg 2 of the northern sky in the u band (CFIS-u) and 4 800 deg 2 in the r band (CFIS-r). The imaging data used in this work are from the CFIS Data Release 2 (DR2; see Fig. 1 ), covering around 2 500 deg 2. CFIS-r has exquisite image quality with a median seeing of 0.
6 , down to a depth of 24. 1 (point source, 10σ rms). CFIS-u has a median seeing of 0. 8 to a depth of 23. 6 (point source, 10σ rms). Here, we use the CFIS-r footprint to search for lenses with CNNs based purely on high resolution morphological information. Since not all r-rand images have u-band counter parts, the CNNs use only r-band information. However, CFIS-u is used, when available, to refine the sample of candidates found through the CNNs by visual inspection. For each target, we have also produced models of the point spread function (PSF) and its spatial variations across co-added images which have been reduced, processed and calibrated at the Canadian Astronomical Data Centre using an improved version of the MegaPipe pipeline  (Gwyn 2008). For each lens candidate, we exploited the model PSF obtained with PSFEx  (Bertin 2011)  to produce an image of the local PSF oversampled by a factor of 2.
Data selection for the lens search A reliable color-selection of LRGs is not possible with CFIS data alone. Even with color information, one needs to account for the fact that LRGs acting as lenses have colors biased towards the blue with respect to non-lens LRGs: lensing LRG are blended with the lensed image of an often blue, background galaxy. Fortunately, the CFIS footprint is entirely included in the first part of Pan-STARRS1 (PS1), hence we use PS1 to carry out our color selection, accounting for the blue bias. This has already been implemented by  Cañameras et al. (2020)  and consists of a color cut in the PS1 3π catalog, broadly matching the aperture magnitudes and colors of 90 000 Pan-STARRS simulations of lensing systems. This photometric selection is very large, since it was designed to include 96% of the mock lens and thus hopefully all LRG lens galaxies.
Data selection for the simulated training set Our simulation set is constructed from real data, i. e. a deflector from CFIS imaging data and a background source from HST images, as described in Sect. 3. 2. The image stamp size in this work is 8. 17 on-a-side corresponding to 44 pixels. The selection of deflectors is taken directly from  Cañameras et al. (2020). This correspond to a subsample the LRG spectroscopic sample  (Eisenstein et al. 2001) , which uses colormagnitude cuts to select intrasically red and luminous galaxies. They have SDSS spectra, and thus also velocity dispersion (σ ) and redshift (z) estimates. In Fig. 2  we summarize the spectral properties of our selection which spans the ranges 200 < σ < 500 km s -1 and 0. 1 < z < 0. 7. After a cross-match with the whole CFIS-r catalog from DR2, we obtain 624 170 LRG images, which form the basis of our training set.
2012). As a final step, the CFIS PSF is resampled to the HST pixel size and the image of the lensed source is convolved with this resampled PSF. The result of the convolution is then downsampled back to the pixel size of CFIS and added to the deflector image. Our simulations are therefore a hybrid between simulations and real data, i. e. built from the CFIS data themselves for the lens and from deep HST images for the source. For some of the simulations produced with this method, the lensing features are too faint or heavily blended with the deflector light. Including images with indistinguishable lensing features may increase the false positive rate. Therefore, we use only the simulations for which the sum of the brightness of all pixels of the lensed source is at least 20 times the mean rms value of the sky noise measured in the four corners of the deflector image.
The batches contain 128 images picked from the data-set and flipped randomly along the x-and y-axis using the Data Augmentation method from Keras. Overfitting is one common pitfall encountered during the training of machine-learning algorithms. It occurs when the algorithm learns the specifics of the training data and thus is not able to generalize on new data. When overfitting occurs, the classification error on the training data becomes very small, while the error on previously unseen data starts to grow. Since the batches contain each time different images, the data augmentation procedure allows us to artificially increase the size of the training set and limit the risk of overfitting. Since our network was previously trained on ImageNet data, we only need to finetune the parameters. Therefore we started directly with a relatively low learning rate of 10 -4.
The maximal number of epochs, i. e. the number of times the machine-learning algorithm is allowed to see the entire training dataset, is fixed at 200. However, in order to optimize the training time, we use the early stopping procedure from the Keras API, which interrupts the training before reaching the maximal number of epochs if the validation loss is no longer improving. epoch achieving the smallest validation loss. The three members of the committee are combined such that the final output corresponds to the mean of all the outputs assigned by the three independent networks.
In other words, this first step rejects any object that can be immediately demoted to a non-lens and keeps the rest. We then consider the union of all objects selected by at least one of the six visual inspectors (4 626 images). For all images selected during the mosaic inspection, we further proceed with a more detailed inspection using our single-object tool. This tool displays one single stamp at a time but offers a dynamic contrast control, more classification options, and a direct link to the Legacy Survey cutouts (LS;  Dey et al. 2019 ), when available. The LS data are shallower than the CFIS data but have color information. Note that the LS color images are not displayed systematically during the classification process to avoid the users' decisions being driven by the color information.
They are rather used to support the r-band CFIS classification when a candidate requires further data to make a decision. In this step we classify the images into four categories "Secure lens" (SL); "Maybe lens" (ML); "Flexion" (FL); and "Non-lens" (NL). Our single-object classification follows the same guidelines as in  Rojas et al. (2021, in prep. ) , where the SL category includes images displaying obvious signatures of strong-lensing features, such as multiple images or arcs with counter images. The second category, ML, corresponds to images that exhibit structures compatible with lensing, but that would require further investigation with lens models or follow-up with higher resolution data, higher signal-to-noise data, or with spectroscopy. When single arcs with small distortions and no counter-images are seen, we use the category FL which stands for "Flexion".