dataesr/scientific-paragraphs-categorization huggingface dataset:
Network prediction and functional annotation The sRNA-mediated regulation network is modelized by a bipartite graph where nodes represent either sRNAs or mRNAs and interactions are given by edges linking an RNA to another. To predict interactions between sRNAs (fasta file) and mRNAs (embl/genbank file), rNAV integrates two wellknown bioinformatics tools: ssearch  [20] , by reversing and complementing the second RNA to focus on interaction instead of homology, and IntaRNA  [21]. The functional annotation of sRNA targets is achieved by DAVID webservice  [22] , a single gene-term enrichment analysis software which exploits several biological knowledge databases. (e. g. GO, KEGG Pathways, UniProt Sequence Features). DAVID computes, for a given sRNA and its putative mRNA targets, the over-represented biological annotations (as well as a significance score) that are associated to the putative sRNA-mRNA interactions.
Conclusions To address the large amounts of data generated by new sequencing technologies, the integration of additional biological information is of great importance. Focusing on sRNA-mediated networks, bioinformatics tools are necessary to prioritize regulated targets but are still producing a prohibitive number of candidates. To address this problem, our strategy relies on providing a posteriori multipurpose information, according to the heterogeneous data extracted from databases and the visual exploration/analysis of the biological network. We present a new software for developing bioinformatics strategies to explore sRNA-mediated networks. The methodology used in rNAV combines bioinformatics tools which predict interactions and visualization techniques, and is freely available at http://rnav.
Platform and environment available One of the key platform assessed by GENCI and its partners is the Ouessant OpenPOWER system, hosted at IDRIS, Orsay, integrated by IBM with the following characteristics: -12 IBM System S822LC "Minsky" nodes with for each : • 2 IBM POWER8 10-core processors clocked at 4. 2 GHZ and 128 GB of main memory; • 2 NVidia P100 GPUs per socket; • each socket is connected to the 2 GPUs via NVLink 1. 0; all the nodes are federated through a Mellanox EDR Infiniband interconnect and access to a high bandwidth filesystem (IBM Spectrum Scale, formerly known as GPFS) This platform is installed using a Linux distribution (RedHat7) and has a variety in its compilation/execution environment. PGI, IBM and LLVM compilers were used on the platform to assess the applications. The main difficulty is that, at the moment, those compilers all have pros and cons.
AVBP AVBP is an explicit compressible code for fluid mechanics and reactive applications used by both research and industry groups  12. It has a hybrid, parallel MPI + OpenMP implementation. The domain is partitioned over the MPI tasks. For each MPI task, the local domain is partitioned into groups of cells. The main computational section of the code is constituted by an external loop over the groups of cells. The internal routine scheme includes 50% of the code with internal vectorized loops over the cells. The data implementation is structured in FORTRAN modules and globally shared over the routines. AVBP is based on a coarse grain OpenMP approach with the parallel static loop over the groups of cells. In order to remove memory bottlenecks, variables and arrays are declared with OpenMP Private clause and Threadprivate directive in the modules.
The contributions of every thread are store independently in the arrays passed in parameter and indexed in the latest dimension over the groups, as illustrated below with the arrays avis. The first GPU implementation has been performed using OpenACC programing model; a switch to OpenMP 4. 5 will be eventually studied in a second step. The choice of OpenACC over OpenMP 4. 5 has been motivated by the existence of the Unified Memory feature, even though in the very first implementation of the code, the data transfers have been manually managed using explicit directives. The GPU implementation uses the same scheme as the current OpenMP implementation, with an offload of the entire scheme function to the GPU. The OpenMP directive controlling the main loop over the groups has been substituted by an OpenACC directive to generate OpenACC gang or CUDA block.
The internal, vectorized loops are parallelized over OpenACC vectors and threads, to ensure a good GPU occupancy. Compared to the current, pure-CPU implementation, the following evolutions are required to manage the GPU offload: -Data from modules used within the scheme routine has to be allocated on the GPU using the OpenACC declare create directive in the corresponding module, bound with enter and exit data directives, and copied or updated to/from the GPU using OpenACC copy/update_device/update_host directives before and after the main loop. -Private variables and arrays in the threads with OpenMP Threadprivate directive was declared in the private clause of the OpenACC loop over the gang. -All the routines and function potentially offloaded to the GPU have been declared with OpenACC seq/vector directives.
EMMA EMMA is an MPI + CUDA code which was already running on GPUs before the beginning of the project. The porting effort was very small, a simple compilation and then a run enabled to get first results on the platform. At the moment, around 50% of the code is running on GPUs. The goal is to reach 80% of the code by the end of 2017. However, first results on the platform are available for this application. The CUDA kernel results are summarized in 1 while the full application is presented in 2. We see a huge decrease in terms of performance for running the entire application, this is clearly explained as the full application has not been ported to CUDA.
GPS GPS is an application developed in MPI and relying heavily on Fast Fourier Transforms. Approximately 100% of the code used by the test case is offloaded using OpenACC. The performance of this OpenACC implementation suffers from the absence of the GPU-Direct feature, which is set to be made available in 2018 with the next generation of systems based on POWER9. This leads to a significant performance penalty when using the Managed Memory feature in OpenACC. In order to evaluate the expected performance gain from GPU acceleration once the GPU-Direct feature will be released, the code has been tested without MPI ; numerical results will not be valid, but the same amount of computation is performed. In this configuration (with no specific optimization), the execution is approximately twice faster when using 4 GPU versus 16 POWER8 cores.
Hydro Hydro is a MPI + OpenMP code widely used by IDRIS in their workshops as a tutorial to learn MPI and OpenMP. This application is not involving deep optimization and tries to mimic what a common developer could implement in its application. The idea with Hydro is therefore to develop an OpenACC and an OpenMP implementation that could make the most of the P100 with a limited effort of development. This code could also become a good porting example for the community. However, a CUDA implementation has been developed as a first step, in order to evaluate the performance gain the GPU acceleration can offer. The performance level achieved through the CUDA implementation will constitute a reference target for the directive-based implementations. The following performance results have been obtained on a 8192x8192 grid (0.
Meso-NH Meso-NH is a code developed in MPI and OpenACC. A part of the code was already ported in OpenACC before the beginning of the project. There is an ongoing development and the team aims to port a huge part of the application before the end of 2017. First results on one node are already available for a given kernel in 5. For this particular kernel, we see a speedup of 5. 6 for using 4 GPUs on top of the POWER8 processor. We also can see a speedup of 2. 2 using 4 P100 compared to 2 K80. Those results are pretty good, however if we run the full application, the speedups, in table 6 are not as good. At the moment, the developer have troubles to port a significant part of the application on GPU. The solver involved is not as easy to port as the one previously ported. A porting effort of 2 years is envisioned in order to obtain a speed-up of 5 on the full application.
Metalwalls Metalwalls is a full MPI application for molecular dynamics. The code is written in Fortran 90 and has 20. 000 lines of codes. The time loop (computational part) is 3. 500 lines long and represents almost 100% of the time spent in the application. The strategy chosen by the development team was to port this application using OpenACC as it seemed, in their opinion, to be the most reliable technology available. 75% (of loop time) of the application is now ported to OpenACC, it took them 1 month to carry out this work. The estimated time for porting the full application is one other month. The first results are in table  7. Those results, after only one month of work are pretty good. However the work now has to be focused on running multiple GPUs and porting the remaining part of the code(the speed-up for 1 GPU is 3.
PATMOS PATMOS is developed in C++11/14 with an hybrid parallelism based on MPI + OpenMP. A CUDA version of the application was also available in a prior release and the main work performed by the development team was to include those CUDA kernels into the main branch of the application. This work has been done during the project and now 5% of the code (in lines, but representing 75% of the CPU time) is available in CUDA. The target is to port another 5% in order to almost cover the whole application. The results in table 8 and 9 are obtained using 1 MPI process per node, OpenMP threads are then used for the in-node parallelism. The results obtained on multiple nodes are almost as good as the ones obtained on the single node, which shows that the scalability of the application on this platform is very good.
These techniques allow for an effective use of all the computational resources available on the node  [12]. The porting on the OpenPOWER platform was relatively easy and needed only minor code fixes due the strict compliance to the Fortran standards enforced by IBM compilers. The graph below reports the strong scalability of the qr mumps solver on a number of problems from the University of Florida Sparse Matrix Collection. On the largest problem (matrix TF18) a performance of 407 Gflop/s was achieved using 20 cores, which corresponds to a remarkable 73% of the peak, with a very good scalability. Using one GPU with the 20 cores, the performance of 1. 2 Tflop/s was reached (sse 11, meaning of speed-up of 3 between one P8 node and one P8 node + one P100. The main problem at the moment is that the code does not use multiple GPUs on a single node as this functionality has not been implemented.
SPECFFEM3D GLOBE Specfem3D is widely known code developed in MPI, OpenMP and CUDA. The two test cases tested here are those available in the git repository (test small bench very simple earth and test small bench more complex earth). The code is running well on one node, with a speed-up up to 27 using a GPU versus a single P8 core. The constraint with Specfem3D is that the test case defines a number of MPI processes (which corresponds to the mesh partitioning). Moreover, we tried using the NVIDIA MPS (Multi-Process Service) for the P100 which would enable to run multiple CUDA kernels sent by different MPI processes on the same GPU. This lead to huge slow-down caused by memory copy to the GPU. This constraint has to be addressed in order to improve performance. The code is generated with the PGI compiler, CUDA gencode60 and IBM Spectrum MPI.
Conclusion and Future Work First of all, the POWER8 processor has to be defined as a very easy to use processor. We clearly have seen over the last year an improvement in the compilation environment which helped all of our users to port their application on the machine very easily. Unfortunately, for now, the goal that we want to achieve (i. e. porting all our applications to GPUs using OpenMP) is still a bit far from us. Indeed, the main difficulty for the users on this platform is to understand the GPU and how to adapt their application to it. While all of the users managed to port their application on the POWER8, only a few applications were run on the GPUs with a relevant level of performance. The platform can achieve very high performances while using CUDA kernels, the IBM XL compiler is mainly used for the code using CUDA kernels and provides a good level of performances.
However, we still expect that this platform will manage to run OpenMP for GPUs and get the same level of performances than OpenACC. Those features should be implemented in the IBM compiler by the end of the year. We also expect that modifying the code from OpenACC to write OpenMP kernel will not be too much time consuming. The opening of the platform, since April 2017, to the full French scientific community will be a new opportunity for us to push for OpenMP and to continue working using this paradigm at the national level. On top of that, we will assess the scalability of the platform, using even larger test cases. The results obtained with PATMOS (having an almost perfect scalability up to 8 nodes) make us believe that this particular point should not be an issue. Despite some porting troubles, the first results on the platform are very promising and we are looking forward to the next generation of OpenPOWER nodes.
INTRODUCTION In the era of Spatial Big Data  (Shekhar et al. , 2012) , more and more geo-referenced data are available via new acquisition data systems (remote sensing, social networks, sensors, etc. ). In this context, some NoSQL Spatial Database Management Systems (SDBMSs) have been developed to deal with the Velocity, Variety, and Volume of data. Several NoSQL databases have been proposed that can be classified into four categories: Key-value, Extensible record, Graph, and Document. Key-value database is a collection of data without a schema and organized as a collection of key-value pairs. Data represented by the "value" is accessed using "key". Extensible record databases represent data with tables, where each row can present different attributes (different columns). Graph database uses graph structure with nodes, edges and properties associated to theses nodes and edges to store the data.
Graph databases are suited for applications in which there are more interconnections between the data like social networks. Document databases allow storing and querying complex structured information as georeferenced documents  (tweets, images, etc. ). GeoBusiness Intelligence (GeoBI) technologies represent first citizens of systems allowing analysis of Spatial Big Data. GeoBI systems include Spatial Data Mining, Spatial OLAP, spatial statistical tools, and reporting systems. Data Warehouse (DW) and OLAP systems allow analyzing huge volume of data represented according to the multidimensional model, which defines the concept of dimension (the analysis axes) and fact (the analysis subject)  (Kimball et Ross. , 2002). On one hand, Spatial Data Warehouses (SDWs) and Spatial OLAP (SOLAP) systems extend OLAP functionalities by integrating spatial data into the multidimensional analysis.
, 2008). Moreover, motivated by expressivity, readability and interoperability offered by UML, we propose an UML profile for the design of: (i) document databases and (ii) SOLAP applications using Falling Star based on the document databases model. Indeed, the benefits of the usage of UML, and its associated Computer-Aided Software Engineering tools, for designing, developing and maintaining complex information systems have been widely proved in several computer science and application domains. Finally, we evaluate our proposal with some experiments. The paper is organized in the following way: Section 2 presents related work, and section 3 details the case study used all along the paper. Section 4 presents our spatio-multidimensional logical model and its UML profile representation. Section 5 shows the implementation.
Implementation Nowadays, among the most popular document SDBMSs, we can find CouchBase and MongoDB  (Filho et al. , 2015). MongoDB is a cross platform document database. Classified as a NoSQL database, MongoDB eschews the traditional table-based relational database structure in favour of JSON-like documents with dynamic schemas (MongoDB calls the format BSON). MongoDB supports a very rich set of spatial data types. Using GeoJSON format, MongoDB can store spatial data with a variety of geographic data structures. MongoDB natively supports topological operators such as intersection, union, etc. CouchBase stores data in a collection of documents. It provides native types for spatial data (i. e. point, line, etc. ). Data can be loaded using the GeoJSON format. CouchBase provides spatial views which support only window queries.
Design The conceptual and logical design of DW and SDW using UML, have been widely proved effective  (Mazon et al. , 2005; Boulil et al. , 2015). Indeed, the usage of UML profiles for OLAP and Spatial OLAP projects reduce design time efforts since UML profiles allow readable, well-formed and familiar class diagrams. A UML profile is a set of stereotypes, tagged values, and constraints used to adapt UML elements to a specific application. Stereotypes extend the semantics of existing elements for a specific domain. Tagged values are used to add new properties to existing elements. Finally, constraints are used to specify rules to check the validity of a stereotype. UML profiles can be easily implemented in Computer-Aided Software Engineering (CASE) tools such as MagicDraw, Eclipse, etc. Moreover, UML profiles can also be associated to automatic implementation of CASE tools to obtain high-quality, defect-free, and maintainable software products.
Falling Star Motivated by the good computation performance of the 1 collection approach, and trying to the spatial data redundancy issues  (Siqueira et al. , 2010) , we describe in this section our new document spatiomultidimensional logical model, named Falling Star model. The main idea is to represent all facts with the same spatial member by a single document. It means that the list of measures and non-spatial dimension members are associated to each spatial member. Our proposed model avoids spatial data redundancy. Indeed, spatial objects are complex objects that require important storage size. For example, the representation of a country at a high resolution can use millions of points. Falling Star is based on the previous UML profile for document database described in Section 4. 1. The UML profile for this approach is represented in Figure  3a.
IMPLEMENTATION In this section, we present the implementation of our UML profile using the CASE tool MagicDraw and the implementation of our logical model using document DBMSs. MagicDraw is a CASE tool supporting UML profiling mechanism with OCL constraints. OCL constraints are automatically checked by MagicDraw when an instance of a UML profile is defined, and an error message is displayed when necessary. By this way, MagicDraw allows users to define only models that are conform to the defined UML profile. Since document databases are not based on a wellaccepted standard yet, to show the generality of our implementation, we test it on two different document DBMSs: MongoDB and CouchBase. However, due to space limitation, we present in this paper only the implementation on MongoDB. Instead of taking a business subject and breaking it up into multiple relational structures, MongoDB can store the business subject in the minimal number of documents.
MongoDB documents are composed of attributevalue pairs and have the following structure: {attribute1: value1, attribute2: value2, … attributeN: valueN } All documents are stored in collections. A collection is a group of related documents that have a set of shared common indexes. MongoDB supports search by field, range queries, regular expression searches. Queries can return specific fields of documents and also include userdefined JavaScript functions. Therefore, using MongoDB, we have implemented the SDW of Figure  3b  as a collection composed of a set of documents. The number of documents is the number of the spatial dimension members. Each document is composed of two parts. The first one is composed of 4 pairs of key/value where key is an attribute representing spatial level and value is geometric.
The second part is an array of subdocument called "Fact" that presents <<LevelMeasure>>. Each subdocument is composed of 48 attributes: 11 of which are measure attributes from the fact, and the others come from all other non-spatial dimensions levels. An example is shown in Figure  4. We can note that geometric attributes (geom_nation, geom_region, geom_city) are stored only once, but they are associated to two facts (one for 29 May, and another for 20 May). In this way, spatial data is not redundant. Using MongoDB documents each document has a maximum size of 16MB. This feature is important to ensure that a single document cannot use excessive amounts of RAM. To deal with this problem, we have developed a java ETL program that calculates the size of each generated documents and splits it in several different documents that repeat the attributes of the spatial levels.
EXPERIMENTS In this section, we evaluate our proposal and compare it to existing logical models for document data warehouses. In particular, we evaluate our model with Spatial SSB data  (Siqueira et al. , 2010). Spatial SSB extends the SSB benchmark to support SOLAP queries with spatial predicates, such as intersection, containment queries. Motivated by the lack of benchmark for spatial big DW  (Chevalier et al. , 2015 )  (Dehdouh et al. , 2015) , we have modified Spatial SSB to write generated data on MongoDB using the Falling Star Schema. In particular, it generates a GeoJson file, which is loaded in MongoDB. Data is generated using different scale factors (sf), namely sf=1, sf=10, sf=20, sf=50 and sf=100 in our experiments. The scale factor sf=1 generates approximately 6*10 6 facts and 10,000 suppliers, for sf=10 we have approximately 6*10 7 facts and 100000 suppliers and so on.
Storage Performance We have compared our approach to the existing "1 collection" MLD0 model (since as previously described in Section 2. 1 there is no difference between the MLD0 and the MLD1). In particular, we have extended the logical model MLD0 presented in  (Chevalier et al. , 2015). MLD0 stores data in one collection, where each document presents an attribute for each level. We have added to MLD0 geometrical attribute. We can note that for each fact (each document) the geometries of spatial levels (polygons composed of 10,000 points) are repeated. We have compared our proposal and the extension of MLD0 under two aspects: data storage and query execution time. Experiments were conducted on a virtual machine with a 6 VCPU, 32 GB of main memory, a 9 TB hard disk, Windows Server 2012, and MongoDB 3.
2. Finally, we do not provide any indexes on our data, since the main goal of this work is to compare logical models. We present in Table  1 , the database size of both logical models without and with spatial data. For sf=1 the redundant geometries of the MLD0 model are the responsible of the huge size of the database. Indeed, geometries represent 314. 5 GB of a 320 GB total size. For bigger sf, the SDW size is bigger. Due to the lack of hard disk space, we estimate the size of the SDW generated by MLD0 from sf=10, thus 10, 20, 50 and 100. Therefore, we can conclude that the spatial data redundancy is the main factor of the huge size of the SDW in the MLD0 model. This is not true for the Falling Star model, where since geometries are not redundant, they do not affect considerably the total size of the SDW.