dataesr/scientific-paragraphs-categorization huggingface dataset:
Luminosity Block During the review of the ATLAS metadata handling software components, it was determined that the current implementation of the Luminosity Block metadata handling mechanism can be considered AthenaMT-compatible. Both the Algorithm and the AlgTool use internal caches for counting events within luminosity blocks. Each Athena job can have at most one instance of either the Algorithm or the AlgTool. None of them offer any public API for accessing their private cache either. Hence, at this point no immediate changes are required in the code of these two components. For the future, though, we can implement some optimizations (e. g. turning the Algorithm into an ReentrantAlgorithm), and also work on making these two components thread-safe.
Trigger menu Trigger development focused on migrating from a limited in-file metadata specific trigger menu format to a general JSON format. This unifies access to the trigger configuration in both online and offline environments. Additional modifications regarding per-slot configurations backed by the in-memory cache were added for MT-safety. From 2020, the data summarizing the configuration of the trigger and AthenaMT processes running the High Level Trigger (HLT) are stored in a series of configuration files in JSON format  [11]. Each run is configured from a Super Master Key (SMK) which is tied to a specific software release. The SMK references three configuration files: one for the trigger menu , one for the HLT menu, and one which fully configures the HLT AthenaMT processes. In addition the trigger prescale, HLT prescale, and bunch-group configuration are stored in JSON formatted files.
This second set have their own unique integer keys because they may change during a run. All these files are stored in an online database in serialized form and referenced by an integer key. When processing bytestream data the configuration files, except the one configuring the AthenaMT process of the HLT, are downloaded from the database during the first step of offline processing. The JSON content of the downloaded files is stored as infile metadata in the output files. The in-file metadata objects are five ROOT stream-able xAOD::TriggerMenuJsonAuxContainer collections: one for each of the trigger menu, HLT menu, trigger prescale, HLT prescale, and bunchgroup information. Each collection contains information from the set of JSON files required to cover the configuration of every event in the file.
The payload of each container is stored as a JSON formatted string. ROOT compression is used to reduce the size of the container on disk. When a reconstructed file is subsequently opened, the contained payloads are added to an in-memory cache of available configurations. The string objects are decoded into boost::ptree data structures. The trigger configuration service's in-memory cache is updated on the BeginInputFile incident after having obtained an exclusive lock over the mutable cache. Upon the BeginEvent incident, a shared lock over the immutable cache is used to verify that the configuration loaded into the event's processing slot is correct or to update it from the service's cache if not. This check is performed by reading the new event's SMK, trigger prescale key, HLT prescale key, and bunchgroup key from the per-event data collection.
File information Recall from Section 2. 7 that the file information only has the first instance of any encountered piece of information. That means the FileMetaData objects cannot be merged. The previous implementation handled this by adopting the first values encountered and warning the user about differences. The thread safe implementation adopts the same practice: using the first object provided and warning about differences when a new input file is opened. Aside from assuring thread safety the new implementation for the file information management follows the same workflow as the event stream information.
Conclusion This paper provides and overview of the ATLAS in-file metadata contents and the software infrastructure supporting this descriptive information. In 2020 the in-file metadata system of the Athena framework was redesigned to support concurrent event processing in multithreaded simulation and reconstruction workflows. We demonstrated how the code migration challenges presented by each category of the ATLAS in-file metadata were met with pragmatic solutions. The new system can now provide in-file metadata clients with the appropriate descriptive information in multi-threaded concurrent event processing. The migration to the multi-threaded framework is a necessary first step for the ATLAS experiment to be able to take advantage of heterogeneous hardware architectures, such as graphical processing units.
If this material is ductile enough (i. e. if grain breakage is disregarded), such a situation should lead to large deformations of the grains (Fig. 1 ), which is prevented in the strict framework of DEM. Several numerical approaches have been proposed to deal with highly deformable grains  [9] [10] [11] [12] , and all of them rely on some sort of discretization of the grains. This is notably the case of the Multibody Meshfree Approach  [13, 14] , which was implemented in the open source code MELODY  [15]. In this framework, a large number of field nodes are positioned in each grain and on its contour. Each field node carries two degrees of freedom in displacement, and the displacement field is interpolated between the nodes using meshfree shape functions. This choice was made to improve the robustness of the code when grains are submitted to very large deformations.
With these assumptions, the normal strain n in the deformed area is related to the ratio between the initial dimensions of the deformed area (in the direction normal to the contact) to its current dimensions. Considering the point of maximum interpenetration (Fig. 6 ), we can write: Considering linear elasticity and integrating the normal stress on the whole contact length, we finally get a repulsive normal force equal to: With a secant normal stiffness k n given by: where a and b are two constants. It is interesting to notice that this expression is independent on the grain radius. To determine a and b , numerical simulations of the isotropic compression of a deformable grain between four walls are performed with the code MELODY  [15]. The grain has a diameter equal to 1 and a unit Young modulus, and several values of the Poisson Coefficient (ranging between 0 and 0.
5. Simulations of isotropic compactions are thus performed on the same samples and in the same conditions with the code MELODY, using the Multibody Meshfree Approach. Qualitative results are provided in Fig. 9  for both samples, in the case = 0. 3. Four loading stages (provided in Fig. 10 ) are considered. Zoomed views on the same area of the sample are provided, and the grains are represented with a color scale corresponding to the local value of the mean (69) n =-E ⋅ b 2 ⋅ Z 0 + k -0 a ⋅ ln max - max -0 stress 1 + 2 ∕2. The agreement between both numerical approaches is acceptable, both in terms of mean stress values (although this quantity is constant in each grain for SDEM while it is allowed to vary spatially in MELODY thanks to a much finer discretization) and in grains motions and deformations.
) and more complex contact models (friction, cohesion, capillary adhesion, etc. ). Kinematics could be either enriched or degraded: if we call the present approach the D2F3-SDEM (2 dimensions, 3 DoF in deformation), standard DEM might then be called D2F0-SDEM. Other versions such as D2F1-SDEM (volumetric deformation only) or D3F6-SDEM could be imagined. A 3D extension seems indeed possible, since the computation of stress and strains tensors will be straightforward. It will however require specific algorithms for rapid computation of large interpenetrations between ellipsoids, and a calibration of contact laws with an accurate 3D code including contacts, in the manner of Fig. 7. A natural and simple extension would also consist in considering ellipses instead of discs, i. e. to modify the elastic state of reference for each body.
In our study, using NMR with UHPLC-MS, blood/methanol (1:8) precipitation gives the In order to select the most relevant preparation procedure for urine sample optimization, we looked at the metabolomics data processing level using the Network Explorer module in MetaboAnalyst 4. 0 and found additional important biological information. Metabolic pathways were then bioinformatically predicted for each set of metabolites (see Supplementary Data Table  S3 ). Results indicated that the urine/MeOH (1:8) preparation had the most exhaustive metabolic coverage with 12 metabolic pathways described. In term of the total number of metabolites extracted, reproducibility, and metabolic pathway description, the urine/MeOH (1:8) preparation with 201 chemicals extracted (CV < 30%) including 22 unique compounds had the largest coverage of the metabolite sets.
Degree four provides metabolites shared exclusively by the four sets (sample type). In all the four matrices, 37 identical metabolites were detected. These 37 common com-pounds reflect the overlapping matrices and can be very informative for metabolic and physiopathological flux analysis at the organism level and to evaluate the biological compartment exchanges. These observations need to be confirmed in future studies by applying this methodology to a unique individual (we worked here with pooled samples). While matrices complementarity and metabolic coverage was assessed earlier, metabolic mapping needs to be ascertained. iPath3. 0 provides data mapping capabilities. Based on the metabolites recovered from urine, blood, saliva, and feces, we established a global metabolic card to metabolically illustrate an individual (Figure  4 ).
Degree four provides metabolites shared exclusively by the four sets (sample type). In all the four matrices, 37 identical metabolites were detected. These 37 common compounds reflect the overlapping matrices and can be very informative for metabolic and physiopathological flux analysis at the organism level and to evaluate the biological compartment exchanges. These observations need to be confirmed in future studies by applying this methodology to a unique individual (we worked here with pooled samples). While matrices complementarity and metabolic coverage was assessed earlier, metabolic mapping needs to be ascertained. iPath3. 0 provides data mapping capabilities. Based on the metabolites recovered from urine, blood, saliva, and feces, we established a global metabolic card to metabolically illustrate an individual (Figure  4 ).
NMR 1 H-NMR spectra were acquired at 298K on an AVANCE III HD 600 MHz system (Bruker Biospin, Karlsruhe, Germany) equipped with a Bruker 5 mm TCI CryoProbe with Z-gradient. 1 H-NMR spectra were recorded with the «noesypr1d» pulse sequence with a relaxation delay of 20 s, on a sweep width of 12 ppm, 64 k data points, an acquisition time of 4. 55 s, with 64 transients, and 8 dummy scans. 3. 3. Data Processing 3. 3. 1. UHPLC-MS Data were analyzed using Workflow4Metabolomics (W4M), an online platform for metabolomics data pre-processing including XCMS Online  [50, 51]. A pre-processing workflow was created following three global steps: (i) the extraction method used CentWavechromatographic peak detection with a max tolerated ppm m/z deviation of 15. 0 and a minimum difference in m/z of 0. 008, (ii) the alignment method was completed by grouping chromatographic peaks within and between samples by PeakDensity with a bandwidth of 10 and by using Obiwarp for the retention time correction  [52] , and (iii) Camera.
1 H-NMR Spectra were processed using TopSpin 3. 6 software (Bruker Biospin, Karlsruhe, Germany) and were reduced to buckets of variable widths using AMIX software (Analysis of MIXture, version 3. 2, Bruker Karlsruhe, Germany). Bucket identification was done using ChenomX software (NMR Suite 7. 7, ChenomX, free software, Edmonton, Canada), an in-house database, and literature  [22].
Data Analysis Data obtained from the different preparation protocols for each matrix and the different analytical tools were analyzed. The number of metabolites, unique metabolites, and the coefficient of variation (CV%) were calculated. To identify the impacted metabolic pathways using the extracted metabolites, we analyzed the set of metabolites for each preparation by the Network Explorer module  [53]  implemented in Metaboanalyst4. 0, a freely available web-based metabolomics analysis suite (MetaboAnalyst4. 0, Quebec, QC, Canada http://www. metaboanalyst. ca/ (accessed on 10 March 2020))  [53]. The Network Explorer module was developed to support a network-based approach for multi-omics data integration and interpretation. This module is used to build the mapping of metabolites onto different types of metabolic pathways.
with all of them aiming to answer biological questions by using multiple available data sources, the issue of omics data integration is far from solved. Along with the issue of omics data heterogeneity and integration, scientists are challenged with the diversity of strategies and methods available to answer the same biological question, each approach having its own perks and benefits. The question of cancer subtyping is particularly representative of this kind of issue. By performing a clustering analysis, disease subtyping aims at detecting subgroups of patients (samples) showing similar characteristics. Even in the single-omics context, such analysis can be challenging, and numerous clustering strategies have been implemented and/or tested to this end: hierarchical clustering strategies, density-, distribution-or centroid-based strategies, supervised and unsupervised strategies, etc.
The selection of a clustering method as well as of the optimal parameters to use is generally tricky. Moreover, the various biological mechanisms that are involved may vary from one patient to another: each tumor is different and has its own characteristics, both in the tumor cells themselves and in their interaction with their environment. As these mechanisms are not restricted to a single molecular level, the detection of groups of patients showing similar characteristics across different omics is a key issue to enable personalized medicine, which aims to offer patients a treatment adapted to the characteristics of their tumors. This detection of groups of patients showing similar characteristics across different omics motivated the development of new computational methods implementing different strategies to analyze several omics datasets simultaneously (for detailed reviews, see  [1, 2] ).
According to the classification proposed in  [1] , the early integration strategy consists of concatenating omics datasets in a large matrix and applying a clustering method conceived for single-omics data  [3, 4]. However, late integration approaches first cluster each omics dataset independently and fuse single-omics clusterings into one multi-omics clustering  [5, 6]. Other approaches perform intermediate integration, fusing sample similarities across omics  [7] [8] [9] , using dimension reduction strategies  [10, 11] , or statistical modeling with Bayesian frameworks  [12] [13] [14]. To tackle both issues mentioned above, i. e. , multi-omics and multi-strategy integration, one may want to apply a particular type of late integration strategy by taking multiple clustering results (using different data, methods and parameters) and fusing all of them into one consensus clustering.
Such a consensus clustering should benefit from the complementary information carried by various omics data and capitalize upon the strengths of each method while fading their weaknesses. Note that with respect to classical late integration strategies that start from the raw omics datasets (e. g. , PINS  [6]  uses perturbations of raw omics data to generate the most stable multi-omics clustering), consensus clustering methods rely solely on clustering results. This property is essential, as it allows for any clustering algorithm and any clustering result to be used, regardless of the availability of the raw omics dataset and of its type. A naive way to compute a consensus clustering would be to perform the intersection of the clustering results, i. e. , by simply taking the associations on which all methods agree.
However, for the median partition-based approach, the choice of a similarity measure is determinant. Nevertheless, for consensus clustering in a multi-omics multi-method context, comparing co-occurrences of objects is more pertinent than comparing similarities between partitions. Here, we present ClustOmics, a new graph-based multi-method and multi-source consensus clustering strategy. ClustOmics can be used to fuse multiple input clustering results, obtained with existing clustering methods that were applied on diverse omics datasets, into one consensus clustering, regardless of the number of input clusters, the number of individuals clustered, the omics and the methods used to generate the input clusterings. The co-occurrence strategy implemented in ClustOmics (detailed in the "Methods" section) is based on evidence accumulation clustering (EAC), first introduced by Fred and Jain  [16].
Although computationally expensive, this strategy allows exploiting all clustering results, regardless of the number of clusters and their size and shape. We designed ClustOmics as an exploratory tool to investigate clustering results in order to increase the robustness of predictions, taking advantage of accumulating evidence. To allow the user to tackle a specific question and to explore relationship patterns within input clusterings and generated consensus, we store the data in a non-relational graph-based database implemented with the Neo4j graph platform  [17]. The use of a graph native database facilitates the storage, query and visualization of heterogeneous data, hence allowing the development of a solution that is flexible to various integration strategies. Indeed, by fusing clusterings from different clustering methods, different data types, different experimental conditions, or several options at the same time, through the use of what we call integration scenarios, ClustOmics can address a wide range of biological questions.
ClustOmics was applied in the context of multi-omics cancer subtyping, with TCGA data from different cancer types and multiple omics datasets. Input clusterings were computed with several single and multi-omics clustering methods and then were fused in a consensus clustering. Further details on the strategy implemented in ClustOmics are given in "Methods" section. To assess the benefit of this novel method, we further explored the robustness of our consensus clusterings with respect to the input clusterings, as well as their biological relevance, based on clinical and survival metadata available for each patient. We compare the ClustOmics results with those of COCA  [5] , a well-known co-occurrence-based consensus clustering tool that has already been used to combine multiple omics datasets to reveal cancer subtypes  [18].
Results overview of the ten cancer types for the two integration scenarios Running ClustOmics and COCA on the ten cancer datasets with respect to the different integration scenarios implies starting by computing single-and multi-omics input clusterings to group patients according to their single-and multi-omics profiles. For the multi-to-multi (MtoM) scenario, multi-omics input clusterings were obtained with existing multi-omics clustering tools: PINS  [6] , SNF  [7] , NEMO  [8] , rMKL  [9]  and MultiCCA  [10]  (see Table  6 ). For the single-to-multi (StoM) scenario, the same tools listed above were applied, except for the MultiCCA tool, which can only be used in a multi-omics context and was replaced with the simple yet robust state-of-the-art method, K-means clustering  [19]. In this scenario, the tools were applied to each omics dataset independently.
Integration of multi-omics clusterings (multi-to-multi scenario) Input multi-omics clusterings were computed with the five multi-omics clustering methods presented in "Methods -Datasets and tools used for computing input clusterings" section using default parameters and following recommendations of the authors. The clusterings were produced using the multi-omics patients exclusively (those for which all three omics data are available). To make all input clusterings comparable, we ran NEMO in the same way, though compared to the other five tools, NEMO is able to handle partial data. ClustOmics was run with the min_size_cluster parameter arbitrarily set to 8 nodes for all cancer types, meaning that clusters of size below 8 were removed from the consensus clustering, with the corresponding individuals being reassigned to consensus clusters exceeding the size threshold.
Two cancer datasets, COAD and LUSC, showed the lower consistency between the input predictions and clustered with a number of supports of 2. For LUSC cancer type, the consensus clustering resulted in only 2 clusters, despite the large size of the available cohort (341 individuals). The computation of the adjusted Rand index (ARI)  [20]  between input clusterings, a measure of similarity between partitions, showed that for these two cancer types, SNF and NEMO clusterings were very similar (with an ARI value of 0. 7 for COAD SNF and NEMO clusterings and of 0. 9 for LUSC; see Additional file 1: Figure  S2 ) while the 3 other input clusterings showed high pairwise dissimilarity ( ARI ≤ 0. 4 ). The resulting consensus clusterings for both Clus- tOmics and COCA were very similar to SNF and NEMO and dissimilar to the other input clusterings, failing to compute an actual consensus of all input partitions.
Integration of single-omics clusterings (single-to-multi scenario) To assess ClustOmics performance when fusing simultaneously input clusterings computed from different omics data and with different clustering methods, we investigated a second integration scenario, combining single-omics clusterings produced independently on each omics dataset. The overall cancer consensus results for this scenario are displayed in Fig. 2  and discussed in detail in this section. As stated above, single-omics clusterings were computed using the following five clustering tools: PINS  [6] , SNF  [7] , NEMO  [8] , rMKL  [9]  and K-means clustering  [19]  (with an optimal number of clusters computed with the Silhouette index  [24] ). To assess the benefit of including individuals with missing data (not measured for all omics), two analysis were performed for this scenario: • For StoM OnlyMulti, input clusterings were computed using exclusively multiomics patients.
Moreover, for 3 cancer types, BIC, GBM and LUSC, capitalizing on all available individuals resulted in increasing the number of supports used to filter the integration graph. The largest increase in the number of supports threshold was observed for BIC, i. e. , from 7 supports in the StoM OnlyMulti up to 11 in the StoM All run. For LIHC, OV and SKCM, however, we observe a decrease of -2 , -1 and -1 , respectively, in the number of supports. For the other cancer types, the threshold on the number of supports is identical between the two runs. In the follow-up of this study, we will focus on the results of the StoM All run. In this scenario, the maximum possible number of supports is 15 as the five clustering methods were run on three omics datasets for each cancer. Note that for this scenario, the threshold on the number of supports used to filter the integration graph has great influence on the capacity of ClustOmics to produce consensus clusters across omics and on the interpretation of the results.