dataesr/scientific-paragraphs-categorization huggingface dataset:
, 1997)  of the forest fire aerosols for this event. Indeed, there was no clear temperature rise inside or near the smoke plume, according to the DC8 temperature data (Figure  S1  in the supporting information). Observational data during this event was used to both validate and design our cloud-resolving simulations. This includes the data from the following instruments; the Ultra High Sensitivity Aerosol Spectrometer (UHSAS)  (Anderson, 2013; Cai et al. , 2008)  from NASA is able to count the number of aerosol particles sized between 0. 060 and 1 μm by detecting the characteristics of laser light scattered by each aerosol particle inside the instrument. The CCN counter  (Nenes, 2013; Roberts & Nenes, 2005)  of the Georgia Institute of Technology optically counts the number of activated droplets after aerosols flow through a supersaturated column inside the instrument.
g. ,  Hong & Dudhia, 2012; Shin & Hong, 2013; Yu & Lee, 2010). The 6-hourly North American Mesoscale Forecast System (NAM) data set (NCEP, 2012) provided initial and boundary conditions for our simulations at a 12-km horizontal resolution. The simulations used the two-moment Morrison microphysics scheme  (Morrison et al. , 2009) , which includes five types of hydrometeors: cloud droplets, cloud ice, rain, snow, and graupel. The upper limit on ice crystal number concentrations in the original Morrison scheme was 10. 1029/2019JD031890 turned off. Without this modification, ice crystal number concentrations may not be as sensitive to changes in droplet number concentrations as they should be. We set the following physics options: the RRTMG longwave and shortwave radiation schemes  (Iacono et al.
Figure10. Vertical profiles of cloud droplet number concentrations (cm -3 ) in the (a) CTL, (b) SML, (c) x10, and the (d) "-orig" runs, averaged inside columns with one or more convective-core grid boxes between 2000 and 2230 UTC (data every 10 min). The shading in each color shows ± temporal standard deviation. The total fire effect (FIRE-NOFIRE, purple), the number/size effect (MODFIRE-NOFIRE, cyan), and the hygroscopicity effect (FIRE-MODFIRE, orange) for the CTL, SML, and x10 are shown in (e)-(g), respectively. The total fire effects for the "-orig" runs are shown in (h). The gray shading indicates the temporally and spatially averaged mixed-phase temperature range inside convective cores in the NOFIRE run. These vertical profiles were vertically interpolated at every 100 m.
Figure12. Vertical profiles of ice crystal number concentrations (L -1 ) inside (a, e, and i) columns with one or more convective-core grid boxes and (b, f, and j) anvils in (a, b) CTL, (e, f) SML, and (i, j) x10, averaged between 2000 and 2230 UTC (data every 10 min). The total fire effect (FIRE-NOFIRE, purple), the number/size effect (MODFIRE-NOFIRE, cyan), and the hygroscopicity effect (FIRE-MODFIRE, orange) are shown for (c, g, and k) convective cores columns and (d, h, and l) anvils in (c, d) CTL, (g, h) SML, and (k, l) x10. The shadings in corresponding colors show ± temporal standard deviation. The gray shading indicates the temporally and spatially averaged mixed-phase temperature range inside convective cores in the NOFIRE run. These vertical profiles were vertically interpolated at every 100 m.
5 GHz; the memory size is 8 GB) to calculate the control signal applied to the proportional directional valve, and a 16-bit data acquisition board (ART Technology, USB3120, the sampling rate is 250 ksps) to receive the position information of the load and send the control signal to the proportional directional valve. The control program, running in the experiment platform, is written in C++ and compiled with Microsoft Visual Studio 2010 under the Windows 10 operating system. The sampling period of the control program is 10 ms. The parameters of the electro-hydraulic system are listed in Table  1. To evaluate performances of different controllers, some indices  [44]  are used as follows: where ξ 1 (i) is the tracking error at time i; ξ max is the maximum of the absolute tracking error; ξ average is the average tracking error; N is the sample size of the tracking error; σ is the standard deviation of the tracking error.
This work was supported in part by the  National Natural Science Foundation of China  under Grant  61973172 , Grant  61273138 , Grant  61973175 , and Grant  61573197 , in part by the  Key Technologies Research and Development Program of Tianjin  under Grant  19JCZDJC32800 , in part by the  Science and Technology Program of Tianjin  under Grant  15ZXGTSF00020 , and in part by the  Open Funding of the Beijing Institute of Space Mechanics and Electricity.
The software provides a generic pipeline that allows free choice of variant calling tools and a flexible language (SSDL) for filtering variant lists. AMLVaran's interactive website presents comprehensive annotation data and includes curated information on relevant hotspot regions and driver mutations. A concise clinical report with rule-based diagnostic recommendations is generated. An AMLVaran configuration with eight variant calling tools and a complex scoring scheme, based on the somatic variant calling pipeline appreci8, was used to analyze three datasets from AML and MDS studies with 402 samples in total. Maximum sensitivity and positive predictive values were 1. 0 and 0. 96, respectively. The tool's usability was found to be satisfactory by medical professionals. Conclusion: Coverage analysis, reproducible variant filtering and software usability are important for clinical assessment of variants.
Even sophisticated pipelines suffer from artifacts caused by immanent weaknesses of the sequencing technology. Discrimination between polymorphisms and pathogenic variants is not trivial, either. The type of tissue to be analyzed is important as well, since relevant variants tend to occur in low frequencies for tumor probes due to heterogeneous cell mixtures. The variety of available clinical databases complicates the annotation of identified variants, and their incompleteness leads to a high number of variants of unknown significance, calling for further (manual) inspection. Clinical use requires software that is able to perform a complete bioinformatics analysis, while offering a user interface that can be operated by medical or laboratory personnel without a dedicated bioinformatics background.
AMLVaran shall be tested for use with AML data, but is intended as a generic system adaptable to other cancer types. Since the software is designed for clinical application, AMLVaran's focus is the generation of accurate and reliable results. We therefore apply the program to three AML datasets, and test its recall and precision to evaluate the software's performance, 0. 95 is targeted for recall and precision. Results of two user-studies shall provide evidence for AMLVaran's practical usability by medical professionals.
System architecture AMLVaran is composed of three main components. First, a flexible, generic variant calling pipeline that generates variant lists from raw sequencing data. Second, an interactive website, which presents the analysis results together with interactive filter settings and creates a standardized, rule-based clinical report. A relational database storing both, results and annotation data, is the third integral part of AMLVaran. The workflow consists of the following steps: A webform manages the upload of one or more NGS raw sequencing files for analysis. Acceptable formats include aligned data in the Binary Alignment Map format (. bam,  [20] ) or raw data in fastq format  [21]. The input files are subsequently processed by the variant calling pipeline, which invokes an adaptable number of variant calling tools and combines their results according to a customizable scheme.
The third view provides an interactive browser, which displays all detected variants. Results can be dynamically filtered and sorted by different criteria, e. g. variant allele frequency or read coverage. The last view features a genome browser, which allows to inspect the mutation of interest on the basis of aligned reads from the original sequence data. The most important pieces of information from the dynamic website are composed into a static, clearly structured clinical report containing the diagnostic and therapeutically relevant details. A tracking system is provided, ensuring, that in case of updated annotation databases, the previously generated reports remain accessible. The web-interface is described in detail in the AMLVaran QuickStart Guide (see Additional file 2). The architecture of the main system components is shown in Fig.
Storing variants The Variant Call Format (vcf )  [29]  defines a standard for storage of genetic variants in a text file. However, the vcf definition allows equivalent variants to be represented in an ambiguous way. Even widely-used databases like dbSNP contain up to 14% non-normalized variants, and 4. 6% unrecognized duplicates  [30]. In order to get a unified, unique representation of all variants, a number of preprocessing steps is applied to AMLVaran's variant lists, as well as the annotation Fig. 1  Overview of AMLVaran's system architecture. Uploaded raw sequencing data are processed by the mutation calling pipeline and the resulting variants are stored in the database. For display at the web interface, the variants are compared with predefined mutation sites and combined with the most up-to-date information from annotation tables.
To further improve the filtering process, a formal language for the definition of variant filtering scores was developed and implemented. This language is flexible enough to implement complex scoring algorithms like appreci8, easily adaptable, and customizable by a graphical interface  [31]. A scoring scheme is specified in JSON and consists of a list of criteria which contribute to the score by a defined weight. Individual criteria can be linked by logical operators AND and OR, and can include variable thresholds. The software is able to derive a graphical interface from the abstract scheme. This enables the end user to activate and deactivate individual criteria, and to adjust threshold values and weightings as needed. The novel Scoring Scheme Definition Language (SSDL) is universally applicable in the sense that, once created, scoring schemes can be used not only within the AML-Varan platform, but also in standalone applications, websites, and in standard applications such as R or Microsoft Excel.
Implementations in JavaScript, R, and Excel VBA are already publicly available  [32]. A formal definition of the SSDL's grammar in Backus-Naur-Form is provided in Fig. 3. A subset of the features of SSDL, as well as the resulting graphical user interface, is shown in Fig. 4. Furthermore, a default scoring scheme for the appreci8 filtering process is available from our website  [33]  and from the AMLVaran package.
Gathering annotation data For adequate biological and clinical interpretation of variants, annotation with comprehensive and up-to-date biological information is a necessity. However, clinical annotation databases are often updated on a regular basis, Fig. 2  Flow chart of the generic variant calling pipeline featured in AMLVaran. An uploaded bam-file is processed by an arbitrary number of variant calling tools (configurable by templates). The resulting variant lists are then normalized and integrated into one common list (in vcf format). For the resulting list of variants, a functional annotation via SNPeff  [12]  and a calculation of sample-specific quality parameters (such as allelic frequency, base quality, etc. ) from the bam file is performed via bam-readcount  [27]. By means of a basic filter, low quality variants are excluded.
For the remaining ones, an effect prediction using Provean  [28]  is carried out. The resulting data is stored in a database and then processed by an advanced filtering strategy and there are several options to address these changes  [34]. On the one hand, there is a strong medical motivation to always consider the most recent biological data regarding the detected mutations for both old and new samples. On the other hand, it is required to reproduce previous reports based on annotation from the past, for practical as well as legal reasons. To meet these requirements, an interactive online report equipped with the latest available biological annotations is presented to the user. Simultaneously, an archive of all previously generated reports is stored on AML-Varan's server. A report is automatically saved in PDF format each time the results page is accessed.
As proposed by Cutting et al. [34] , references to a set of online annotation sources are integrated, allowing for easy access to most recent annotation sources. The technical implementation features stored variant lists and annotation data in separate tables within the database. Whenever a sample is retrieved, relevant data are merged. Currently, AMLVaran uses dbSNP  [35] , COSMIC 1  [36] , ClinVar  [37] , dbNSFP  [38] , 1000Genomes  [39] , ESP6500  [40] , ExAC  [41] , as well as functional prediction data from PROVEAN  [28]  and SIFT  [42]  for variant annotation.
To achieve this, all mutation sites are stored in AMLVaran's databases with precise genomic coordinates. As set of genomic ranges (from 1 bp to complete exons) can be associated with each mutation. Additionally, restrictions to certain mutation types like frameshift insertions can be specified. Any matching, non-synonymous, not benign variant entry located in the specified areas is then regarded as driver mutation. However, it is equally important to reliably rule out the presence of relevant driver mutations. This requires, that no relevant mutation was found in the corresponding region, but also that the coverage of the entire region is sufficiently high. Only then a site is classified as "wild type" by AMLVaran. Implications defined in any disease specific treatment guidelines can be automatically derived on the basis of the detection or exclusion of these defined driver mutations, and are displayed as diagnostic recommendations.
The report can be augmented with more detailed information for each mutation site, including details on the detected mutations, the coverage in the examined area, and general information on the function of the considered gene vant for certain cancer types  [47]. Clinical users expressed interest in comprehensive and up-to-date information on these variants, and for interactive overviews in order to enable quick and accurate interpretation. While AML-Varan retrieves known clinical information from annotation databases like ClinVar or COSMIC, additional resources are required for those mutations. Hence, functional prediction tools, conservation scores and mutation frequency in sequencing projects, such as 1000 genomes, were integrated into the platform, and provide information on the potential pathogenicity of variants.
Results AMLVaran was installed on a virtual server with high performance hardware, and on a standard desktop workstation. Detailed information regarding hardware configuration and runtime is provided in Additional file 1: Section 5. The software's performance was evaluated on AML and MDS datasets, and tested with regards to its sensitivity, positive predictive value, and general usability. Three datasets were analyzed with the generic pipeline in its default appreci8-based configuration, with the following eight variant calling tools: GATK 3. 3 2 [9], Free-Bayes 1. 0. 2 [10] , SamTools 1. 3  [11] , LoFreq 2. 1. 2 [51] , Platypus 0. 8. 1  [52] , SNVer 0. 5. 3  [53] , VarScan 2. 4. 0  [54] , and VarDict (Java) 1. 5. 5  [55]. For annotation and variant filtering process, the following databases were used: dbSNP v150 (2017-04-03)  [35] , ClinVar (2017-12-31)  [37] , COSMIC v83 3 (2017-11-07)  [36] , 1000Genomes v5b (all, Aug 2015)  [39] , ExAC 65000 v0.
3 (all, 2015-11-29)  [41] , and ESP6500 (2014-12-22)  [40]. Precalculated prediction scores were downloaded from PROVEAN v1. 1  [28]. The test system with results on the described datasets are available at https://amlvaran. uni-muenster. de [56]. 2 GATK is only available for public usage from version 4 and higher due to license restrictions. 3 COSMIC is not available for public usage due to license restrictions by the authors.
Validation of the generic variant calling pipeline Validation strategy and source data To validate the generic AMLVaran pipeline in its appreci8like configuration, its output was compared to the original appreci8's output. AMLVaran was used to analyze a set of three published datasets. Two of them were well characterized datasets from myelo-dysplastic diseases, for which biological validation data was available (MDS-1 and MDS-2). The third dataset (AML-1) was taken from routine AML diagnostics, which resembled the intended use case, but only limited validation data was available. MDS-1 and MDS-2 were collected and sequenced within the European MDS Triage project and focused on patients with MDS. The latter one was provided by the University Hospital of Halle, and contained a mixed set of samples (67x AML, 1x AL, 2x t-AML, 2x s-AML after MDS, 1x MDS/AML unsure diagnosis, 17x MDS, 19x MPN and 10x unknown diagnosis).
Evaluation on hotspot regions For clinical use, it is crucial, that existing variants are detected with very high reliability. No less important, however, is the pipeline's ability to safely exclude the presence of mutations for a chosen position. This is of special importance for hotspot regions, which are typically designed to contain mutations relevant for treatment. First, we evaluated results within these defined, therapyrelevant areas for all three datasets. For both MDS and AML datasets, there was a high overlap between the two pipelines and the biological truth. In total, 415 out of 419 variant calls matched for AMLVaran and appreci8 and the ground truth, leading to sensitivity ≥ 0. 99, and PPV ≥ 0. 99. The only two cases of discrepancy between AMLVaran and appreci8 were borderline cases that were reported by only two or three out of eight variant callers, respectively.
Evaluation on the complete target region Next, we considered the whole sequenced target region of 42 kbp length, which includes segments of 19 genes. The target region's average coverage was 1450. Almost all true positive calls from appreci8's reference implementation were confirmed by AMLVaran. For dataset MDS-1, 395 of 397 true variants were identified, and all 89 variants of the MDS-2 dataset overlapped in Fig. 6  Overview of AMLVaran's variant explorer. a Main view of the variant explorer. The detected variants are presented as a dynamic, customizable, interactive table that allows for comprehensive, easy-to-use real-time filtering. Variants can be filtered by gene name in the displayed gene panel, which shows all genes with their number of variants and allows the user to restrict the output to one or more genes.
Further filtering options include the region type (exon, intron, hotspot regions), mutation type (non-synonymous, protein-coding, pathogenous effect prediction), and filtering by minimum quality values (coverage, variant allelic frequency, base quality). Certain kinds of variants can be excluded, e. g. variants rated as artifacts or polymorphisms by appreci8. The presented table can be easily adjusted by selecting the columns to be displayed, changing the sorting order and adding custom filters per column. b Detailed view of all annotation information available in AMLVaran for a variant. Information is divided into different tabs, which show the affected gene (name, function, pathways), the detected variant (protein effect, allele frequency, base quality), the effects of the variant in various medical databases, functional prediction scores from eight tools including rank scores with graphical representation, and a large number of literature references to the chosen gene and variant, retrieved on-the-fly from the constantly updated CiVIC database  [49]  both outputs.
Likewise, 16 of appreci8's 17 false positive calls for dataset MDS-1 and all three false positive calls for dataset MDS-2 were matching in AMLVaran's results. The observed differences can be explained by an improved normalization procedure and updated reference databases. Due to these improvements, the sensitivity of AMLVaran's pipeline (0. 98) was higher than of the reference implementation (0. 95) for MDS-1. For MDS-1, 12 previously filtered true positive variants were correctly classified by AMLVaran, and another six new high-quality In general, AMLVaran's pipeline was slightly more sensitive than the original appreci8 implementation, resulting in 12 additional false positive calls that were reported by AMLVaran. These differences were caused by changes in the updated dbSNP version (10 variants), and a corrected bug in appreci8's method for the counting of samples (2x).
For dataset MDS-2, AMLVaran recognized all 89 validated mutations. Another promising candidate mutation as well as five additional false positive calls were reported. Reasons for the differences were differing PM flag due to newer dbSNP version (three variants), an update to the integrated COSMIC version (2x), and improved InDel normalization (1x). In total, AMLVaran's variant lists showed high concordance with the reference results for both MDS datasets. A detailed comparison of the results of both pipelines and the biological ground truth is shown in Fig. 7.
Evaluation of dataset AML-1 For dataset AML-1, the investigated target regions were much larger. In total, 523 kbp in 112 genes were analyzed, with an average coverage of 570 and over 90% of the unfiltered calls were artifacts/polymorphisms. Since this dataset originated from routine diagnostics, biological validation data was limited to a part of the samples and to the genes NPM1 (n = 75), JAK2 (n = 10), FLT3_TKD (n = 50), and CEBPA (n = 30). For these biologically validated sites, AMLVaran detected 51 out of 55 variants. In addition, AMLVaran did not report a single false positive call for any of the 110 validated wild-type alleles. While the program did report two unexpected calls for FLT3-TKD, these two variants were also reported by appreci8 and validated by expert inspection afterwards.
Compared to the biological truth, AMLVaran achieved a high number of overlapping variants, resulting in high sensitivities of 0. 95 resp. 1. 00 for the NPM1 and JAK2 variants. For FLT3-TKD, one variant was missed. A sensitivity of 0. 67 or higher was achieved for CEBPA, a gene that is typically correlated to coverage issues and high numbers of false positive and false negative variants  [58]. Detailed results for all groups of validated mutations are shown in Fig. 8. In total, AMLVaran reported 504 variants in 119 samples for dataset AML-1, ranging from 0 to 13 variants per sample, and with an average of 4. 2 calls per sample. In contrast to datasets MDS-1 and MDS-2, more differences between AMLVaran and appreci8 were noticeable. A set of 426 variants matched between AMLVaran and appreci8, however 78 variants were called by appreci8 only, and 162 additional variants were specific for AMLVaran.
Evaluation of the system's usability The development of AMLVaran was driven by a focus group, consisting of computer scientists as well as several clinical domain experts and medical professionals. The involvement of clinical experts was especially valuable to identify and prioritize user requirements. Two user studies were conducted during the development process to ensure that the software met critical requirements and offered good usability. In the first user study, a prototype of the software  [59]  was evaluated, while the final AML-Varan program was examined in the second study. 9 and 14 independent medical professionals were asked to fulfill application-related tasks using AMLVaran, respectively. Afterwards, participants were asked to rate their experience with regards to the software's general performance, functionality, and user-friendliness.