dataesr/scientific-paragraphs-categorization huggingface dataset:
In multiple-kernel learning frameworks, this method may be especially beneficial for data containing no identifiable clusters. K-sparse clustering  [49]  is an algorithm combining dimension reduction and relevant feature selection using a constraint in L1-norm rather than a lasso-type penalty to select the features. The performance of an unsupervised clustering method is measured by its ability to partition data. Partitioning is considered optimal when it minimizes the average distance between patients within a cluster (homogeneity) and maximizes cluster distances 2 by 2 (separability). The performances of the five methods were compared using the silhouettes index (SI)  [39]. The SI ranges between À1 and 1 and assesses whether a patient belongs to the ''right" cluster. The closer the index is to 1, the more satisfactory the assignment of a patient to a cluster.
Median follow-up with a 95% confidence interval was calculated by reverse Kaplan-Meier method. All analyses were performed with Matlab Ò R2018b for PCA k-means, Spectral clustering, SIMLR (https://github. com/BatzoglouLabSU/SIMLR/tree/SIMLR/MATLAB) and k-sparse clustering and R  [51]  using package Sparcl  [52]  for sparse k-means clustering. The difference between clusters regarding the most biologically significant metabolites was plotted using boxplots. For clinical and biological analyses, all p-values <0. 05 (two-sided) were considered statistically significant.
Prediction for 5-and 10-year overall and specific survival Web-based prognostication PREDICT tool (https://breast. predict. nhs. uk/tool) [9, 10, 53]  was used to estimate predicted OS (pOS) and predicted SS (pSS) at 5 and 10 years, based on several patient and tumor characteristics. For each patient, ten characteristics were entered manually: age at diagnosis, menopausal status, estrogen receptor status, Her-2 status, Ki-67 status, tumor stage, histological grade, mode of detection, number of positive nodes and presence of micrometastases. PREDICT tool can be used to estimate expected overall survival at 5 years and 10 years in the absence of available survival data due to short follow-up. If information was missing for detection, bisphosphonate therapy or menopausal status, patients were not excluded but the ''unknown" category was used.
From a machine learning perspective To the best of our knowledge, this proof-of-concept study is the first to compare different unsupervised ML methods to identify metabolomics-based prognostic signatures in BC. Analyses were performed intentionally without any prior clinical or biological assumptions. Clinical and biological interpretations were performed only after cluster identification. The objective of our study was to compare different unsupervised ML algorithms for feature selection from untargeted metabolomic data and to evaluate the capacity of these methods to select relevant features for further use in prediction models. This study did not seek to highlight significant differences but rather to assess how unsupervised methods might behave with high-dimension metabolic data and to open up new perspectives in the particularly active domain of BC  phenotype predictors.
Other unsupervised ML methods such as model-based clustering, bi-clustering and deep learning may be of value in this analysis and should be further explored. Yet it is worth noting that, even       Glycine, serine and threonine metabolism 48 13 0,0040 5,5100 0,4699 though deep learning methods are of particular interest in many fields, they necessitate a very large number of patients to be efficiently trained and may therefore not be suitable for small metabolomics datasets obtained on real life patients, such as the one we have used. While obtaining imaging or clinical data concerning several thousands of patients seems achievable, obtaining metabolomics data for that many patients is currently much more complicated. Furthermore, even though some efforts are being made to tackle this issue  [60] , it is currently impossible to understand which features are responsible for the outcome when using deep-learning clustering techniques.
Average Energy Balance In steady-state regime, the following energy balance can be written for the cylinder wall: Qw + Ẇloss = Qamb + Qcooling (33) where Ẇloss is the mechanical friction loss dissipated as heat, Qcooling is the heat removed by a possible cooling system (e. g. water cooled engine) and Qamb is the ambient heat loss: Qamb = AU amb. (T w -T amb ) (34) Numerical Solution Method and Model Closure The model described above has been implemented in Matlab and the numerical solution is reached as follows. First the inputs are defined, the geometrical variables are computed, the wall temperature is guessed and an assumption on initial state of the fluid is made. Then the governing differential equations are solved using the Euler forward method. Once the evolution of the fluid state during one revolution is known, the guessed initial values are compared to final values.
Assessment of bending stress induced by specimen distortion The studied cruciform specimens have overall symmetrical geometry but initial distortion due to the welding process induces an additional bending stress during tensile tests. The use of TSA to quantify this additional part of the stress is evaluated in this paragraph. To validate the experimental results, a first finite element model has been implemented with the commercial software Abaqus to simulate only the mechanical behaviour of the specimens. Assuming two symmetry planes, only one fourth of the specimen geometry is considered and a driving force is applied at one end (Figure  6 ). Initial distortion is introduced by setting the weld detail center offset of clamp axes by 0. 75 mm (Figure  6 ). This value has been measured onto the mean specimen profile thanks to in-situ digital image correlation measurements when both ends of the specimen were clamped.
The crack growth rate does not significantly evolve with crack size iv. With as-welded joints, multi-site crack initiation are captured along weld toe, whereas TIG dressed specimens show in average only one crack propagation per weld seem. v. Crack coalescences can be observed on as-welded joints. vi. For as-welded configuration, propagation phase corresponds to more than half of the fatigue life, whereas propagation phase represents only a short fatigue life part of TIG dressed specimens. This database of observations, collected exclusively through thermoelastic coupling study, may potentially be used as an identification base for future modelling works. In addition, all the informations that can be extracted from the thermoelastic coupling is only one part of the data contained in the infrared films.
The continual evolution of photon sources and high-performance detectors drives cutting-edge experiments that can produce very high throughput data streams and generate large data volumes that are challenging to manage and store. In these cases, efficient data transfer and processing architectures that allow online image correction, data reduction or compression become fundamental. This work investigates different technical options and methods for data placement from the detector head to the processing computing infrastructure, taking into account the particularities of modern modular highperformance detectors. In order to compare realistic figures, the future ESRF beamline dedicated to macromolecular X-ray crystallography, EBSL8, is taken as an example, which will use a PSI JUNGFRAU 4M detector generating up to 16 GB of data per second, operating continuously during several minutes.
Although such an experiment seems possible at the target speed with the 100 Gb s À1 network cards that are currently available, the simulations generated highlight some potential bottlenecks when using a traditional software stack. An evaluation of solutions is presented that implements remote direct memory access (RDMA) over converged ethernet techniques. A synchronization mechanism is proposed between a RDMA network interface card (RNIC) and a graphics processing unit (GPU) accelerator in charge of the online data processing. The placement of the detector images onto the GPU is made to overlap with the computation carried out, potentially hiding the transfer latencies. As a proof of concept, a detector simulator and a backend GPU receiver with a rejection and compression algorithm suitable for a synchrotron serial crystallography (SSX) experiment are developed.
Graphic processing unit accelerators The computationally intensive conversion of raw data produced by a detector like the JUNGFRAU detector and their subsequent online processing imposes the use of massively parallel computing engines. Graphic processing units (GPUs) are now routinely used in high-performance and scientific computing applications because of their superior performance and ease of use. These are the best candidates to treat the data streams produced in SSX experiments. During the time slot available between two images, the GPU can perform the raw-data correction, followed by the image rejection or compression. However, to sustain this type of data treatment for a long duration, it is essential to transfer the detector data into the GPU memory continuously and to trigger the events required to synchronize computation and data flow.
Proof of concept Commercially available detectors commonly use either proprietary or 10 Gb ethernet links. As a proof of concept, we have emulated a detector with a Linux workstation using a 100 Gb s À1 ethernet RDMA network interface card (RNIC) from Mellanox Technologies. This test bench aims at exploring and leveraging RDMA/zerocopy techniques and online GPU dataprocessing capabilities. Firstly, we verified that the RNIC was able to keep up with the expected throughput when transferring data to CPU memory. Then we proposed an efficient synchronization mechanism between the RNIC and the GPU. It appears that this transfer, from the RNIC to the GPU accelerator, is capped by the computer internal-bus throughput that might be lower than the 100 Gb s À1 of the network link. During the time slot available between subsequent frames, we were able to perform the conversion of the JUNGFRAU detector raw data and the image rejection using a very basic Bragg's peaks counting algorithm.
Limitations of conventional data transfer The most recent generations of NICs support 200 Gb s À1  (Mellanox, 2019). However, when using the traditional software library (socket API), packet losses might be experienced and they are not dropped during the transmission phase but within the operating system. This is a well known flaw  (Price, 2019) , related to the inner complexity of the network stack. Many time-consuming tasks are executed under the hood: data copies from/to the user and kernel memory space, complex interrupt handling and context-switches, etc. Fine-tuning of the operating system, e. g. increasing multiple buffer size, carefully allocating interrupt handling and disabling the Linux kernel from pre-emptively scheduling tasks onto the core dedicated to the receiving task, enables higher rates to be achieved  (Marek, 2015) , but the result does not scale well above 10 Gb s À1.
Methodology Benchmarks of conventional non-RDMA and RDMAbased data-transfer software applications were carried out by transferring packets tagged with an incrementing packetsequence number to detect packet drops at the destination. To estimate the highest achievable bandwidth, we decreased the throughput until we obtained a transfer without losses for a given transfer size. The three technology families evaluated were: (i) Socket solution. This is the conventional method relying on the socket library. It has been widely used since the start of the internet and has continuously evolved and adapted over time but no longer suits new hardware. However, some optimizations are still possible by tweaking the operating system. (ii) Hybrid solution. This improves conventional applications leveraging the messaging accelerator library (Mellanox/ libvma, Mellanox Technologies), a software library which intercepts system calls to the socket API and transparently replaces them using RDMA operations.
(iii) Full RDMA solution, capable of reaching the target rate. We have evaluated three versions: WRITE, SEND and RAW. All are based on the libibverbs eponym API. Both WRITE and SEND packets conform to the RoCEv2 format but differ in the way they manage the destination memory address. In a WRITE operation, the destination address is chosen at the time of sending and embedded in the packet with the data. The receiver RNIC is then fully autonomous. On the other hand, SEND lets the data receiver resolve the memory address it writes data to, upon reception of said data. Some CPU effort is required; with the RAW API the RNIC hardware shall offload any incoming ethernet packet, according to configurable 'steering rules'. This mode underexploits some of the RNIC high-level capabilities.
Benchmark of transfer protocols Our results confirmed that the socket API and the hybrid methods suffer from packet drops. The measured throughputs are also far below the theoretical expectations for these methods. This is detrimental to our study and enforces the use of RDMA. 3. 2. 1. A socket and hybrid solution comparison. Table  1  presents a comparison of UDP using classic socket API without (column 1: UDP socket) or with Linux kernel optimization (column 2: UDP + kernel tuning), and the accelerated code with the VMA library (Mellanox/libvma) (column 3: UDP-VMA). The results are more reliable when sending data always to the same destination address than when sending data to 100 000 different memory addresses. This is because of the limited size of the RNIC cache memory. 3. 2. 2. RDMA solutions comparison.
RDMA-assisted online GPU image processing Processing in real-time large datasets, such as those produced in SSX experiments, is a major challenge. This computationally intensive task would put a lot of strain on the CPU without hardware accelerators such as GPUs. GPU accelerators efficiently handle massively parallel operations but are not fully autonomous. A CPU application is involved in orchestrating data transfers from the host CPU to the GPU device and back. Our control application also prelaunches the GPU kernels (code running on GPU) so that their execution begins as soon as the data are available. The actual execution is delayed until the occurrence of a RDMA transfer completion event. This mechanism is presented in the next section. For the sake of efficiency, we have implemented a dataprocessing loop with a sequence of three operations described below: (i) Data transfer to GPU memory through the peripheral component interconnect express (PCIe).
While the delivery order of UDP packets is not guaranteed, no reshuffle step is required thanks to the WRITE API which specifies the destination memory address in each packet. (ii) Conversion of the detector raw data (JUNGFRAU in our example) into floating-point values; this involves image rejection or compression. (iii) Transfer of the computational results from the GPU to a large CPU memory buffer when the image is not rejected. These sequences are CUDA streams that can be executed in parallel. This transforms the previous loop into a three-stage pipeline in which transfers overlap with computations.
GPU accelerator and RDMA synchronization mechanism Three heterogeneous systems are involved in our design: a RNIC, a CPU and a GPU. However, to date, a RNIC cannot directly trigger a GPU event so we have designed our own cascaded synchronization procedure described below: (i) By design, the receiver CPU is not informed of the ongoing RDMA traffic. However, it is possible to notify the CPU of an event: when a detector has sent a full image it uses a variant of the WRITE API that embeds a 32-bit event value in its payload. (ii) Upon notification, the CPU application in turn triggers the GPU stream execution. A memory lock mechanism relying on CUDA stream memory operation (cuStreamWaitValue32) initiates, with a minimal latency, the actions previously put on hold in their streams. This mechanism removes the launch overhead detrimental to realtime data processing, as shown in Fig.
2. As shown in Fig. 3 , the GPU application implements several double buffers so that the ongoing transfer is carried out in one buffer while computation is alternatively carried out in the second buffer. At the end of an RDMA transfer, a completion event triggers three simultaneous overlapping actions: (i) The start of a CPU to GPU transfer data chunk #n + 2. (ii) Consecutive kernel computations of data chunk #n + 1. (iii) Transfer from the GPU to a large memory buffer on the CPU of the result of data chunk #n (if the image is not rejected). When a non-pertinent image is rejected, the third step does not happen. Therefore, the result of the veto kernel algorithm shall conditionally trigger the transfer. As the condition is not evaluated prior to the launch, we use another stream memory operation lock triggered by the veto function.
This explains why NVIDIA is purposely integrating PCIe-switch chips into their highperformance DGX computers as a workaround for this issue. The maximum possible speed for data processing is defined by the minimum of: (i) RNIC to CPU speed, which is related to the length of the packet on the network (the width of the region of interest in the images that are sent). (ii) CPU to GPU speed, which depends on the size and number of images processed in the GPU; it is wise to transfer either a large image or a bunch of small images. For comparison purposes, Fig. 5  also exposes the performance of the ZeroMQ protocol, even if it relies on TCP/IP and therefore might not be easily embedded in a detector FPGA. The latest version of the CrystFEL software suite for SSX experiments has recently been upgraded with a ZeroMQ/ MessagePack interface  (White, 2020).
Detector raw-data conversion to float As stated in Section 1. 3, the JUNGFRAU detector has three gain levels for each pixel, stored in two of the most significant bits of the raw data. The pixel value is stored in the 14 remaining bits as an integer. Therefore, the conversion to the integrated charge is The GPU processing pipeline from top to bottom: DMA transfer, CPU to GPU transfer, data processing, GPU to CPU transfer. The pipeline involves three heterogeneous systems: RNIC, CPU and GPU. The RNIC cannot directly synchronize the GPU. Each stage in the execution pipeline is synchronized by an RDMA event or conditionally by the veto kernel result.
Raw i; j ½ADU À Pede i; j ½ADU Gain k;i; j ½ADU=keV ; where k is the gain level, and the raw data and pedestal are expressed in arbitrary detector units (ADU). This computation is inherently parallel. The gain factors are stored in a large constant dataset, i. e. they remain in the GPU memory, and only require one transfer from the CPU memory at the beginning of the process. Pedestal data are acquired interleaved with image data when the chopper is cutting the beam. These dark images are used to update the pedestal value for the highest gain. For the two other possible gain regimes, their pedestal value is expected to be constant.
Data rejection or compression In this work, our aim is not to propose any original or highly optimized algorithms but rather to assess a low-latency GPU/ RNIC integration. Therefore, all the evaluated GPU kernels are extremely simple to allow a fast evaluation compatible with the 1 ms time slot counting the raw-data processing. More crystallographic sensible algorithms still have to be developed. One simplistic rejection algorithm counts the intense pixels (considered as Bragg's peaks) in each image, without noise correction or outlier removal. A first threshold defines the signal needed for a pixel to be counted as a Bragg's peak, while a second threshold defines the minimum number of such pixels in an image to be accepted. Such counting has been implemented using atomic addition and shared memory.
Conclusions We have evaluated the feasibility of RDMA data transfer in the frame of high-performance X-ray detector development using gigabit ethernet data links after confirming the flaws of the standard socket API at 100 Gb s À1. It appears that oneway communication, a major challenge to stay compatible with detector embedded electronics, is possible using RoCEv2 unreliable datagram queue pair and WRITE verb API and commercially available RNICs in data-receiver computers. The expected throughput is effectively achieved without usage of the destination CPU without packet drop and is solely limited by the RNIC packet per second message rates for small-size payloads. The data flow could be dispatched to multiple dataprocessing accelerators in the destination computer because the memory address at destination is set by the detector source.
One can address online data-processing challenges, as encountered in SSX experiments, with GPU accelerators, for algorithms compatible with the reduced time slot available using a data-analysis pipeline and making simultaneous data transfers and computations. We proposed a synchronization mechanism with the GPU accelerator that minimizes the kernel start latency using stream memory operations. Required events such as the end of RDMA transfer have been implemented using WRITE_WITH_IMM to notify the CPU application scheduling the processing pipeline. Data transfer straight into GPU memory was evaluated with a GPU device featuring PCIe peer-to-peer capability (GPUDirect). Latency was decreased but throughput was also affected by hardware flaws. Our work has also highlighted that the main limitation to performing online data analysis remains the data-transfer rate from PCIe to GPU memory (capped at 88 Gb s À1 using our hardware), as it is now slower than the network throughput.
Release of new PCIes (generation 4) and other emerging highspeed GPU buses, such as NVLINK2, will contribute to a better exploitation of the full GPU processing speed. Based on the outcome of our work, one can draw some conclusions, as far as the serial crystallography example featuring a JUNGFRAU detector is concerned: in the UDP-based design, 9 Gb s À1 data transfer is the limit, with unavoidable packet drops in continuous operation. In a first step of improvement, with a RDMA-compatible NIC, using the VMA library and without changing the application software, one can reach almost 26 Gb s À1. At the price of the rewrite of the application code with RDMA API, it is definitively possible to saturate a 100 Gb s À1 link without a packet drop. The use of RDMA appears to be a very good solution to optimize the data transfer from the detector to a data receiver, especially the RoCEv2 technology preserving existing ethernet infrastructure.
Future work RoCEv2 routable properties make it also possible to fan out detector data to multiple-processing units for parallel processing, or the reverse -gathering in a single GPU accelerator the data flows from multiple detector modules. This functionality is a core feature of the RASHPA framework currently under development at the ESRF. For more efficient low-latency GPU processing, we are considering minimizing the number of kernel launches with GPU processing times on NVIDIA QUADRO P6000 of the proposed online algorithms, as shown using a NVIDIA profiler. They are compatible with the available 1 ms time slot of the foreseen SSX experiment. For comparison with real-world use cases, we provide numbers for the yet to be published peak_finder algorithm from the GPU pyFAI suite. This algorithm implements the peakfinder8 algorithm from CrystFEL on GPUs.