dataesr/scientific-paragraphs-categorization huggingface dataset:
Study System and Data This study utilizes data collected at Windermere, which is situated in the English Lake District, United Kingdom (54Њ22 N, 2Њ56 W; altitude 39 m). The lake consists of a mesotrophic north basin and a eutrophic south basin with similar fish species composition  (Winfield et al. 2008). Data have been collected since the 1940s, covering pike and other major fish populations as well as the abiotic and biotic environment (a review of the history of the study is given by Le Cren 2001). In the northwest United Kingdom, annual mean air temperature is predicted to increase over the next century, under different emission scenarios  (Jenkins et al. 2009). Pike prefer shallow water where we can expect similar temperature changes to apply, and the observed surface temperature of Windermere has already shown a marked increase over the recent decades  (Winfield et al.
2008). Scientific monitoring of the pike population was initi-   Frost and Kipling (1959). In this study, we use body length estimates that are measured and back-calculated using catch data for females from 1944 to 1995 (7,939 individuals, 34,440 length estimates in total). Since 1963, data on female reproductive investment (gonad weight, egg number, and egg weight) have also been collected  (Frost and Kipling 1967). During the first few years there was an increase in average egg production after a peak in fishing pressure in 1963, followed by a slow decrease  (Edeline et al. 2007 ). Here we use egg number data from the period  1968-2002 (3,634 individuals) , corresponding to the period with slow decrease. Survival probability estimates are based on data from a separate capture-mark-recapture (CMR) study, which is not ongoing today.
Before and during the spring spawning period (March-April), individuals were caught in a spring sampling program using 38-and 64-mm-mesh-size gill nets and perch traps, and then weighed, sexed, lengthmeasured, and tagged before release  (Kipling and Le Cren 1984; Haugen et al. 2007 ). The tags were made of monel metal with punched individual numbers, and since 1953 they have been attached to the maxilla bone (upper jaw;  Kipling and Le Cren 1984). Some marked individuals were later caught in the spring sampling program, but most were caught (and killed) during the winter fishery  (Carlson et al. 2007 ). Due to reduced sampling effort, the number of pike tagged and recaptured after 1990 has been very low  (Haugen et al. 2007). Therefore, we use CMR data from individuals captured in the period  in this study.
Data from males, females, and individuals of un-known sex (3,992 individuals in total) are used in order to increase the statistical strength of the estimation procedure. The four data sets associated with this study are available online (see URL for each data set in the references): (i) fecundity data  (Winfield et al. 2013a ), (ii) growth data  (Winfield et al. 2013b ),( iii) survival data  (Winfield et al. 2013c) , and (iv) lake temperature data  (Winfield and Fletcher 2013). Further inquiries may also be made directly to I. J. Winfield.
We have provided the R code, available online, for the decomposition of the thermal sensitivity of l (eq. [2]), using the vital rate functions of this study. 1 These functions can easily be modified to other organisms and life histories. In the same R script we also show how to construct the temperature-specific projection function from the vital rates, and how to calculate l, u(x), and v(x) from the projection function. Stochastic Population Growth and Environmental Variance. While most of our results apply to mean environment, we also analyzed a stochastic model to test whether (i) the decomposition of the thermal sensitivity of l (eq. [2]) is a good approximation also for the stochastic growth rate l s , (ii) the stochastic dynamics are well described by a diffusion approximation and thus that the stochastic growth rate and environmental variance are sufficient to capture the long-term dynamics of the system, and (iii) changes in the variability of the temperature process have small effects compared to changes in the mean.
Estimation of Vital Rate Functions Four of the functions entering the model (M(x, z), m g (x, z), , and m g1 (z)) were estimated from the three data 2 j (x) g sets using generalized linear mixed models  (Zuur et al. 2009 ). The constant variance in offspring length was 2 j g1 also estimated from the length data. All analyses were done with the program R (R Development Core Team 2011), using the packages nlme  (Pinheiro et al. 2011 ) and lme4 (for survival probability;  Bates et al. 2011). All models include a random year effect, in order to estimate the residual environmental variance and covariance among the vital rates. We also included a fixed year effect to account for temporal trends caused by other factors than temperature (see  Edeline et al. 2007 ) that are not the focus of this study.
Our model also included residual environmental variation and covariation among vital rates, arising from other sources. This study did not consider changes in the intraannual variability, which may potentially have larger consequences than interannual variability. Evaluating consequences of temperature variability at different temporal scales is therefore another interesting topic for future studies. This study demonstrates that demographic modeling can be useful in revealing complex underlying mechanisms for general responses to climate change, such as increased population growth and the temperature-size rule. The approach of integral projection modeling combines the power of statistical regression modeling with the analytical tractability of demographic models. However, demographic approaches to study climate change effects requires long-term individual-based data as well as observations of the relevant climate variables.
Stage 4 Validation results for stage 3 are systematically and regularly updated when new products are released and as the time-series expands. We propose a tool to provide current and easy access to land product validation results, with transparency and traceability. The objective is to ensure that the validation exercises follow the guidelines established by the community as reported by CEOS-LPV and is compliant with Quality Assurance for Earth observation (QA4EO) recommendations within the Group on Earth Observation (GEO). Further, the platform allows capitalizing on information: the products that are evaluated constitute the -core‖ inter-comparison database from which consistency metrics are computed. Finally, the set of ground validation sites, used for accuracy assessment of satellite products, may also be complemented by new sites that verify the requirements defined by CEOS_LPV.
Once these files are prepared, the user can upload them to the OLIVE platform. The new data can be published to make it accessible to the whole community or not. The new product is then listed along with the other available products. • Add new ground-based measurements: they can be added to expand the database of already available ones. This requires uploading the site description, methods used to complete and process the ground measurements, the strategy used to upscale the local ground measurement to the whole area covered by the site and the data themselves. The site should be at least 3 × 3 km 2 in order to account for the geo-location uncertainties and the point spread function of the products  [24]. Then, the CEOS-LPV sub-group will check if the proposed site complies with the CEOS recommendations for product validation before formally accepting it.
Sustainability of Validation The OLIVE system facilitates improvement of the validation process through updating some functionality, enhancing the metrics used as well as the format of the outputs. The maintenance and update of the OLIVE system is overseen by the CEOS-LPV sub-group. Further, Essential Climate Variables (ECV) other than LAI, FAPAR and fCover such as surface albedo could be included in the OLIVE system for consistent validation. The OLIVE system is built in such a way that the code used to process the data can be modified by the CEOS_LPV sub-group. It is written in ® Matlab. The code is compiled and then run as an executable within the OLIVE web platform. As soon as the input and output file formats managed by the interface remain the same, the Matlab® (Mathworks, Natick, MA, USA) validation core code can be modified and updated.
This is not observed for MODIS because of the exploitation of the replication of views for the higher latitudes that are fully exploited, in agreement with the results reported by  [65]. 2 , and for the original temporal sampling. The fraction of valid data is also evaluated per continent and site (Figure  4 ) and per biome type. The GLOBCOVER biome classification is used  [42, 43]  with the classes being aggregated into larger biome types comprising of Evergreen Broadleaf Forest (EBF), Evergreen Needleleaf Forests (ENF), Deciduous Broadleaf Forest (DBF) and Non Forest (NF). GLOBCOVER was chosen in order to be consistent with the BELMANIP2 site selection and homogeneity verification. However, considering the broad categorization of the vegetation after aggregation, the impact of using a different land cover map should be marginal.
A yearly climatology is finally computed to provide a global average seasonality (Figure  8 ). The difference in magnitude is the largest in July, corresponding to the maximum FAPAR value, with MODC5 > GEOV1 > MGVIo. Conversely, the spatial and inter-annual averages of the three products are in relatively good agreement in winter. Note however that the spatial representativeness may differ between the three products, depending on the fraction of valid data (Figures  2  and 3 ). 2 ). The 49 × 49 pixel values are averaged over all the BELMANIP2 sites for the period defined in the validation exercise. 2 ). The 49 × 49 pixel values are averaged over all the BELMANIP2 sites, and then averaged over years for the period defined in the validation exercise.
They are identified as open symbols in the results (Figure  12 ). The corresponding open symbol is used when the ground data have derived from another year as compared to the ground measurements. In this case, the median value of the available products at the date in the year corresponding to the ground measurements acquisition computed across the considered time period (Table  2 ) is used. Results show that the use of the closest observation reduces the number of available matches between ground measurements and available products (Table  4 ). This is mostly obvious for MGVIo where only 18 DIRECT sites could be used because of the larger fraction of missing data as compared to 60 when the products values were interpolated with time. For MODC5 and GEOV1, the performances measured with the -closest‖ product are very similar to those obtained with the -interpolated‖ product values (Table  4 ), except that the RMSE of MODC5 is much higher with the -closest‖ method.
Discussion OLIVE provides metrics to evaluate the continuity of the products (missing data, length of gaps). It showed some deficiencies of the three FAPAR products considered in this study. They are mainly due to cloud occurrence over the low latitude areas and the limited day length in winter for the higher latitudes that make reflectance data unavailable. It should be noted that these differences, observed on the product continuity, may affect the evaluation of the uncertainties against ground measurements. Indeed, it slightly changes the representativeness of the ground data with regards to the global range. The validation procedures should be improved by providing more details on the structure of the uncertainties which is one of the main outputs of the validation exercise expected by the user community.
Most of the DIRECT sites were only measured once within the entire data record period. However, it is critical to validate the seasonality in the temporal profiles. Furthermore, a significant percentage of DIRECT sites correspond to non-forest situations. Additional sites over forested areas with medium to high FAPAR values are required to improve the accuracy assessment. Further, situations including more complex topography that represent a significant part of the vegetated area should also be sampled. Therefore, the OLIVE tool allows the community to extend the ground validation data sets by adding ground measurement compatible with the medium sensor resolution, through an open, simple and fast submission process. Finally, the accuracy assessed from the ground validation also integrates the uncertainties associated to their measurements, while the upscaling process smoothes out most of the random component of the uncertainties, biases may still be observed.
The OLIVE system has been designed to allow updating the validation code as well as implement improvements endorsed by CEOS-LPV. More efforts should be dedicated to a better knowledge of the uncertainties associated to the products in their original format. The decomposition into precision, accuracy and stability is a first step, but each of these components has a proper structure that should ideally be retrieved from the validation exercise. This will mainly need additional ground measurement sites and a better knowledge of the associated uncertainties. The validation activities of moderate resolution (250 m for MODIS and VIIRS, 300 m for MERIS, PROBA-V and Sentinel 3) will ease the validation process by allowing more sites with already available ground measurements. Flux tower networks are expected to widely contribute to the validation of hectometric and decametric spatial resolution products.
OLIVE has the potential to be extended to other biophysical products including land surface albedo and soil moisture with very minor adaptations. Discrete variables, such as land cover and burnt areas, will require substantial modifications as their validation requires specific procedures and metrics. The validation of biophysical products with higher spatial resolution, as for example provided by LANDSAT-8 and the upcoming Sentinel-2 (10 m-60 m) missions, should capitalize on the OLIVE platform, although requiring significant changes in the validation reference data and procedures.
Operating system (OS) technology is significant for the proliferation of the wireless sensor network (WSN). With an outstanding OS; the constrained WSN resources (processor; memory and energy) can be utilized efficiently. Moreover; the user application development can be served soundly. In this article; a new hybrid; real-time; memory-efficient; energy-efficient; user-friendly and fault-tolerant WSN OS MIROS is designed and implemented. MIROS implements the hybrid scheduler and the dynamic memory allocator. Real-time scheduling can thus be achieved with low memory consumption. In addition; it implements a mid-layer software EMIDE (Efficient Mid-layer Software for User-Friendly Application Development Environment) to decouple the WSN application from the low-level system. The application programming process can consequently be simplified and the application reprogramming performance improved.
Moreover; it combines both the software and the multi-core hardware techniques to conserve the energy resources; improve the node reliability; as well as achieve a new debugging method. To evaluate the performance of MIROS; it is compared with the other WSN OSes (TinyOS; Contiki; SOS; openWSN and mantisOS) from different OS concerns. The final evaluation results prove that MIROS is suitable to be used even on the tight resource-constrained WSN nodes. It can support the real-time WSN applications. Furthermore; it is energy efficient; user friendly and fault tolerant.
With this hybrid scheduling, the number of threads in the MIROS can be decreased. As a result, the real-time scheduling can be achieved with low data memory cost. In Section 3, three kinds of improved MIROS dynamic allocation mechanisms are proposed. These mechanisms are improved on the basis of the current WSN dynamic allocators. With these mechanisms, the allocators become more flexible or can support memory defragmentation. In Section 4, the design and implementation of the new MIROS mid-layer software Efficient Mid-layer Software for User-Friendly Application Development Environment (EMIDE) is discussed. The same as the Embedded Java Virtual Machine (EJVM) and dynamic loading mechanisms (DLM), EMIDE can simplify the application programming process and improve application reprogramming performance.
Scheduling Background of the Wireless Sensor Network Operating Systems (WSN OSes) The scheduling models can be classified into two kinds: the multithreaded scheduling and the event-driven scheduling. Multithreaded scheduling is commonly used on the general-purpose OSes, such as Linux and uCOS. Different tasks can be executed concurrently by the threads, and the preemption among the threads can be achieved by the context switch. With the preemption support, the real-time (RT) reaction can be achieved. However, each thread in the preemptive multithreaded OS should have an independent stack. Thus, the data memory usage of the preemptive multithreaded OS is high, making the preemptive multithreaded OS unsuitable for the high resource-constrained WSN nodes, e. g. , the MicaZ node which has only 4 KB RAM.
Related Works about the Hybrid Scheduling in the WSN OSes Currently, the hybrid scheduling structure has been implemented in several WSN OSes in order to address the different kinds of WSN challenges. In TinyOS, the TOSThread  [13]  is developed for the purpose of combining the ease of the threaded programming model with the efficiency of a fully event-driven OS. TOSThread is achieved in the TinyOS application level (Figure  3a ). It supports the application logic to be implemented in the user-level preemptive threads, and supports the lengthy computation program to be developed inside the TinyOS application. In Contiki  [4] , the hybrid scheduling structure is also implemented (Figure  3b ). The same as the TOSThread in the TinyOS, the multithreaded scheduler in the Contiki is also built on top of the event-driven scheduler.
Code Size of the Different OS Schedulers Code size of the event-driven schedulers: The code sizes of the different event-driven schedulers are shown in Figure  5. In the TinyOS, only one FIFO scheduling queue is used for the event scheduling, and the scheduler code size is small. In the Contiki, two level scheduling mechanisms are adopted: the FIFO scheduling queue for the asynchronous events and the polling mechanism for the high-priority events. As a result, the scheduler code size is larger than that in the TinyOS. In the SOS, three priority-based scheduling queues are used. Moreover, the indirect access and the module management mechanisms are implemented  [5]. Consequently, the SOS scheduling structure is more complicated and more code memory is consumed. In the MIROS, the simple flag-polling mechanism is applied and the code size is small.
Provided by a scenario shown in Table  1 , the data memory size of the different OS schedulers can be computed. From the results in Table  1 , it can be concluded that the MIROS hybrid scheduler can support real-time scheduling by consuming less data memory resources (compared to the pure multithreaded OS mantisOS). Although the data memory costs of the TinyOS TOSThread and the Contiki multithreading are also not high, the real-time scheduling cannot be guaranteed in these systems (Section 2. 5). From the results in Figure  5  and Table  1 , it can be concluded that the code memory size and the data memory size of the SOS scheduler is larger if compared with those of the other event-driven OSes; this is because SOS is a dynamic module-based OS. In SOS, the complicated module management and indirect access mechanisms need to be implemented.
Discussions Although two schedulers are implemented, the code size of the MIROS does not greatly increase. This is because the MIROS event-driven scheduler only needs to schedule the non-RT tasks while the MIROS multithreaded scheduler only needs to schedule the RT tasks. As a result, the implementations of both the two schedulers can be simplified (Section 2. 4). The MIROS RT tasks and non-RT tasks are scheduled by two different schedulers. Thus, two kinds of programming styles exist. Commonly, the non-RT tasks need to be programmed by the event-based style (using the phase-split state machine) while the RT tasks need to be programmed by the thread-based style. In order to simplify the programming complexity, the protothread  [18]  is applied in MIROS. With the protothread, the non-RT tasks can also be programmed in a thread-similar programming style.
Performance Evaluation In Figure  10  and Table 4 , the code size, the execution efficiency and the memory utilization efficiency of the different dynamic allocators are evaluated. In Table  4 , the symbol F represents the steps of searching for a free block in the Contiki SFL allocator (Contiki SFL uses the block flag mechanism other than the free list mechanism to manage the free memory), L represents the steps of searching for an available entry in the free list, and S represents the size of the memory to be shifted during the coalescing operation. From these evaluation results, it can be concluded that the code size and the allocation overhead of the dynamic allocators are not very high, thus the dynamic allocation approach is feasible to be used even on the resources-constrained WSN platforms.
Dynamic Loading Mechanism (DLM) Dynamic loading mechanism (DLM) is another approach which can decouple the application space from the system space. With the DLM, the application can be built into a loadable module and then linked dynamically on the WSN nodes. To perform the dynamic linking, the function and variable references need to be contained in the DLM module and a dynamic linker needs to be implemented on the target device. Currently, the DLM mechanism has been used in many WSN OSes, such as the TinyLD  [13]  in the TinyOS, the dynamic loader (ContikiDL) in the Contiki  [33]. Moreover, the application code is built into a standard loadable ELF (Executable and Linkable Format) file in these mechanisms. The drawback of the DLM is that the application module cannot be executed directly.
The Design and Implementation of the EMIDE The objectives of EMIDE determine it to be designed as follows: Decoupling the application space from the system space: Like the EJVM and the DLM, EMIDE should be able to decouple the application space from the system space and function as a bridge between these two spaces. Machine code or interpreted code: The byte code is used in the EJVM application while the machine code is used in the ContikiDL module. Although the byte code can be platform independent, more energy and time will be consumed during its interpretation process. Therefore, the machine code is chosen in the EMIDE. In this way, EMIDE can address the challenge of better using the tight resource-constrained WSN nodes. Pre-linked code or dynamic loading code: The pre-linked application code is used in most EJVMs  [26] [27] [28] [29] [30] [31] [32]  while the dynamic loading code is used in most DLMs  [13, 33].
Compared with the dynamic loading code, the pre-linked code is smaller in size, and higher in execution efficiency. Moreover, the underlying system architectures can be simplified. Due to these reasons, the pre-linked approach is adopted in the EMIDE so that it can maintain a small memory footprint. Application programming language: In most EJVMs, the language used in the application space (Java language) is different from the language used in the system space (commonly C language). As a result, two different run-time contexts should be created and this increases the complexity of the system architecture. In EMIDE, the application language is chosen to be the same as the system language. In so doing, the application code and the system code can call each other directly, thereby simplifying the system architecture.