dataesr/scientific-paragraphs-categorization huggingface dataset:
The injected fuel, thanks to the injection velocity and to the high temperature of the combustion chamber, rapidly breakups and evaporates, even if no combustion happens, because of the non-reactive environment. Injection duration is different for the various measurements, but it always overcome 4 ms in order to achieve the quasi-steady period of spray development. Liquid length is measured through high-speed Mie scatter images using a 3% threshold of maximum intensity. For steady liquid penetration the period between 0. 5 and 1. 4 ms is considered  [19]. Furthermore, Rayleigh scatter imaging is used to obtain several contour data for vapour fraction in order to determine both its axial and radial distributions. Data for vapour are available starting from 17. 85 mm after the injection point until 50 mm downstream.
With p<c, the colony experiences negative growth and goes through extinction, whereas with p>c it grows until the maximal size is reached. In our first set of simulations, we examine the growth curve of populations constituted of either only phasic or only non-phasic colonies, in discretized time. In each simulation, the total population is composed by a variable number of colonies and is represented by a vector ݊ ത, which we refer to as the population vector. Each element n i within ݊ ത represents the number of individuals within the i-th colony. The length of ݊ ത represents the number of colonies in the population, and varies with time depending on colony death and reproduction. At each time iteration (identified by the subscript t), the discrete variation of the size of each colony is computed according to the following equation: ∆݊ ,௧ ൌ ݂൫‫‬ ,௧ െ ܿ൯ ݊ ,௧ ൬ 1 െ ݈ ௧ ‫ܮ‬ ൰ where n i,t is the number of individuals in the i-th colony at the t-th time iteration, f is the "foraging" factor varying for phasic (f=1/2) and non-phasic (f=1) populations, p i,t is the food income, c is the foraging cost, l t is the number of colonies at time t, and L is the carrying capacity for the population, expressed as the maximal number of colonies that are able to survive in the environment.
Concerning reproduction, the same rules of our monospecific model apply here. In this set of simulations, we studied the same values of c, w and s considered in the monospecific simulations. For each value of these parameters, we repeated the simulation 1000 times; each simulation consisted of 500 time iterations; we fixed m, the maximal colony size, to 1000, and the carrying capacity L to 300. Concerning the choice of such values, the same considerations made for the previous model apply here. All the simulations were carried out in a Python environment ({van Rossum}, 1995) with the module Numpy  (Walt et al. , 2011). Our scripts are provided in the supplementary electronic material.
In this work, we present the design, analysis and implementation of a decentralized particle filter (DPF) for multiple object tracking (MOT) on a graphics processing unit (GPU). We investigate two variants of the implementation, their advantages and caveats in terms of scaling with larger particle numbers and performance on several datasets. First we compare the precision of our GPU implementation with standard CPU version. Next we compare performance of the GPU variants under different scenarios. The results show the GPU variant leads to a five fold speedup on average (in best cases the speedup reaches a factor of 18) over the CPU variant while keeping similar tracking accuracy and precision.
Moreover, the observation models are often built on complex appearance models, and as a result the trackers have difficulties to operate in real time especially when the number of targets increases. Currently, to the best of our knowledge, the literature is lacking works that showcase graphical processing unit (GPU) to improve performance of multi object tracking (MOT) algorithm. Hence, this paper aims to fill this void by presenting performance comparison and assessment of MOT algorithm running on GPU. The tracking is achieved by a decentralized particle filter with rich target appearance model. We demonstrate that the precision of GPU implementation is comparable to the standard CPU version and the execution time is significantly better -on average five times faster than CPU and on some datasets the improvement is by a factor of 18.
Their analysis showed a possibility of substantial performance gain compared to current desktop computers. With the introduction of CUDA (Compute Unified Device Architecture) the focus shifted to GPGPU. (Chao et al. , 2010 ) offered a design guide on how to create an efficient filter running on GPU. They propose two approaches, FRIM prior editing and localized resampling, in order to reduce global operations and thus improve performance. The approach proposed by  (Hendeby et al. , 2010)  does not use CUDA to achieve GPU computation. Instead, they propose a filter based on OpenGL shading language  (Rost, 2006). Their simulations confirmed that GPU can outperform CPU for larger tasks, while for smaller tasks the overhead of GPU initialization is substantial and thus the CPU is faster for such tasks.
Compute Unified Device Architecture (CUDA) CUDA is a programming interface that uses the parallel architecture of NVIDIA GPUs for general purpose computing  (Nickolls et al. , 2008). The computation in CUDA is expressed in form of a kernels, which are programs written in Single Instruction Multiple Threads (SIMT, which is a generalization of SIMD programming model) language defined by CUDA. The execution of the kernel is done by threads, where all threads execute the same code, but each thread has unique set of indexes to be able to determine on which data it should operate. In CUDA there are two levels of indexes -blocks (groups of threads) and grids (groups of blocks). The main difference between block and grids is that threads in one block can share a memory block, while blocks in mode grid cannot.
While CUDA programming language allows programming constructs that create divergence (typically if-then-else), the physical execution is done in warps in true SIMD fashion. The device typically launches 16 or 32 threads in parallel in one warp and all threads execute the same code. This means that code with two possible ways of execution (one if-then-else block) the GPU first executes the "true" branch and then executes the "false" branch. The memory model consists of 4 parts: registers (private memory for each thread, fastest), shared memory (all threads in one block can access the same segment), constant memory and global memory (accessible by anybody, very slow compared to other memory types). In order to hide global memory latency, GPU is able to very effectively switch between warps. So while one warp is waiting for the data, GPU switches the context to another warp, which can continue its execution.
An efficient CUDA implementation must, apart from direct code conversion, also handle efficient data reading / writing due to memory latency, as little branching as possible and a good ratio of arithmetic calculations versus memory operations to achieve good GPU utilization. While modern GPUs support double precision primitives, the performance of double arithmetic is always worse compared to single precision  (Itu et al. , 2011). In worst case scenario, where the performance of the algorithm is bound by the arithmetic, the performance drop might be up to 1/24 of single precision performance (the actual value depends on the concrete algorithm and GPU used). Due to this possible performance penalty we have used single precision arithmetic in our GPU implementation and we have tested the precision of the results to see if the reduced arithmetic precision has any impact on the results quality.
Evaluation metrics To compare the quality of the results between CPU and GPU implementations, we have utilized the prevalent CLEAR-MOT metrics  (Bernardin and Stiefelhagen, 2008). These metrics are principally based on computation of two quantities: the Multi-Object Tracking Accuracy (MOTA) and the Multi-Object Tracking Precision (MOTP). The MOTA = 1 -(F P + F N + Id sw ), where F P = ∑ t FP t g t quantifies total false positives, F N = ∑ t FN t g t quantifies the total false negatives, and Id sw = ∑ t Id sw ,t g t quantifies total id switches, all divided by the ground truth targets and summed over the entire dataset. The MOTP is the average bounding box overlap between the estimated target position and ground truth annotations over the correctly tracked targets. A tracker estimated rectangular position (noted R T ) is considered a correct track if its overlapping area score, sc = R t ∩G t R t ∪G t , with the ground truth annotation (G T ) is above a given threshold τ, which is usually set to 0.
5. For the performance comparison we have measured total execution time including data preparation before the filtering and also data retrieval after the filtering. This approach penalizes the GPU version due to the need of GPU to CPU data copying for display, but it better reflects real world performance and behavior. The times were measured with millisecond precision using std::chrono class. The experiments were conducted on a PC with Intel Xeon E3-1241@3. 5GHz, 8GB RAM, NVidia Quadro K420 with 1GB VRAM. The OS was Linux 12. 04 LTS with all update available at the time, NVidia binary driver v364. 19, NVidia CUDA 7. 5 and as a compiler we have used nvcc v7. 5. 17 (bundled with CUDA package). All computations have been run ten times to account the stochastic nature of the algorithm.
Test data In order to properly evaluate the performance of the implementations we ran the tests on several datasets with different scene and people settings. We have used a total of 7 datasets (sample images can be seen in Figure  3 ): the CAVIAR 1  EnterExitCross-ingPaths [3(a)] and OneShopOneWait 1 [3(b)] datasets, the ETH 2  Bahnhof [3(c)],  Jelmoli [3(d) ], Sunnyday [3(e)] datasets, TUD 3  Crossing [3(f)] dataset and PETS2009S2L12 4  [3(g)] dataset. As for people detector, we have used several widely used detectors in order to take into account the dynamics of the scene.
HOG-SVM This detector computes local histograms of the gradient orientation on a dense grid and uses linear Support Vector Machine (SVM) as a classifier. The HOG features have shown to be the most discriminant features to date, and in fact, a majority of detectors proposed hence-after make use of HOG or its variant  (Dollár et al. , 2012). Further details can be found in  (Dalal and Triggs, 2005). ACF This is a fast person detector that has shown state-of-the-art performance on various benchmark datasets  (Dollár et al. , 2014). It is based on aggregates (summed over blocks) of features represented as channels and a variant of Boosted classifier. Examples of features channels used include: normalized amplitude of the gradient, the histograms of oriented gradients (HOG, 6 channels) and color channels (LUV).
Execution time vs particle number The performance scaling comparison with different number of particles per tracker can be seen in All three tested variants exhibit almost linear dependency on particle count in all three figures. CPU variant is always the slowest one, even for 20 particles per tracker. For OneShopOneWait dataset the performance for 20 particles per tracker is very close to GPU and BULK variant, but this is because of low tracker count. Due to low tracker count the GPU and BULK variants have almost constant execution time for all particle counts, because the graphic card is not fully utilized. The GPU-BULK variant exhibits best performance in terms of scaling, but due to the fixed cost of data preparation needed it is better suited for scenarios with larger data size. In cases where we have used low particle count per tracker or the scenes contain only small number of tracker the GPU variant is superior.
Global spectral databases In contrast to genomics, there is a lack of metabolite databases with sufficient depth and breadth covering entire metabolomes. There are no databases capable of providing a near comprehensive snapshot of the molecular diversity available. While a number of databases around the globe store and serve spectral data, there is no open and comprehensive resource targeted at the needs of metabolomics. The public repository MassBank (http://www. massbank. jp/en/database. html), which stores mass spectral data, is actively developed and used by members of the metabolomics community. However, it is designed to hold only reference spectra and not experimental raw data. For NMR, a few and sparsely populated repositories provide raw data for individual metabolites, such as the metabolomics collection in BioMagRes-Bank (http://www.
bmrb. wisc. edu/www/resources. shtml)  9. Efficient metabolite identification requires several fundamental resources and developments, which mandate concerted efforts across research groups and countries in Europe and worldwide. In the field, two main types of resources exist: 1. Databases of measurements: Resources such as the Human Metabolome Database (HMDB, http://www. hmdb. ca)  10  , and the Yeast Metabolome Database (YMDB, http://www. ymdb. ca)  10, 11 store MS and NMR measurements of known compounds but also collect and curate published results with the aim to establish specific organism reference metabolomes. One important consideration in this arena is that different confidence levels can be associated with structural identification of metabolites  17  , and standardized annotation schemes for such evidence descriptions are currently emerging  18.
The highest confidence level can only be observed when instrumental data for an authentic chemical standard is matched to the data for the biological samples. However, authentic chemical standards are not available for many metabolites and therefore bioinformatics and chemoinformatics, including through ELIXIR supported resources, are essential to solve this community-wide hurdle. Recently, as one strategy to accelerate the identification of metabolites in biological systems, a task group within the International Metabolomics Society has promoted the idea of characterising model organism metabolomes  19, 20. The philosophy of this task group is to leverage upon the critical mass of knowledge and activity that already exists for model organisms, linking to these other efforts and exploiting resources such as sequenced genomes to predict metabolism (as targets for experimental investigation) using genome-wide metabolic reconstructions or metabolic pathway databases KEGG  12  , BioCyc  13  , and WikiPathways  21.
The task group has set a grand challenge for the community, to identify and map all metabolites onto metabolic pathways, to develop quantitative metabolic models for model organisms, and to relate organism metabolic pathways within the context of evolutionary metabolomics  22. To assist the experimental community in generating and gathering high-quality metabolomics data about biological models, an Implementation Study proposal called "MetabolHomes" has been submitted to ELIXIR as part of the present Metabolomics Use Case, which aims at providing users with a generic data model and the associated software tools for data management, visualisation, and annotation.
Tools and standards registries Since its inception, the Metabolomics community has developed a plethora of computational tools for data analysis (https://goo. gl/Crf2Ye), as well as data and minimum information standards (https://goo. gl/gouSQY). There is a general feeling that it is difficult for the average researcher to navigate both areas. The suggestion here was to contribute to and improve long-term supported registries of tools and standards that help researchers decide which mature, well-tested tools and standards to use for which purpose. There is a need for more metabolomics resources to be appropriately included in Tools and Data Service Registry (tools), and the FAIRsharing registry (standards, databases, repositories and data polices), the two resources part of the ELIXIR platforms".
However, there is a lack of integrated omic databases for most model systems and it is not self-explanatory how a genomicist/proteomicist could integrate his/her data with metabolomics data that refers to the same biological system and vice versa. Additionally, there is a lack of harmonization of the experimental design, sample collection, handling and quenching protocols of metabolomics monitoring, which further increases the challenge of integrated omics analysis. The ELIXIR group proposed that these issues of integrated omic analysis and the standardization of metabolomic data interpretation in this context, could be tested and explored via comparison and analysis of a controllable reference biological system, such as a well-characterized human cell line. Genome scale metabolic networks and metabolic pathway databases contain information both on metabolites and their reactions with corresponding genes and proteins.
Thus, these networks provide valuable context for simultaneous interpretation of metabolomics data and other omics data. However, mapping metabolites in these databases is a heavy workload (see above), since most of databases use specific identifiers for small molecules, where ideally chemical structure mapping should be applied. This is a particularly striking issue with genome-scale metabolic models, as these were initially built for constraint-based computational studies (flux balance analysis and related), where the chemical structure of small molecules plays no role. Because of this, no effort was put into those models to use proper small molecules identifiers, and instead only short and ambiguous names were used for small molecules, making mappings very difficult. Hence, omics data integration was not considered at all in their design and most of these databases (available in SBML format) do not provide standard metabolite identifiers.
Data Platform The Data Platform focuses on sustaining long term Europe's life science data infrastructure by working on guidelines and indicators to improve data resources impact and long-term sustainability. Additionally, platform aims to improve links between curated and non curated data resources and literature. On the data side, metabolite identification requires a) the availability of high-quality curated resources for compound de-replication (the process of finding known chemical compounds in databases based on their spectroscopic and chromatographic fingerprints) as well as b) the establishment of workflows to push data on newly identified metabolites into the existing repositories. For a), the reference layer of the MetaboLights 32 database plays a crucial role and needs to be extended.
Tools Platform The Tools Platform drives access and exploitation of bioinformatics research software by working closely with services and connectors. Additionally, this Platform aims to facilitate the discovery, benchmarking and interoperability of bioinformatics software by focusing on software development, best practices and on strategy for workflows and software containers. Workflow management e-infrastructures such as Workflow4Metabolomics (http://workflow4metabolomics. org/)  34, 35  , PhenoMeNal, and Galaxy-M 36 are key European resources built on the Galaxy environment 37 that simultaneously address the two challenges of 1) high-performance, user-friendly, modular, and reproducible data analysis (needed by the experimental community), and 2) collaborative contributions from the bioinformatics community.
Comprehensive workflows for preprocessing, statistical analysis, and annotation of data from liquid chromatography -MS (LC-MS), direct infusion MS (DIMS), gas chromatography -MS (GC-MS), and NMR technologies can be created, tailored, run, saved, shared, and publicly referenced with digital object identifiers (http://workflow4metabolomics. org/referenced_W4M_histories). A recent questionnaire has shown a need to further develop such tools and workflows, as part Galaxy, that are well supported through community-based training, to further improve the standardisation and automation of data processing and analysis 38. Standardization of compound annotation is critical for such Platforms i) to enable individual modules to communicate between each other and with external resources (e. g. , repositories for raw data, mass spectra, compounds and metabolic networks) and ii) to deliver useful and FAIR data to the end-user.
However, courses for greater levels of hands-on training in the laboratory are focused on training in the laboratory; through the use of video media we can envisage some courses operating via online resources. For training purposes, the Galaxy framework has also shown that it could be an efficient Platform to explain tools, parameters and workflows to life scientists without any skills in scripting (R, Bash, Python). The trainees can focus on their scientific questions regardless the technical aspects and programming language barrier. Since 2014, the Workflow4Metabolomics group (ELIXIR-FR, Metabo-HUB) have conducted three sessions of one week based on their Galaxy instance. For those who wish to use the command line after the training session, the bridge is easy since the parameters within Galaxy are mapped exactly on the native software.
ELIXIR training modules can be classified into three types of trainers: 1) Life Scientist (TrR): "Bring Your Own Data" training addressed to the experimentental community optimally promote good practices for using software and critically interpreting the results, and provide feedback about specific training needs. As an example, during the Workflow4Experimenters (ELIXIR-FR, MetaboHUB) oneweek courses (W4E) (http://workflow4metabolomics. org/events), participants learn to analyze their own MS or NMR datasets by using the Workflow4Metabolomics Platform. Morning sessions are dedicated to methodology and tools and afternoon sessions are devoted to tutoring. Such training offers unique opportunities to discuss the designs, methods, and tools for comprehensive and rigorous data preprocessing, statistical analysis, and annotation.
2) Communities of Developers (TrD): to enrich the tools and compute Platforms based on good practices guidance. As an example, the ELIXIR-EXCELERATE and IFB (ELIXIR-FR) European Galaxy Developer Workshop (EGDW, https://www. elixir-europe. org/events/elixir-excelerate-and-ifb-europeangalaxy-developer-workshop), hosted in Strasbourg, aimed to teach the best-practices about the tool integration and advanced features like the Galaxy API, visualisation and administration (high performance computing (HPC), Docker). 3) Trainers expert (TrT): Train the trainers program with the best strategies in Learning principles and didactic strategies for delivering bioinformatics in the most effective way.
Significant synergies between the privacy and ethics work package in PhenoMeNal and the parties working on the human data Use Case are obvious. As one of the best established molecular phenotypes, metabolomics is already widely used for the genotype-phenotype analysis of crops and in tree species, providing an immediate interplay with the Plant Science Use Case which is also supported by the common of use of the ISA experimental metadata framework. A rich corpus of work exists on the metabolomics of marine organisms where communities of, for example, marine sponges and marine microorganisms produce pharmacologically active polyketides with diverse chemical structures, which are investigated based on genomic and macroeconomic data of these communities. In all those application scenarios, the mapping of spectral features in metabolomics data to identified chemical compounds (metabolites) and thereby to molecular pathways is crucial for the understanding of the biochemistry underlying the Use Case in question.