dataesr/scientific-paragraphs-categorization huggingface dataset:
Results: We have devised a bioinformatics pipeline to call and type SNPs from RNAseq reads and applied it to P. nigra transcriptomic data. The accuracy of the resulting RNAseq-based SNP calling and typing has been evaluated by (i) comparing their position and alleles to those previously reported in candidate genes, (ii) assessing their genotyping accuracy with respect to a previously available SNP chip and (iii) evaluating their inter-annual repeatability. We found that a combination of several callers yields a good compromise between the number of variants type and the accuracy of genotyping. We further used the resulting genotypic data to carry out basic genetic analyses whose results confirm the quality of the RNAseq-based SNP dataset. Conclusions: We demonstrated the potential and accuracy of RNAseq as an efficient way to genotype SNPs in P.
Validation of the SNPs detected and genotype calls A first validation of the SNPs detected and genotyped by each or by combinations of the callers has been done through a comparison of the genotype calls with those previously obtained with a 12k Illumina Infinium Bead-Chip array  [1]. Full details of SNP discovery and selection, array development and data filtering criteria are given in Faivre-Rampant et al. [1]. In brief, 852 unrelated P. nigra accessions (including our 12 genotypes) were successfully genotyped with this genotyping array, yielding 7903 SNPs for the validation of genotype calls. For each of the 12 genotypes, genotyping accuracy was calculated as the percentage of similarity between chip genotype and RNAseq genotype at the common positions. A second validation consisted in comparing the SNPs detected with those previously identified within 5 candidate genes through Sanger and Next-Generation sequencing (CAD4, HCT1, C3H3, CCR7, and 4CL3;  [3, 4] ).
The usefulness and relevance of the resulting SNPs for basic genetic studies were further assessed as another form of validation. Minor Allele Frequency (MAF) was calculated with VCFtools 0. 1. 15 [38]. Genome-wide distribution of SNPs was calculated based on a 100-kb window with custom R scripts  [39]. SNP density within a 100-kb window was further correlated with the sum of the expression of the genes located in the same window. The SNPs have also been annotated using Annovar (version 2017Jul16)  [40]. We further tested whether the gene models (with at least 5 SNPs) displayed any enrichment in Gene Ontology (GO) terms using Arabidopsis thaliana annotation with the R package topReviGO  [41]. Finally, population structure was described using a hierarchical ascendant clustering on a distance matrix estimated as d = 1 -IBS, where IBS is the identity by state matrix between genotypes computed with PLINK 1.
"FreeBayes" and "gVCF_GATK" were always below the line and thus appeared to be the less accurate with respect to the number of variants detected. "GATK" and the combination of 4 callers were always very close to the line and thus could be seen as intermediary performing calling methods. Finally, "Mpileup" and the combination of 3 callers were always above the line, suggesting that they performed best. Of note "3CallersConsensus-anyNA" was the most distant modality above the line, underlining the strength of this approach for detecting and genotyping variants in our dataset. For further analyses and validations, we decided to focus on the set of SNPs that gave the highest number of SNPs with at least 98% of accuracy, i. e. the consensus from 3 callers with no missing data (modality "3CallersConsensus-noNA").
Discussion We have successfully built a pipeline from multiple bioinformatics tools for detecting and typing several ). "Coverage" in red refers to the mean depth at each position among the 12 individuals; "Frag. Marroni" and "SNP Marroni" in blue refer to sequenced fragments and SNPs discovered and typed in  [3, 4] ; "SNP RNA-seq" in green refers to SNPs discovered and typed in the present study with the modality "3CallersConsensus-noNA". Point symbol size for each SNP is proportional to its MAF across the 12 individuals hundred thousand SNPs from RNAseq data. Genotyping accuracy of the resulting SNPs has been evaluated by (i) a comparison with genotyping data previously obtained with a SNP array  [1]  and (ii) an interannual validation. The high accuracy (around 95%) underlined the quality of the genotypic dataset obtained with our pipeline.
The gain was mainly due to the production of consensus genotype calls from the different callers, especially when they did not all agree. This opens the choice between various options along the accuracy amount trade-off, which could further be picked depending on the objectives of downstream analyses. For instance, if one wishes to obtain the largest number of SNPs within its dataset for carrying out a GWAS, it may be a good idea to use the combination of 3 callers with missing data allowed and then to impute the missing data with a dedicated tool which make use of linkage disequilibrium between neighbouring SNPs for the imputation  [45]. If one wants to only use 1 caller, we recommend the use of "Mpileup", as it is the only one that produced a data set at the equilibrium between quantity and quality of SNPs.
These polymorphisms could also be valuable for species determination and for studying interspecific hybridization  [46]. We sampled our RNA from two tissues, young differentiating xylem and cambium, because our research focuses on wood production. Combining information from two tissues has likely increased the number of genes covered by reads and consequently by SNPs compared to what would have been obtained when considering a single tissue. Using this strategy, we could obtain a genotyping dataset with almost half of the gene models of P. trichocarpa covered by at least 5 SNPs. Morevover, the GO enrichment analysis suggested that sampling did not introduce a strong bias into the representativeness of functional categories that were effectively captured by the RNAseq experiment. One strategy to increase the genomic coverage could be to combine RNA from multiple tissues but this would have a cost in term of sequencing.
The importance of synergy with industry lies in the possibility of experimental validation of the work research results. With Software-Defined Radio (SDR) platforms, it is possible to implement a physical layer and to have tests with hardware in a real environment. In this paper, we investigate the validation of an impulsive noise resistant physical layer based on Orthogonal Frequency Division Multiplexing (OFDM) and an interesting concatenation of forward error correcting codes: Rank metric Code (RC) and Convolutional Code (CC). We fully design and implement a new block namely RC Encoder + WiFi Mapper in GNU Radio, which acts as a forward error correcting code to mitigate impulsive noise occurring in substations. After showing by simulations that using this coding scheme is very efficient in mitigating the bursty nature of impulsive noise, we then confirm that the same performance is maintained even with various impulsive voltages and experimental scenarios, which confirms the high performance of the proposed approach.
Thus, with SDRs, most of the radio functionality and signal processing are implemented in software that runs on a computer, and the only task of the hardware is taking care of functions, such as transmissions and reception of the signal  [15]. We now propose a combined analysis and experimental validation of the best coding schemes with an appropriate OFDM signal. The objective is to come up with an optimized overall physical layer to ensure better communication in substations. For this purpose, we use the GNU's Not Unix Radio (GNU Radio) platform, which is presently the open-source reference apparatus for academic work and wireless research  [15] [16] [17] [18] [19]  allowing the researcher to implement signal processing blocks with no additional hardware requirements. We implement a new block namely "RC Encoder + WiFi Mapper" to perform error correction.
It is based on the implementation of gr-ieee 802. 11 proposed by Bloessl et al. [20, 21]. The main contributions of this paper are summarized as follows: i Implementation of a new block performing forward error correction code based on the RC code and convolutional encoding in GNU Radio. ii Setup design and impulsive noise measurements in a controlled laboratory condition: this is a new method using the GNU Radio instead of an oscilloscope as proposed in other laboratory tests. iii Over the air experiments in an impulsive noise environment in a laboratory: several scenarios are made up including Line-Of-Sight (LOS) and Non-Line-Of-Sight (NLOS) situations by also considering the impulsive noise level, the distance between the emitter, the receiver and the source. The rest of this paper is organized as follows.
The Transmitter The structure of the transmitter is a constituent of gr-ieee 802. 11. The difference between the recent implementation of Bloessl et al. is the new block called "RC Encoder + WiFi Mapper", otherwise the rest of the blocks remains the same. RC Encoder + WiFi Mapper implementation: The novelty in this structure is the new block that is created for RC encoding and CC encoding. First, we recover the old implementation of gr-ieee 802. 11. Following the steps of the building, which can be found in [27], we create a new block by using gr-modtool add and the different arguments linked to the blocks as depicted in Figure  2. The various parameters associated with this block are also identified: • ninput corresponds to the data from the Medium Access Layer (MAC). They can be in a message or a bit format.
The Receiver The receiver part of the IEEE 802. 11 physical layer is designed to receive and demodulate OFDM signals. As described in  [21] , the OFDM receiver consists of a frame detection part, which exploits the short cyclic preamble repeated 10 times at the start of a frame. The frame is then aligned, equalized and decoded into the MAC information needed for proper delivery. NB: Since we evaluate performance over the air, the transmitter and the receiver used are interfaced with USRP radios. At the receiver side, recall that the last block was the decoding of the frame. However, this decoding is only performed by the Viterbi decoder. After that, we use Wireshark connector to save the information and performs MATLAB processing for the haul decoding of the rank metric.
Average Delay In this section, we compute the average delay versus the voltage for the overall situations. With Wireshark capture files, we have the information about the delta time from the previously captured frame and the time reference since the first frame. The average delay defines the average sum of the difference delay of each data packet received by the sink and the time the source sends a data packet. It is calculated as follows: A d = ∑ N P i=1 (T ri -T ei ) N P (7) where T ri is the time when a packet i is received by the sink, T ei the time when a packet i is sent by the source and N P corresponds to the total number of the received packets. In this case, we limit N P to 100. The obtained results are depicted in Figure  7. The results for LOS configurations are in Figure  7a. As can be seen, the average delay increases with the distance.
Comparison between Simulations and Measurements In this section, we examine the validity of our proposed physical layer. In  [13] , we performed simulations, and in this paper, we have evaluated the performances empirically in a controlled laboratory. To validate or reject the results, we first set the difference between the simulation results and the empirical ones. Since in our experiments, we have evaluated two types of distances and four voltages, we consider the BER for LOS as the mean of all configurations, and the same procedure is applied for the NLOS situation. The results are presented in Table  7. After that, a Kolmogorov-Smirnov (K-S) test is done using the kstest2 function of MATLAB. The two-sample K-S test is a non-parametric hypothesis test that evaluates the difference between the distributions of the two sample data vectors over the range of x in each dataset.
An important prerequisite for the simulation-based assessment of energy systems at urban scale is the availability of high-quality, well-formatted and semantically structured data. Unfortunately, best practices and state-of-the-art approaches for urban data modelling are hardly applied in the context of energy-related simulations, such that data management and data access often become tedious and cumbersome tasks. This paper presents the so-called Simulation Package, i. e. , a data model extending the 3D City Database for CityGML, and its derived data access layer, both aiming to bridge this gap between semantic 3D city modelling and simulation in the context of urban energy systems. The feasibility of this approach is demonstrated with the help of a concrete example, where the proposed extension has been implemented and integrated into a simulation toolchain.
Consequently, the logical next step is a persistency schema for this type of information that integrates with the CityGML data model and its database implementation. The Simulation Package represents therefore a first step towards linking semantic 3D city modelling and multi-domain co-simulation for urban energy modelling at urban scale. The UML diagram of the Simulation Package is presented in Figure  1. The structure of the package specifically targets co-simulation setups. At the same time, the design aims to be as generic as possible, enabling the application of the Simulation Package to a large variety of simulations tools and co-simulation environments. To this end, the following classes have been defined: Instances of class Simulation are -from a hierarchical point of view -the top-level objects describing a co-simulation setup.
Information about the associated simulation model (e. g. , name or parameters) can be specified as generic attributes (through class GenericParameter). Furthermore, instances can be linked with CityGML objects derived from class CityObject, which allows to link them to domain-specific semantic data of a city model (useful, for instance, for automated model creation or validation). A node object can represent a template node (i. e. , attribute isTemplate is TRUE), or be itself derived from a parent template node. In the latter case, the additional relation derivesFrom is used. The AbstractPort class is an abstract class that is implemented by InputPort and OutputPort. Instances of classes InputPort and OutputPort represent, respectively, the input and output variables of a simulation node used by a co-simulation tool to send/retrieve information to/from the associated simulator.
Implementation as extension of the 3DCityDB The 3D City Database or, in short, 3DCityDB  (Yao et al. , 2018)  represents the reference implementation as database schema of the CityGML data model. It comes with a number of open-source tools that help with import and export operations of CityGML data. Initial work has been carried out recently to extend the 3DCityDB and add support for any ADEs  (Yao and Kolbe, 2017) , with concrete examples of implementations for the Energy ADE  (Agugiaro and Holcik, 2017) , the Utility Network ADE  (Boates et al. , 2018 , Den Duijn et al. , 2018)  and the Scenario ADE  (Schüler et al. , 2018). The 3DCityDB Simulation Package builds on top of the abovementioned "extended" 3DCityDB and is currently implemented for PostgreSQL only. The overall goal of this extension is to facilitate direct connection and usage of the 3DCityDB relational database by users and applications programmers.
Besides the database schema, the 3DCityDB Simulation Package is shipped with a set of stored procedures that are automatically installed during the setup and that, conceptually, reflect the logic of the analogous ones shipped with the "standard" 3DCityDB. All database objects are stored within an instance of the 3DCityDB, and are all contained in a schema called sim pkg. All software resources, the accompanying documentation and a small test dataset are available as open-source on GitHub (Agugiaro, G. and the 3DCityDB Development Team, 2018).
CASE STUDY AND IMPLEMENTATION This section provides a concrete example for the application of the Simulation Package presented in the previous section, demonstrating how the data model can be applied to a specific co-simulation tool. As different co-simulation tools employ different ways of semantically representing co-simulation graphs, this example is not representative for the entirety of co-simulation tools. However, the example illustrates the mapping of the Simulation Package's data model to a co-simulation tool's specific representation of a cosimulation graph, showcasing the applicability and flexibility of the Simulation Package design. Furthermore, this section gives an overview about the implementation of a data access layer (DAL), which serves in the example as the actual interface between the database instance and the co-simulation tool.
The IntegrCiTy co-simulation toolchain The IntegrCiTy project (IntegrCiTy Project Team, 2018) focuses on the development and implementation of an integrated decisionsupport environment for city planners and energy providers to improve efficiency and resilience of energy supply infrastructures. An important asset in this decision support environment is a cosimulation toolchain, which allows to perform very detailed technical assessments of proposed changes and extensions of energy supply infrastructure. The core of the co-simulation toolchain is the OBNL software package, the OBvious Node Link co-simulator (OBNL Development Team, 2018). OBNL is an open-source Python package that provides a light-weight implementation of a co-simulation orchestrator for the synchronization of other simulators and the data exchange between them.
OBNL has been specifically designed to work with Docker (Docker, Inc. , 2018), which allows to package simulators and implemented models into executable containers. From a user perspective, setting up a co-simulation in the IntegrCiTy toolchain is reduced to defining the co-simulation graph, whose information is subsequently used to deploy the containerized applications and execute the co-simulation with the help of the functionality provided by OBNL. To facilitate the creation of co-simulation graphs for urban multi-Figure  2. Overview of the relation between meta-models, models and nodes in the IntegrCiTy co-simulation toolchain. energy system simulations, an extended concept for representing simulators and models has been developed on top of OBNL's generic notion of nodes and links. This enables a semantic representation of individual parts of the co-simulation setup, offering the user the advantages discussed in Section 1.
Mapping the IntegrCiTy co-simulation graph to the Simulation Package The representation of co-simulation setups in the IntegrCiTy toolchain cannot be mapped one-to-one to the scheme provided by the Simulation Package for two reasons: • Semantic representation: IntegrCiTy's notion of meta-modmodels and nodes is more complex the concept provided by the Simulation which only provides the classes Node and SimulationTool to represent the edges of a co-simulation graph. Specific parameterization: OBNL's deployment certain parameters (e. g. , to Docker), which are too specific be as of the general Simulation scheme. However, the design of the Simulation Package schema is rich and generic to allow an unambiguous mapping to IntegrCiTy's representation of co-simulation graphs. Specifically, the Simulation Package's concept of template nodes and generic parameters can be used to establish this mapping.
The IntegrCiTy data access layer Figure  4  visualizes the concept of the data access layer (DAL) developed for the IntegrCiTy toolchain  (DBLayer Development Team, 2018). The goal is to bridge the gap between semantic 3D city models based on CityGML and technical assessments of multidomain urban energy systems based on co-simulation. In this concrete instance, this is done by linking the extended 3DCityDB (including the Simulation Package) and the tools developed for the IntegrCiTy project. The DAL implementation relies on state-of-the-art software packages provided by Python and several new developments for the extended 3DCityDB (as described in Section 2. 2): • The DAL is based on functionality provided by the SQLAlchemy software package  (SQLAlchemy Development Team, 2018). Apart from a toolkit to interact with SQL-based databases, it also offers a so-called Object Relational Mapper (ORM).
This ORM presents a method of associating user-defined Python classes with database tables, and instances of those classes (objects) with rows in their corresponding tables. This mapping is done at runtime using metainformation from the database, which means that changes in the database scheme are automatically reflected in the DAL. • The extended 3DCityDB and the Simulation Package come with functions for inserting/deleting objects to/from the database. Thanks to SQLAlchemy, these SQL functions can be easily mapped to Python functions, enabling a user-friendly interaction with the database as needed for IntegrCiTy workflows. • Furthermore, the extended 3DCityDB and the Simulation Package define so-called views linking information otherwise distributed over several tables. SQLAlchemy allows to interact with these views just like with ordinary tables, increasing the user-friendliness of data access and reducing the need for users to define complicated queries.
Example application In the following, a minimalistic co-simulation setup is used to demonstrate the basic functionality of the DAL described in the  After a successful connection, class DBAccess offers several functions enabling a user-friendly interaction with the database. For instance, an important feature is that the SQL functions of the extended 3DCityDB can be called to insert new objects. The following code snippet demonstrates how a new heat pump object is inserted with a reference to the building it belongs to (e. g. , with building ID 1122) using SQL function insert heat pump (lines 1-5). Finally, these changes are committed permanently to the database (line 7). In the context of creating co-simulation setups it is probably most important to have easy access to data already available in the database.
For this, the extended 3DCityDB provides in many cases convenient views. The following example shows how this can be done in the case of heat pump data. First, class HeatPump is associated with the view citydb view. nrg8 conv system heat pump (lines 1-4). This association is then used to refine conditions for querying the database (lines 6-9). Finally, function get citydb objects is called to retrieve data from the specified view with the specified query conditions (lines 11-13). Lines 15-16 show that the attributes of the retrieved objects indeed reflect the content of the specified view. For reading co-simulation setups from the extended 3DCityDB, the DAL provides class DBReader. Upon connecting to the database (line 1), a co-simulation setup stored in the database can be referred to by name and retrieved with the help of a single command (line 3).
In the example below, which simply reads back the co-simulation setup written in the previous example, the resulting object sim read would be identical to object sim from the example in Section 3. 4. 1. 3. 4. 4 Associate co-simulation graphs with 3DCityDB data: In the current IntegrCiTy toolchain, the association of co-simulation graphs with 3DCityDB data happens first and foremost by using the available information to parametrize simulation models. In the context of urban energy systems simulation, this comprises not only scalar model parameters (e. g. , U-values for walls) but also time-series data as provided via the Energy ADE (e. g. , electrical load profiles). The rather trivial approach for such an association is to directly retrieve certain values with the help of the DAL (according to the example in Section 3.