dataesr/scientific-paragraphs-categorization huggingface dataset:
24 We simulated random sampling genotype pairs with replacement to create 5000 hypothetical donor-recipient pairs within each population (subdivided in 10 groups of 500 pairs). (  2 ) In parallel, 10,667 HLA genotypes from renal transplant donor-recipient couples were extracted from the DIVAT database to assess eplets in a real practice donor-recipient matching setting. These pairs were first upgraded through the HLA-upgrade tool  20  to get high-resolution HLA genotypes. Data from simulated pairs, along with real data pairs from DIVAT, were formatted for the HLA-Epi workflow; we used the multiple search mode and selected all eplet types (exposed, cryptic, checked and unchecked). Outputs provided by HLA-Epi were then analyzed and visualized with the R statistical analysis software (https:// www.
| Comparison to other related tools We validated HLA-Epi by comparing the calculated epitopic HLA class I and class II mismatch scores against two related tools: HLAMatchmaker 3. 1, Excel-formatted program for HLA antibody analysis and eplet-based matching based on EpRegistry (as HLA-Epi), and PIRCHE, algorithm established to identify peptides presented by APC to recipient CD4 T-cells after digestion of HLA protein residues. We considered HLA-A, -B, -C alleles for class I HLA genes and HLA-DRB1 and -DQB1 alleles for class II HLA genes from 1000 randomly assigned pairs from 1KG European ancestry. The mismatch scores were calculated in the HvG way. Linear regression analyses were performed to compare similarity between the different scores. For HLA-Epi and HLA_Matchmaker, both class I and class II mismatch scores as well as the only given PIRCHE output (corresponding to PIRCHEII score for HvG) were retrieved and compared HLA-Epi mismatch scores (class I, class II, and class I + class II).
| Eplet database characterization The EpRegistry database includes correspondences on 560 distinct eplets carried by 2976 HLA alleles. Although this database covers only 10%-15% of all described HLA alleles (30,862 known to date, April 2021, https://www. ebi. ac. uk/ipd/imgt/hla/stats. html), it represents more than 99% of the overall HLA alleles observed frequency. Only rare alleles, with frequency below 10e-6, are not represented in the database. Characteristics of the eplet database are summarized in Table  1. "Unique" eplets are exclusively present on one HLA gene; in other words, a unique eplet will only appear on some alleles within a gene but not on any other HLA gene. On the other hand, some eplets are not only shared between different alleles of the same HLA gene but also between different HLA genes (Figure  2 ).
| HLA-Epi comparison with HLAMatchmaker and PIRCHE software We created a dataset of 1000 randomly assigned European-ancestry donor-recipient pairs from 1KG dataset and compared our HLA-Epi tool results with HLAMatchmaker and PIRCHE. Our HLA-Epi tool shows high similarities with HLAMatchmaker (Figure  7A, B ); ) when some alleles coming from the recipient are unknown to the HLAMatchmaker algorithm. Indeed, in Figure  7B  case 2, no eplet arise from the unknown HLA allele of recipient and consequently increase the number of unknown eplets from the donor. In addition, HLAMAtchmaker can sometimes count 2 mismatches for the same epitope, when HLA-Epi only accounts for 1 (e. g. , 74SV for HLA-Epi becomes 74S and 75 V in HLAMatchmaker). Finally, third and most common case is when the HLA-Epi score is higher than HLAMatchmaker (Figure  7B  HLAmatchmaker, hence, less possible eplet mismatches can be characterized.
It also provides the overall eplet mismatch load, as well as details on mismatch eplets. Importantly, the possibility to impute missing or low-resolution HLA genotypes with HLA-Upgrade algorithms is a non-negligible asset for HLA-Epi, even if HLA-DQA1 and HLA-DPB1 genes are currently not covered in our reference haplotypes database. Although imputation may come with some uncertainties (86%-97% accuracy for low to high resolution imputation found in Geffard et al. ,  18  ), high resolution imputation is an important feature of HLA-Epi as many historical cohorts were typed in low resolution or with missing alleles, their epitopic HLA potential can now be investigated. Regarding applications, HLA-epi allows studying epitopic compatibility between a recipient's HLA genotype and potential(s) donors' genotype(s) in the HSCT context.
Regarding epitopic targets, HLA-Epi and HLAMatchmaker both focus on eplet mismatches and rely on different versions of the same database (Epregistry). As a consequence, strong correlations between the two tools were observed (Figure  7A, B ). However, most of the time, HLA-Epi counted more mismatches compared with HLAMatchmaker. HLA-Epi covers more HLA alleles than HLAMatchmaker (1930 vs. 1900 class I alleles, and 983 vs. 700 class II alleles, respectively) resulting in more potential mismatches. Second, HLAMatchmaker does not count some closely related epitopes as mismatches (e. g. , 71AK ! 71AR) contrary to HLA-Epi. Our tool therefore addresses some of HLAMatchmaker limitations. First, its spreadsheet-based interface makes it very heavy and slow as soon as more than 10 pairs are simultaneously evaluated.
, case 3, HLA-Epi = 53, HLAMatchmaker = 28), HLAmatchmaker tool does not consider the latest version of the eplet database. Newly characterized eplets are not present in F I G U R E 7 Comparison HLA-Epi to other epitope-matching related tools. Correlation between HLA-Epi scores and (A): HLAMatchmaker class I mismatch score, (B): HLAMatchmaker class II. Three scenarios were considered to further investigate the differences between tools: 1: HLA-Epi = 0, HLAMatchmaker = 1, 2: HLA-Epi < Matchmaker, 3: HLA-Epi < Matchmaker. (C): PIRCHEII epitopic mismatch score. Dots were colored according to the number of HLA allelic mismatches.
ACKNOWLEDGMENTS Acknowledgments to  Données Informatisées et VAlidées en Transplantation Cohort (DIVAT) Consortium. Nicolas Vince  has received funding from the  European Union 's  Horizon 2020 research and innovation program  under the  Marie Skłodowska-Curie  grant agreement No. 846520. This work is supported by the  ATIP-Avenir Inserm program , the  Region Pays de Loire ConnectTalent. Analysis and interpretation are those of the author.
Introduction With the emergence and the production of a large volume of spatial data, supporting large-scale and high-performance queries becomes crucial and essential in several fields. The tremendous advances in technology such as smartphones, the internet of things, web, navigation systems and sensors, have led to the production of large size spatial datasets. For instance, data related to climate and precision agriculture sectors is produced in high precision and large temporal sequences  [1, 2]. Processing this large volume of data is both a challenge and a real opportunity. In fact, querying large-scale data allows for extracting more valuable and meaningful information that is vital for decision making, scientific advancement and scenario predictions. The major requirements for the data-intensive spatial applications are the processing time and scalability.
The query calculates the average of the temperature stored in the rasters and provide as a result the sequence of rasters corresponding to the desired environmental phenomena (e. g. , period of intense rain). With another application such as rasters representing soil humidity, it is possible to select the rasters that correspond to a period of intense rain (or of drought). These analyses are very important in many environmental fields and in very large datasets, it is therefore essential to be able to select these rasters of interest very quickly. The results presented in the paper show that GPGPU-based methods reduce the execution time and enable us to obtain the query response three times faster than the sequential methods. Moreover, we propose a sorting step using a GPGPU to boost the response time of the query by rejecting the unwanted results in the early stages and, hence, saving computations.
For example, it is useless to continue to calculate a temperature average for the rest of the rasters in a data set, if whatever the remaining temperature values, the user-defined temperature threshold can never be reached. A sorting data step was introduced in the method in order to improve the performance for rasters having a high variation of values. This result is presented and discussed in the experiment section. Unlike our previous work in  [9]  which is based on overlapping aggregation raster subsequences and limited to providing a data summary for simulated datasets, the actual work deals with a specific selection spatial data query based on the user condition. Hence, besides the aggregation of disjoint raster subsequences, the query resolution requires a testing step which rejects the subsequences not satisfying the condition.
Therefore, compared to the previous work, first, we have designed and implemented both a straightforward CPU and GPU version methods for that query. Second, we propose a sophisticated rejection heuristic in order to reject the unwanted subsequences in the early stages and as a result, the useless, heavy computations are avoided. We have introduced the idea of early data rejection in a single raster in  [8]. Finally, the proposed methods are tested on a real dataset and can be used for other types of data that have the same characteristics and can be extended to other operations. The rest of the paper is organized as follows. Section 2 reviews, firstly, the main related works and secondly, introduces some basics of spatial data, presents a description of our query and provides the main principles of the heterogeneous computing, the GPU architecture, and the main Nvidia libraries: CUB  [10]  and Thrust  [11].
In an effort to raise the challenge of providing interactive queries over large spatial data sets and efficient support for visualization, the work presented in  [22]  proposes a new GPU-based index to speed up interactive spatio-temporal queries over large historical data. The proposed method, STIG (spatio-temporal indexing using GPUs), was implemented in MongoDB  [23]  and tested using two large data sets: NYC taxi trips and Twitter data. The results of the experiments have shown the efficiency of STIG which was capable of obtaining interactive, sub-second response times for queries over the two large datasets and has overcome the existing solutions. Other works have been proposed to use the GPGPUs for GIS and spatial data. For instance, in  [24] , the researchers proposed to use the GPGPU so as to speed up the interpolation of massive point clouds, using the natural neighbor interpolation method (NNI).
The work presented in  [25]  proposes to use the GPGPU to speed up some spatial database queries, and in particular, distance queries. The authors of  [26] , suggest an implementation of seismic wave, rock magnetism propagation and computational fluid dynamics based on the GPU. Finally, the work proposed in  [27] , implements basic operations for raster analysis based on the GPGPU. Recently, in  [9] , we proposed a parallel approach to speed up the overlapping aggregation process of raster sequences used for generating data summaries. The method is based on the use of prefix sum and reduction algorithms implemented on a GPU using the CUB and Thrust libraries. The results highlight more than 40 examples of speedups. In  [28] , we proposed an algorithm based on a GPGPU implementation to accelerate the large-scale raster selection queries based on a threshold fixed by the user.
GPU-Accelerated Libraries for Computing NVIDIA GPU-accelerated libraries provide highly optimized functions that can help users to write and optimally scale applications. Using them allows for highly efficient implementations of algorithms that are widely used as building blocks for many applications in several fields and many kinds of libraries are available. There are libraries for linear algebra (cuBLAS and CUDA Math library). For deep learning, there are libraries for parallel algorithms such as Thrust (used for parallel algorithms and data structures). The libraries that interest us in this work are Thrust and CUB since they provide a set of fundamental parallel algorithms that are implemented in an optimized and efficient way, such as reduction and sort, which are used in this work.
ISPRS Int. J. Geo-Inf. 2021, 10, x FOR PEER REVIEW 10 of 18 objective, we have chosen a data parallel primitive approach, for instance the cub::Device-SegmentedRadixSort parallel primitive function which allows the performing of a batched radix sort across multiple, non-overlapping sequences. The reason why we decided to use these parallel primitives was to reduce the implementation complexity and maximize the performance of our algorithms, since these parallel primitives are highly optimized. Once the rasters are sorted, we move to the second step and it consists of splitting each sorted raster into equal segments (tiles). Thus, the first tile of each raster contains the cells of the largest numbers. We consider the positive numbers for cell values. In the case of negative numbers in the datasets, shifting by a large number is needed (e.
g. , adding 100 Once the rasters are sorted, we move to the second step and it consists of splitting each sorted raster into equal segments (tiles). Thus, the first tile of each raster contains the cells of the largest numbers. We consider the positive numbers for cell values. In the case of negative numbers in the datasets, shifting by a large number is needed (e. g. , adding 100 to all the values). In the first iteration, we compute only the sum of the first tiles of each raster for a given subsequence S j. If the result Res 1 is not satisfying the query condition, then the subsequence S j is rejected. Otherwise, we repeat the same processing for the second tiles of each raster in S j , add it to Res 1 (the previous results of the first segments) and check the results. If the Res 2 is not satisfying the query condition then S j is rejected.
ISPRS Int. J. Geo-Inf. 2021, 10, x FOR PEER REVIEW 11 of 18 Based on the Sophisticated Sort We consider that we do not know in advance on which datasets the query will be applied as the data set can change from one query to another. We take the point of view of a database management system (DBMS) designer and the goal is to implement generic DBMS operations. Our goal is not to improve the computation for a particular data set. Sorting is expensive, i. e. , the time complexity of a sort is O(n log n) in the case of quicksort, and is higher than the sum computation, i. e. , O(n). In practice, the sorting cannot be a preprocessing step of all the rasters of the whole data set before the query execution, because this process is too time-consuming and the dataset used for a query will not necessarily be reused for later queries.
We propose to execute the sorting at the query runtime on only some rasters. More precisely, we propose the following: 1. Split the dataset of our rasters in time windows containing a fixed number of rasters. Thus, we propose to sort only one raster from each time window. The sorting result can be viewed as an array M mapping a cell position (x, y) to an order position I. 2. The cells of rasters falling in the same time window will be reordered based on the sorted raster of this time window. To do this, the array M will be directly used during the average computation without an impact on time complexity. The time window can be the size of the subsequences. Figure  5  illustrates this approach. As we can see in this figure, the data sets are divided in three-time windows of a fixed size 7. In the second step, for each segment, one raster is sorted and the rest are reordered accordingly.
Based on the Sophisticated Sort We consider that we do not know in advance on which datasets the query will be applied as the data set can change from one query to another. We take the point of view of a database management system (DBMS) designer and the goal is to implement generic DBMS operations. Our goal is not to improve the computation for a particular data set. Sorting is expensive, i. e. , the time complexity of a sort is O(n log n) in the case of quicksort, and is higher than the sum computation, i. e. , O(n). In practice, the sorting cannot be a preprocessing step of all the rasters of the whole data set before the query execution, because this process is too time-consuming and the dataset used for a query will not necessarily be reused for later queries. We propose to execute the sorting at the query runtime on only some rasters.
• The type of data (the temperature, pressure, etc. ). The less the data is evolving over time the more the sorting is accurate. The proposed methods perform better when the spatial locations of maximal and minimal values evolve slowly over time. To implement that, first we sorted the indexes (keys) of the rasters that must be sorted. We used the sorted keys to reorder the other rasters. To sort the raster and indexes, two solutions are available: the solution based on CUB with cub::DeviceRadixSort::SortPairs, and the solution based on Thrust with thrust::sort_by_key. The other rasters that fell in the same time windows were reordered (sorted) according to the sorted raster using the gather transformation that could be implemented using the primitive thrust::gather. Once the rasters were sorted, we needed to implement the kernel responsible for computing the average of the subsequences using our method described above.
Configuration of the Experimental Environment Our experiments were performed on two platforms. Concerning the parallel methods, we have used a GPU-based platform: Tesla K20 C, while the sequential approaches were performed on Intel(R) Core(TM). To implement our methods we have used C++, CUDA and the libraries Thrust and CUB. Table  1  shows the details related to the used hardware and software configuration. In the tests, we aimed to outline the power of using the GPGPU platform to speed up the spatio-temporal raster queries over the classical approaches based on the CPU. Besides this, we showed that based on the type and the distribution of data in our dataset, we could gain more performance by using the sort heuristic presented above.
Dataset 4. 2. 1. INRAE Montoldre Site In our experiments, we used a dataset provided by the INRAE Montoldre site  [30, 31] , which is a large experimental farm located in Montoldre. This was later dedicated to the development and the experimentation of agri-environmental techniques. Based on a sensor network composed by LiveNode  [32]  (developed by LIMOS), this platform provides real data that are used by researchers in their work related to the environment. The measurements used were air and soil humidity, temperature and light and they were measured using several sensors distributed over the Montoldre site. The Montoldre raw dataset produced by LiveNode is composed of two SQL tables, the network table and the sensors table.
• The sensors table contains columns such as: myNodeID, battery, temperature, humidity, light, etc. , and 14,970,995 rows which correspond to the measurements of the different sensors during many months with a different fine-grained frequency of acquisition. The table below (Table  2 ) shows the description of some measures. Note: Watermark1: this sensor is deployed at 10 cm depth in the soil; watermark 2: this sensor is deployed at 20 cm depth in the soil; watermark3: this sensor is deployed at 30 cm depth in the soil. The inverse distance weighted IDW  [33]  interpolation method was used for predicting the missing values of the unsampled locations to produce rasters based on the raw INRAE dataset. Hence, 3550 rasters were produced in four different resolutions (300 × 300, 350 × 350, 400 × 400, 450 × 450) for three types of measures (temperature, humidity, watermark 2).
Experiment Results In this subsection we present the results of our method. As cited before we have used several datasets with three measures: temperature (Table  4 ), humidity (Table  5 ), and watermark 2 (Table  6 ). Hence, we present the results for each measure. To do this, we have generated four datasets and each one contains: 3550 rasters with a different raster size. We have fixed the size of the time windows at 10 and the size of the sequences as equal to 6. As you can see, hereunder, The Table  4  represents the results on the temperature measure, the Table  5  concerns the air humidity measure, while the Table  6  shows the results using the watermark 2 measure. As we can see in the results, using the temperature datasets always showed good results for using the GPU over the CPU version; however, our improved method based on the rejection step based on sorting, showed bad results for the CPU-sorting and the GPU-sorting for the temperature dataset.
The time of execution was worse compared to the methods without sorting. Our improved methods are based on a sorting step that must allow for rejecting the raster sequences earlier; however, the values of the temperature dataset were too close to each other in the rasters. The mean of rasters standard deviation of temperature was equal to 2. 73, which explains the low variation of the values in the temperature rasters data. The goal of the sorting step was to allow for summing the highest values first. Consequently, when the values were too close in the rasters, the sorting step was useless in reaching the threshold quickly and rejecting rasters in an earlier stage. In this case, the sorting step became a heavy burden on the method, since sorting is expensive in term of computations. Hence the execution time was higher than the methods without sorting.
Concerning the humidity and watermark 2 datasets, the GPU-based methods were always better than the CPU methods (Tables  5  and 6 ); however, unlike the previous results based on the temperature dataset, our methods using the sorting step enhanced the results of the parallel version. This is due to the sorting step which allowed for rejecting raster sequences in earlier stages, because of the distribution of the humidity and watermark data values. The mean of rasters standard deviation of the humidity dataset was equal to 15. 20, and 43. 79 for the watermark 2 dataset (Table  3 ). As a summary, our methods without sorting based on the GPU give good results compared to the CPU over all the datasets and the measures however, when the dataset has a high variation of values such as for humidity and watermark 2, using our methods based on sorting can improve the results, since it allows us to reject data not satisfying the user condition in the early stages.
The Impact of the Time Window Size on the Performance Here we show how the time window size impacts the performance over "dataset 4" for the watermark 2 measurement using the same fixed parameters cited above. As we can see in Figure  6 , when the time window size is too small (size = 3), the number of time windows increases as well as the number of sorted rasters. Since the sorting is expensive, this will increase the time execution. On the contrary, when the time window size is too large (size = 20), it will impact the reordering precision of the rasters and hence the sorting becomes useless which will lead to a performance drop; however, when the time window is not too small and not too large (size = 10), we obtain a good performance. for the watermark 2 measurement using the same fixed parameters cited above.