dataesr/scientific-paragraphs-categorization huggingface dataset:
[50]  to identify relevant entities for our study, i. e. genetic clusters of specimens potentially subject to selection and genetic drift. The method of Pons et al. [50]  identifies clusters representing independently evolving entities using a generalized mixed Yule coalescent model (GMYC). The model optimizes the maximum likelihood value of a threshold, such that the nodes before the threshold are identified as species diversification events, while the branches beyond the threshold are clusters following coalescent processes. Two ultrametric trees were constructed from the combined dataset using the uncorrelated lognormal relaxed clock method implemented in BEAST v1. 7. 4  [47] , assuming either a Yule tree prior or a coalescent tree prior with a constant population size back through time.
AICM has been shown to perform better in model selection than HME  [53]. Following the removal of 10% burn-in, the sampled posterior trees were summarized using TreeAnnotator 1. 7. 4 to generate a maximum clade credibility (MCC) tree. The GMYC method as implemented in the R package SPLITS (http://www. rforge. r-project. org/projects/ splits/), was then applied to the MCC tree that best fitted our data. We then derived a "phylogenetic species" tree based on the results of the species delimitation method, by picking (at random) one specimen for each putative species and simply pruning subsequent specimens from the global tree with R using the package APE  [54].
When they were found capable of feeding on lignified wood (specimens were found on branches, older twigs and small trunks), they were considered as branch feeders. When they were found on trunks only, meaning that they needed a rostrum long enough to reach the sap through thick bark, they were considered as trunk feeders. Information in Blackman & Eastop  [29]  is sometimes based on original descriptions or a few taxonomic surveys, therefore adding information from our field campaign generally increased species polymorphism in feeding sites and host plant use. Further, when a morphological species was divided into several clusters, we only took into account information recorded in the field in order to evaluate whether each cluster was associated with a particular character state. We then used the PhyloType software  [34]  to explore the evolutionary trajectory of host plant genus association and feeding sites, and to give a coarse biogeographic scenario for the diversification of North American and European species.
Sequence data The final matrix contained 56 morphological ingroup species (five of those could not be assigned to either of two morphologically similar species, we thus gave them "mixed" names), six specimens for which identification keys did not lead to any known species and four outgroups, representing a total of 246 individuals and 4076 bp (COI + Cytb = 1418 bp, Aph = 257 bp, EF = 1135 bp, His = 719 bp, and GroEL = 547 bp). All sequences have been submitted to Genbank (Additional file 1). 1906 bp were variable and 1705 bp were parsimony informative. Sequences were missing for less than 12% of specimens for each DNA marker (18 COI, 5 Cytb, 8 Aph, 28 EF, 20 His and 25 GroEl). Alignment of protein coding genes revealed no stop codons or frame shifts.
Molecular systematics of the genus Cinara We obtained a well-resolved phylogeny of the genus Cinara encompassing a quarter of the species diversity. Our results confirmed the monophyly of the subgenus Cupressobium though it appeared nested within a group of species belonging to the subgenus Cinara. These relationships suggest that the subgeneric classification within Cinara needs revision. The data presented here will be useful for future work dealing with the taxonomy of the genus. Our molecular work on species delimitation was largely concordant with previous taxonomic investigation in the genus  [25, 37, 56, 57]. Overall there was a good correspondence between morphological species and genetic clusters inferred by the GMYC species delimitation method. But our analyses revealed more diversity than currently described in some common species with large geographic distributions: C.
The results from this study will be presented as a sequence of two parts. Part 1 describes the two modeling systems: WRF/Polyphemus and WRF/Chem-MADRID, their configurations and the simulation set-up, evaluation protocols and observational databases used, and the evaluation of meteorological predictions and sensitivity to horizontal grid resolutions using WRF. Part 2  (Zhang et al. , 2013)  describes the evaluation for chemical concentrations and intercomparisons between chemical predictions from the two models, sensitivity of the model predictions to horizontal grid resolutions, and the interactions between meteorology and aerosols predicted with WRF/Chem-MADRID. Figures.
g. Sartelet et al. , 2008 Sartelet et al. , , 2012;; Royer et al. , 2011) , and specifically to simulate the year 2001 over Europe  (Sartelet et al. , 2007). A detailed model description set-up of Polair3d/Polyphemus is given by  Sartelet et al. (2007). Compared with the study of  Sartelet et al. (2007) , major updates in the model treatments include the gas-phase chemistry, the calculation of photolysis rates, the treatment of organic aerosols, the number of vertical levels and the land use cover. To minimize differences in model predictions, the same or similar modules are chosen for both model simulations whenever possible, e. g. both models use the same gas-phase chemical mechanism (CB05)  (Yarwood et al. , 2005) , the same photolysis scheme (Fast-J)  (Wild et al. , 2000) , and the same aqueous-phase chemical mechanism that is based on the Carnegie Mellon University (CMU) aqueous-phase chemistry of  Fahey and Pandis (2001).
Back Close Full rates is taken into account  (Real and Sartelet, 2011). The major differences between the two AQMs lie in heterogeneous chemistry, dry and wet deposition of gaseous and aerosol species, aerosol treatments and aerosol-cloud interactions. While the version of WRF/Chem-MADRID used in this study does not treat heterogeneous chemistry, Polyphemus includes heterogeneous reactions of HO 2 , NO 3 and N 2 O 5 on the surface of aqueous particles and cloud droplets based on  Jacob (2000). Polyphemus uses the SIze REsolved Aerosol Model (SIREAM)-SuperSorgam aerosol module  (Kim et al. , 2011)  and WRF/Chem-MADRID uses the MADRID aerosol module of  Zhang et al. (2010a Zhang et al. ( , 2012a)). Although both aerosol models use a sectional size representation with 8 sections between 0. 0215 and 10 µm and simulate aerosol thermodynamics using ISORROPIA  (Nenes et al.
, 1998)  for inorganic species, dynamic processes (nucleation, coagulation and condensation/evaporation) and organic aerosol thermodynamics, they differ in several aspects. Both models include similar sets of SOA precursors (e. g. aromatics, long-chain alkanes, long-chain alkenes, isoprene, and terpenes), and use an absorptive approach for hydrophobic SOA (Super-Sorgam of  Kim et al. (2011)  for Polyphemus; an updated version of the MADRID 1 SOA module for WRF/Chem-MADRID). However, the Super-Sorgam SOA module in Polyphemus accounts for the NO x dependency for SOA formation from biogenics and aromatic compounds based on  Ng et al. (2007)   (2002)  and the H 2 O-H 2 SO 4 -NH 3 ternary nucleation scheme of  Napari et al. (2002) , but nucleation is not taken into account in this work. For gas/particle mass transfer, both models use the bulk equilibrium approach in this work.
Polyphemus uses the parameterization of  Zhang et al. (2001)  that treats dry deposition processes, such as turbulent transfer, Brownian diffusion, impaction, interception, gravitational settling, and particle rebound. Despite the use of different modules  (Easter et al. (2004)   that is not treated in Polyphemus. WRF/Chem-MADRID treats in-and below-cloud wet removal of PM based on the parameterization of  Easter et al. (2004). Polyphemus only treats in-cloud scavenging parameterization of PM based on the parameterization of  Roselle and Binkowski (1999). For aerosol-cloud interactions, WRF/Chem-MADRID includes an aerosol activation parameterization of Abdul-Razzak and Ghan (A-R&G) (2002) and simulates aerosol direct, semi-direct, and indirect effects. Polyphemus allows the activation of particles if they exceed a critical diameter of 0.
emep. int) for both models. However, as indicated in  Mallet and Sportisse (2006) , large uncertainty exists in the vertical distribution of the EMEP emissions. In Polyphemus, the surface and elevated sources are assumed to be released in the first model layer and several upper layers, respectively, at the median height of each layer defined in WRF. They are distributed following a vertical profile in WRF/chem. Given differences in the first model layer height and the thickness of each model layer between the two models, the vertical distributions of emissions are different, which will affect model predictions of chemical concentrations. Sea-salt emissions are simulated online based on  Gong et al. (2002)  in WRF/Chem-MADRID and offline based on  Monahan et al. (1986)   online module which generates emissions from soil surfaces (note that road dust emissions are not simulated) as described in  Zhang et al.
Back Close Full MEGAN2 BVOCs module that include all primary aerosol emissions and secondary aerosol formation represent the effects of aerosols via various feedback mechanisms. ), nitrate (NO - 3 ), ammonium (NH + 4 ), sodium (Na + ), and chloride (Cl -)). EC and organic matter (OM) are not evaluated because of a lack of observations. EMEP contains data from the Convention on Long-Range Transboundary Air Pollution and represents hourly O 3 data and daily data for other species at regional background sites mostly at farmland, rural, and light forested areas  (Torseth and Hov, 2003). The AirBase database contains observations from the European Air Quality (EEA) monitoring network (EuroAirnet) provided by European Union Member States, EEA member countries, and cooperating countries. It contains hourly data for all species and additional daily data for PM 2.
Back Close Full in AirBase. Large uncertainties exist in these observational data due to artifacts in the measurements and the impacts of local geographical conditions on the measurements  (Schaap et al. , 2004; Sartelet et al. , 2007). The satellite datasets include the Total Ozone Mapping Spectrometer/the Solar Backscatter UltraViolet (TOMS/SBUV), the Measurements Of Pollution In The Troposphere (MOPITT), the Global Ozone Monitoring Experiment (GOME), and the Moderate Resolution Imaging Spectroradiometer (MODIS). The variables evaluated column concentrations of tropospheric CO and NO 2 , tropospheric O 3 residual (TOR), and aerosol optical depth (AOD). To evaluate all observations related to MODIS, the monthly-mean AOD predictions are calculated as an average of column-integrated values during 15:00-20:00 UTC when the Terra satellite passes over the continental US, following  Roy et al.
Description of selected sites The observations of precipitation and other meteorological variables such as T2, Q2, and WS10 come from different databases (i. e. ECA&D and NCEP, respectively) and no observation of all these variables was available at the same sites. Ten sites are selected for detailed temporal analysis for T2, Q2, and WS10. Eight sites are selected for detailed analysis for precipitation. Table  5  summarizes the major characteristics of the selected sites. Among the ten NCEP sites selected for analysis of T2, Q2, and outside D02 and D03. Among the eight sites selected for a detailed analysis of Precip, three sites (Pris-14E, Bretigny-sur-Orge, and Chartres-Champhol, France) are in D03, two sites (Milan, Italy and San Sebastian-Igueldo, Spain) are in D02 but outside D03, and three sites (Stockholm, Sweden; Gorlitz, Czech Republic; and D üsseldorf, Germany) are in D01 but outside D02 and D03.
Conclusions This paper describes two 3-D air quality model systems (WRF/Polyphemus and WRF/Chem-MADRID) to be evaluated for their capability in simulating pollutant concentrations over Europe in Part 2, the simulation design, as well as the evaluation datasets and protocols. Both models use WRF to generate meteorological fields for chemical predictions. In this Part 1, we described the application of WRF for Jan- northwest and the hottest/wettest in the south in both January and July. In January, although the positive bias (an MB of 0. 5 • C and an NMB of 19. 2 %) in T2 dominates, the largest cold biases (-5 to -2 • C) occur in the Alps area and the eastern portion of the domain, likely due to several limitations in model initialization and treatments (e. g. too cold soil temperature, too much soil moisture, too many daytime clouds, and a poor treatment of snow-related processes).
uary and July 2001 over triple-nested domains in western and central Europe at three horizontal grid resolutions: 0. 5 • over a large area in western Europe, 0. 125 • over an area covering France, Germany, the Netherlands, Belgium, Switzerland, Luxembourg, Slovenia, most of Austria, and part of the UK, Italy, the Czech Republic, Spain, Croatia, and Poland, and 0. 025 • over an area covering the greater Paris region in France. WRF predictions are evaluated using available observational databases. The WRF simulation at a horizontal grid resolution of 0. 5 • reproduces the observed spatial gradients of temperatures and specific humidity with the coldest/driest values in the Figures Back Close Full Screen / Esc Printer-friendly Version Interactive Discussion Discussion Paper | Discussion Paper | Discussion Paper | Discussion Paper |.
However, there is no published evidence of the effect of traceability links in software maintenance tasks in industry. This paper seeks to gather such evidence through an empirical study. Before conducting the empirical study, a survey was conducted to determine the link model that fits stakeholder roles. This link model is used in the empirical study. Note that the intent of this paper is not to create a traceability system  [3] , rather the goal is to show the effect of links on maintenance tasks. For this reason, a simple prototype TraceLink was created that provided us with enough linking to run the study. In the past decade, there has been a lot of progress made in the field of software traceability  [4]  (especially with link recovery and more recently with link evolution) in academia.
The results of the survey are presented from the point of view of each stakeholder. The second question is addressed by conducting a controlled experiment using industry experts as well as students in a senior software engineering capstone class. This paper is organized as follows. The next section defines what we mean by traceability links. Section III presents the industrial survey, stakeholder benefits, real life scenarios that occurred at an industrial firm and a high-level traceability meta-model as a consequence of the survey. Section IV presents a controlled experiment conducted on the effect of traceability links (via a prototype linking tool TraceLink), on several software maintenance tasks. This is followed by a discussion in Section V and threats to validity in Section VII. Section VIII presents related work and Section IX discusses future work and concludes this paper.
A. TRACEABILITY META-MODEL Based on the industrial survey, a traceability meta-model was developed. Different stakeholders in the software development cycle are interested in different traceability links between different artifact repositories. A traceability model must support traceability links that are specific to each stakeholder role. A meta-model that requires support for links specific to each stakeholder role is shown in Figure  1. In this meta-model, a TraceModel consists of one or more TraceLinks. A TraceLink contains two TraceElements (artifacts). A TraceElement has type and status attributes. The type is either ''source'' or ''target''. The status is set to ''modified'' when one or more of the important fields in TraceElement are modified. Stakeholder has a Stakeholder role that traces one or more specific TraceLinks.
IV. THE STUDY The second research question seeks to determine if the presence of traceability links help in software maintenance tasks. This section presents details on the study conducted in industry and academia on the effect of traceability links in software maintenance tasks. The link model used in this study is based on the results of the industrial survey presented above. To conduct the study, we developed a prototype traceability tool that we call TraceLink. We first describe the prototype tool followed by the experiment details.
B. EXPERIMENTAL DESIGN AND HYPOTHESES Following the template by Wohlin  [13] , the experiment seeks to analyze the effect of using traceability links via TraceLink, for performing software maintenance tasks with respect to effectiveness (accuracy) and efficiency (speed) from the point of view of the researcher in the context of industry practitioners and software engineering students. The detailed null hypotheses are given below. The alternative hypotheses are 1-tailed predicting TraceLink performs better. The hypothesis testing is done at 95% significance (alpha = 0. 05). H 1 : There is no significant difference in task accuracy when performing maintenance tasks in the presence of using traceability links via TraceLink (versus not using it). µ (Accuracy with links ) = µ (Accuracy without links ).
H 2 : There is no significant difference in task speed when performing maintenance tasks in the presence of using traceability links via TraceLink (versus not using it). µ (Speed with links ) = µ (Speed without links ). H 3 : Ability level does not significantly interact with TraceLink to have an effect on task accuracy, difficulty or speed. The overview of the experiment is shown in Table  3. The main factor being analyzed is the link-tracing method with two treatments: without links (no TraceLink) and with links (links displayed using TraceLink). While analyzing the results we also looked at secondary factors such as the effects of subjects' ability level (high vs. low ability) on accuracy, difficulty level and speed combined with the link-tracing method. The difficulty level refers to a rating of easy, medium or hard given by the participant for each of the five software maintenance tasks.
C. PARTICIPANTS A total of 28 participants were involved in the study: 22 software engineering students and six practitioners (three developers and three testers) from industry. We split the participants into two groups. Only one group used TraceLink to solve the tasks. The other group were not provided with traceability links. To ensure a variety of abilities in both groups, the students were randomly placed into two groups. Industry participants were also randomly assigned into one of two groups of 14 people each. Both the control and experimental groups had eight high-ability subjects and six lowability subjects. Six of the subjects from industry are very skilled practitioners who have been developing and testing software for at least 5 years.
Subjects were asked to note the start and end time for each task on paper as well as indicate the level of difficulty (Easy, Average, Difficult) they faced for each of the five tasks. All the data was collected on paper questionnaires and later tabulated. In addition to the tasks provided to all, people in group 1 (that were provided no links) were provided with an electronic file that contained all artifacts for the system. People in group 2 were provided with the same material as group 1, and in addition they were also presented with traceability links between the artifacts via the TraceLink tool. The tool contains all artifacts and the 402 links listed in Table  4. A sample demo for group 2 on how to use the tool was given before the study began. The academia subjects took the study in a computer lab while industry subjects did the study at their workplace.
V. DISCUSSION The results of the study indicate that using traceability links leads to significantly more correct answers for software maintenance tasks. With respect to speed, industry subjects who given traceability links (via TraceLink) were faster than subjects that were not given any links (group with no TraceLink). In academia, however, subjects who did not have traceability links were faster. This can be due to the fact that industry subjects are more accustomed to using tools (given that the links were presented via the TraceLink tool) compared to students; in addition, more training was needed on the tool as pointed out by some subjects. With more training we could expect to see a significant difference in time needed to solve the tasks. This is left as a future exercise. Results also show that the use of traceability links reduces the gap between high and low ability subjects as well as between academia and industry subjects.
VI. DEVELOPER COMMENTS ON TRACELINK This section presents what developers are interested to see in a traceability tool to help them in software maintenance tasks. Based on the input from developers in industry, some of the features that need to be supported by a traceability system are given below. These were all additional feature requests made by the subjects as they used TraceLink to solve the maintenance tasks. These observations are mentioned here with the goal of aiding future traceability tool developers. • A simple search function similar to grep would be required. Note that TraceLink provided a way to find all links that were related to a given artifact however searching on specific keywords was not implemented. • A traceability system should have more than one level of linking. For example, if artifact A is linked to artifact B and B is linked to artifact C, the tool shall support A to B and A to C linking.
We derived our tasks after browsing the Bugzilla database for various projects. The developers also agreed in the post questionnaire that the tasks were realistic. Also, there are not many open source systems that have traceability matrices available for use which makes the choice of a subject system very narrow. Most traceability papers use the same academic datasets such as iTrust  [14]  to validate their link retrieval/evolution algorithms. In this regard, we can consider the room management system dataset as yet another dataset with developer provided traceability links that could be used by traceability researchers in the future. Our results from the study are only generalizable to maintenance tasks that are similar (i. e. , finding artifacts that need to be changed if a feature is added, changed, or behaves incorrectly).
There are many papers such as  [32] -  [37]  addressing the topic of link recovery. Although this paper does not address link recovery, these are important to consider when developing a traceability system. Traceability tools such as ADAMS  [38] , Poirot  [39] , ACTS  [40] , traceMaintainer  [3]  and Traceclipse  [41]  have been developed for link recovery and management in academia. DeLucia et al. [42]  conduct a controlled experiment to assess the usefulness of an information retrieval based traceability recovery tool. Results show that the tool reduces the time spent vs. manual tracing. These studies compare different traceability techniques instead of assessing the effect of traceability itself on maintenance tasks. None of the studies look at the effect of traceability links on software maintenance tasks: the main goal of the study we present in this paper.