dataesr/scientific-paragraphs-categorization huggingface dataset:
Comparison of the SOM and MBCluster Methods The RNA-seq data of Pycco 310 was used for the comparison. Gene clusters were generated with the R package MBCluster. Seq  (Si et al. , 2014). The number of partitions (k = 320) was used to initialize the cluster centroids with the negative binomial model; this number was chosen to match the number of the gene clusters used for SOMs with this fungal strain. The default function of the package, Expectation-Maximization method with negative binomial model was used for clustering. The global mean transcription of the individual clusters was calculated from the results of SOM and MBCluster. The total count of proteins was calculated for the individual clusters. Spearman's rank correlation coefficients of the transcriptomic and the secretomic profiles were used as an indicator for the biological relevance of the constructed models.
INTRODUCTION Virtual cities are an ever more growing research topic, with a great variety of applications for urban planning, routing, simulation or cultural heritage  (Biljecki et al. , 2015). Technical challenges still remain, especially regarding the high amount of data in a virtual city model. To allow the best user experience, this data needs to be streamed. While there exist efficient methods for the progressive streaming of raster data, few satisfying solutions exist for vectorial data. Most of these solutions require a long preprocessing stage, where the data is organised, simplified or generalised and often duplicated. The result is generally a new dataset suitable only for visualisation that needs to be recomputed whenever the original data is modified. An alternative to the costly generalisation of the geometry is the transmission of a subset of the data.
For this purpose, having a single model for both the visualisation and the storage of the data seems convenient. Furthermore, a unified model removes the need to duplicate the data (base model and visualisation model). With datasets covering larger and larger areas, exceeding the city scale, as well as existing in multiple temporal versions  (Chaturvedi et al. , 2015a) , storage may well become an issue in the future. The contributions of our paper are as follows: • an efficient hierarchical structure for vectorial data allowing: progressive loading of data based on a weight function dynamic addition and removal of data compatible with rising exchange formats such as 3Dtiles (3D Tiles -Specification for streaming massive heterogeneous 3D geospatial datasets, 2016) • an architecture for visualising data from a geospatial database featuring: fast deployment original storage format, suitable for 3D analysis The paper is organised as follows: we will review the state of the art in the fields of web 3D and virtual cities, then we will describe our data model and, in the next section, the detailed algorithms for creating and updating our data structure as well as ways of accessing the data.
(Suárez et al. , 2015)  presents a globe application, where the use of a quadtree enables constant resource usage. However, this only works for regularly meshed tiles, where each tile has the same number of triangles. Furthermore, vectorial data stored in quadtrees often overstep the boundary of the tiles, making them somewhat complex to manage. In geospatial databases, r-trees  (Guttman, 1984)  are often used to index the data. While it offers quick access to the features and solves the problem of overstepping features, it is not suitable for progressive streaming: all the features are stored at the same depth, in the leaves of the tree (there is no hierarchy of features), and features of the same leaf tile are always close to one another, meaning that a progressive loading based on this structure will be non-uniform and chunky, similarly to a grid.
DATA MODEL In this section, we will present our solution for storing and editing a geospatial dataset. A description of the data structure is presented in figure 1. This dataset S is defined as a collection of features F. A feature F i is a 3D geometry to which is assigned a number of semantic attributes Ai. For instance, a feature could be a building with attributes such as height, energy consumption, etc. A feature could also be a bridge with its name and date of construction as attributes. Our goal is to retrieve data in chucks of similar sizes. Additionally, we wish to retrieve the most important data first. Since a city has variable density, we either need an irregular organisation of the data or a hierarchical data struture. In our case, hierarchical data structures are preferable since they allow the ranking of data.
Therefore, we store our data in a Bounding Box Hierarchy (BBH): a tree where each node has a bounding box which strictly encloses all the underlying features (see figure  2 ). This is an advantage compared to the usual structures used for tiling cities (quadtrees or regular grids), where some features may overstep their tile's boundaries and causes imprecisions in the loading of its features. In this paper, we use bounding boxes since our data has almost no verticality. In some cases, Bounding Volume Hierarchies (BVH) might be a better choice. The presented methods work with both BBH and BVH with virtually no change. Choosing a hierarchical data structure allows us to easily enable progressive loading: by storing features in the nodes of each level of the tree, the data will automatically be loaded progressively, starting from the topmost nodes down to the leaves.
This is a classic knapsack problem. We use a very simple approach, where as soon as a feature overfills a node, it is considered full. This solution offers satisfying results, further optimisation is left for future works. Bounding box hierarchies (or bounding volume hierarchies) are a fairly common data model. Some exchange formats, most notably AGI's 3D-tiles (3D Tiles -Specification for streaming massive heterogeneous 3D geospatial datasets, 2016), already support these kind of structures, assuring compatibility with standardcompliant web clients. The specificity of our method, namely the way we order the features inside the hierarchy, takes place on the server and is completely transparent for the client.
Accessing the Data We recommend storing the features in a spatial database on the server. The features are indexed by the identifier of the tile to which they belong. This allows the server to select very quickly the features that a client needs, as the client sends requests for specific tiles. The client accesses the data by querying the tiles that are inside its field of view and match its desired precision. For this task, the client must know in advance the bounding box and the level of detail of each tile. We call refinement scheme the way each tile is subdivided into its child tiles, that is the number of child tiles and their bounding boxes. There are two main ways of managing the transmission of the refinement scheme. The refinement scheme of the whole structure can be sent on initialisation of the application, solving the issue once and for all.
Creating a weight function In this section, we will define guidelines for creating and combining weight functions. A weight function assigns to a feature a weight, represented as a floating point number between 0 and 1. The higher the weight, the more importance is attached to the feature. F 7 ! W (F ), R ! [0. 1] Surface Weight A classification based on the 2D footprint of a building allows the largest buildings to be displayed first. It is a pertinent choice for visualisation applications since these buildings are big enough to be seen from afar and can be used as landmarks for orientation purposes. The surface weight function is defined as a function which returns 0 for a null surface and 1 for the surface of the largest building of the dataset. Cities often have a few buildings that are very large in comparison to the others.
Implementation and performance All the following results were obtained on an Intel c Core TM i5-4590 CPU @ 3. 3GHz x 4, Nvidia GeForce GTX 970. We implemented the algorithms for creating and manipulating our data structure in Python, using psycopg2 (psycopg2 -Python-PostgreSQL Database Adapter, 2016) to interact with a postgres database (PosgreSQL -The world's most advanced open source database. , 2016). We use the postGIS extension to handle geospatial data (PostGIS -Spatial and Geographic Objects for  Post-greSQL, 2016). We tested our algorithms on a dataset of close to 30,000 features of the city of Lyon and a second dataset of 80,000 features of the city Montréal. Results for Montréal are written in parentheses. The initial state of the database for our study was a postGIS database filled with the aforementioned data indexed by gid.
We chose a weight function that returns the area of the footprint of the building and a maximum of 50 features per tile. It took 6. 1 (11. 4) seconds to create our data structure. 1. 3 (1. 9) seconds were spent fetching the data from the database and computing the weight of each feature, 4. 6 (8. 9) seconds were spent updating the database with a new tile index. The remaining 0. 2 (0. 6) second was used to organise the data inside our structure. Adding and removing features from the database and updating the data structure is also fast. For the same database, which had 1165 tiles and up to 5 depth levels, each of these operations took barely more than 10 milliseconds (see.
Test client We use an Apache2 server combined with Python scripts to manage the server-side processes. Client-side, we visualise the data using Cesium (Cesium -We-bGL Virtual Globe and Map Engine, 2016). Our Javascript implementation features the progressive loading of buildings as intended by our data structure. Figure  8 : Screenshot of our web application based on Cesium. Buildings in red belong to level 0 tiles, those in orange to level 1 tiles, those in yellow to level 2 tiles and those in green to level 3 tiles. Figure  8  shows the result of the classification of the dataset's features in the web application. We can clearly see that the buildings with the biggest 2D footprints are assigned to the highest level of the hierarchy and are therefore displayed first. Figure  9  is an example of this behaviour: the greater the distance to the camera, the fewer tiles are loaded; only the buildings with the highest weight remain.
In the experiments, we first evaluate the performance of the proposed implementation and the optimizations applied during the synthesis process. Next, two reference implementations are made by using MATLAB and C for a comparison evaluation. Finally, the development cycles are studied for development productivity analysis. The results demonstrate that the applied design flow is an effective method to facilitate the implementation on FPGA. The optimizations made during the synthesis significantly accelerate the designs by parallelizing the operations and simplifying the control flow of the generated register-transfer level implementation. According to the comparison experiments, the proposed implementation achieves a speedup of over 10× compared to the CPUs. The remainder of this paper is organized as follows: Section 2 introduces briefly the background of this research; Section 3 describes the selected segmentation algorithm for very high resolution satellite images; Section 4 presents the development framework specially designed for the algorithm of this paper; Section 5 presents the prototype of the target algorithm and its optimized implementation; Section 6 analyzes the experiment procedure and the results; finally, a conclusion is given in Section 7.
Design Flow Description In order to achieve useful and competitiveness models, tools and methodologies are the fundamental elements of any design flow for industrial or academic embedded systems. These methodologies and tools are usually properly joined up according to a design space exploration framework in order to facilitate the discovery, the management and the evaluation of the design alternatives prior to being implemented. In our case, the target algorithm is hard to specify by using conventional hardware description languages, i. e. , Verilog or VHDL. Handling the code of such an application would be far from easy due to the fact that register-level languages requires a high code density for low-level hardware configuration or behavior specification. Therefore, finding an effective design flow will help for reducing the complexity of the design and for increasing its maintainability, as well.
Recently, numerous research works pointed out that high-level synthesis is an effective method to reduce the complexity of FPGA designs. For example, Wakabayashi Kazutoshi  [30]  shows that a 1 M-gate (Gate count refers to the quantity of the NAND equivalent gate in ASIC. This value is usually used to estimate the complexity of the design. ) design usually requires about 300 K lines register-transfer level code, while the code density can be easily reduced by 7 -10× when moved to high-level specification in C-like languages, resulting in a much reduced design complexity. Villarreal et al. [31]  present a Riverside Optimizing Compiler for Configurable Circuits (ROCCC) that achieves an average improvement of 15% in terms of the metrics of lines of code and programming time over hand-written VHDL in evaluation experiments.
Consequently, we first propose a design flow and its tool kits, which incorporate the high-level synthesis technique for its advantages of high development productivity. The proposed approach has the following properties: (a) to allow the exploration in different development environments and hardware. (b) to handle the algorithm analysis and top level simulation in a very high level language, MATLAB. (c) to handle the algorithm prototype written in C without FPGA expertise or even not for FPGAs, but the platforms of other types. (d) to optimize the performances of the designs with the hardware constrains, such as frequency or area of the target device. (e) to automatically generate the desired RTL implementation in a short time, rather than hours or even days. (f) to be capable of being implemented by using the currently-available electronic design automation tools.
This is important for industrial designs, because it can effectively reduce the R&D cost by helping with fast building the desired development platforms and avoiding the additional cost for the new tool kits. Figure  2  shows the proposed design flow. Considering most designs begin with the algorithm analysis, which requires a very high level environment to facilitate the descriptions of mathematical operations and the simulations of the model, we select MATLAB as the favorite user-level design environment for its advantages in the terms of vector processing and powerful built-in image processing tools. Once the algorithm is verified, we can start to prototype the algorithm for FPGA synthesis. Thanks to the HLS technique, the algorithm behavior can be prototyped in the C environment and verified by using the common C compilers.
It should be noted that the original prototype has to be debugged depending on the input code constraints of high-level synthesis due to the special architecture of FPGAs compared to general-purposed processors. Before running the synthesis, some optimizations can be made to improve the performances of the design (the optimization strategies applied in this paper will be discussed later). The C-to-RTL conversion of the development is automated via a high-level synthesis process. Finally, the generated code is evaluated by using a hardware description language estimator to determine whether it satisfies the performance requirements. If satisfied, the generated implementation is then exported as an IP core to the test bench for top level simulation; otherwise, the process of code optimization is iterated again.
We implement the development platform by using five different design tools within Ubuntu, including MATLAB, Gedit, ICC, AutoELS and System Generator (see Table  1 ), which can benefit both the development productivity and design performance according to their different development environment. In our work, MATLAB and System Generator are respectively used for algorithm analysis and top level simulation of the generated kernel for their advantages of high-level abstraction. Meanwhile, Gedit is selected as the code editor for prototyping and optimizing in a C environment, while ICC for simulating the source code by using general-purposed processors. The gap between C and register-level languages is bridged via AutoELS, which is one of the leading high-level synthesis tools for its abilities to produce high quality register-level languages  [32].
Within this design flow, all of the manual, necessary cycles, including algorithm analysis, prototyping, debug, optimizing and top level simulation, are made in a high-abstraction environment, while the C-to-RTL conversion is automated by incorporating the HLS process. This is an effective approach to free the users from the boring work of hardware configuration required at the low abstraction level. Moreover, the proposed approach allows a design space exploration in different environments (MATLAB, C and System Generator) and processors (CPU, FPGA and GPU), which provides a large number of opportunities to find the potential design solutions compared to the design flows targeted to only a single type of environment or device.
Implementation and Optimization This section describes the implementation and optimization issues of the proposed very high resolution image segmentation design. Algorithm 1 shows the pseudocode of the original version of the target algorithm in Kintex7_fpv6 from Xilinx. This implementation is first made and functionally verified depending on the algorithm analysis results presented in Section 3 without any hardware level optimizations, then debugged according to the HLS source code constraints for the C-to-RTL conversion. end for 20: end for Despite the benefits of high quality designs for small kernels, the performances of the HLS-generated RTLs are still far away from the manual designs for complex applications, even by using the most advanced tool, such as AutoELS. For example, in the cases of Rupnow et al.
Loop Manipulation In HLS, the control logic of the source code is first analyzed and extracted as an FSM. Next, the operations are assigned to the corresponding states of the control behavior to perform the control-and-datapath behavior. During this process, either the sequences of operations or the loop bodies are represented as a single state, i. e. , Lines 5 or 9 for the operation sequence and Lines 3, 7 or 11 for the loop body in Algorithm 1, and the operation scheduling is confined by the state scope. In this paper, applying loop manipulation onto the proposed designs is motivated by two reasons: (1) reducing the running-cost due to the state transit controls by reducing the state numbers; and (2) helping HLS to discovering more instruction-level parallelism opportunities by expanding the scheduling scopes that are confined by states.
According to our tests, the parallelism underlying the single equations cannot be effectively exposed by the data flow analysis performed by AutoELS. Therefore, in the symbol expression manipulation, we transform the long expressions in the design into short ones to help HLS to discover more potential parallelizing opportunities. Figure  5  illustrates the code of the function pow4_hls() before and after the symbol expression transformation, as well as its scheduling graph. Obviously, the segmented expressions lead to a more efficient implementation. We respectively apply this approach to the descriptions of Equations (  26 )-(  29 ) and achieve speedups from 24. 3% up to 60%.
Loop Unwinding Loop unwinding is a loop-level parallelism form of optimization widely used in parallel computing. It unwinds first the loops in the source code and next pipelines the body operations for acceleration if their iterations are independent. By using this transformation, engineers can multiply the running speed of the design up to several hundred times. Meanwhile, it should be noted that this method is seriously constrained by the hardware resources of the target device. The area of LLP optimized version A ll p can be expressed as follows: A ll p = K ∑ k=1 (DOP k (n) × a k ) + A control ( 30 ) where K is the number of the operation types, DOP k (n) is the degree of parallelism of the k-th operation with the unrolling times of n, a k is the area of the k-th component and A control is the area of the control circuit.
Experiment In order to obtain an unbiased conclusion, we compare the proposed implementation with its original RTL implementation and two CPU implementations. These reference implementations are developed from the same pseudocode shown in Algorithm 1. For the sake of fairness, all of the reference implementations are specified within the high-abstraction environments MATLAB or C/C++. Table  2  details their specifications. cpu_m is the original implementation after the algorithm analysis; cpu_c is its C/C++ version; fpga_hls_ori is the RTL generated from the source code without any optimization; and fpga_hls_opt is the proposed one of this paper. Since the algorithm is complex, a large FPGA platform, Kintex 7, is selected for evaluation. In this section, the user-controlled parameters in the algorithm are defined first.
e. , the convex ices in Figure  10a  or the constructions on shore in Figure  10b. (e) (f) (e) (f) On the other hand, it is seen as well that the segmentation results of the different implementations are highly similar. The similarities between the proposed and reference implementations are quantitatively evaluated by using the corr2() function within MATLAB and shown in Table  4. This demonstrates that the selected HLS tools is effective to automate the C-to-RTL transplantation with an acceptable difference, and the optimizations made on the fpga_hls_ori would not effect the functions of the design.
Performance Comparison This experiment estimates the overall running-time of the proposed and reference implementations in the real world. The scope of this measurement covers the necessary computations and memory access operations. For CPU implementations, specific storage space is allocated in the memory for the input and output images, whereas the external RAM is used for the implementations of FPGA. The results of this experiment are compared in Figure  11. First of all, we can see that cpu_c speeds up the design by around 2. 69× related to cpu_m. Unlike MATLAB, C/C++ allows design optimization in a lower abstraction level, and a series of compiling tools are developed to automate this process. In this implementation, we compile the source code by using the Intel C++ Compiler. This compiler is able to analyze and vectorize the data flow in order to benefit from Streaming SIMD Extension instructions.
It also optimizes the loops by helping OpenMP (Open Multi-Processing) or auto-vectorization to make effective use of caches and memory access, as well  [38]. In the compilation process, the "maximize speed" mode is used to schedule the algorithm automatically. This compiler option can create the fastest code in the majority of cases by default. The optimizations made by the compiler include generating intrinsic functions, omitting frame pointer, function inline, etc. Therefore, it achieves a significant running time acceleration. Next, the original RTL of the design fpga_hls_ori achieves a speedup of 1. 415× related to cpu_m. However, it is also observed that fpga_hls_ori is 1. 9× slower than cpu_c. The generated RTL is substantially an FSM coming from the code and data flow graph of the source code, so its operation scheduling has to satisfy the corresponding time constraints.