dataesr/scientific-paragraphs-categorization huggingface dataset:
Assessment of third-party software The five complex surfaces were converted into Chebfun objects and then used to obtain surface texture parameters. As the limitations of some symbolic calculations have been alleviated due to the numericalbased approach, parameters Sa and Sdr were also calculated in addition to the original set shown in section 2. 2. Whilst the Chebfun method's calculation of the original set of parameters was verified against symbolic mathematical calculation in section 3. 2, no such verification could be performed for Sa and Sdr. Therefore, although Chebfun may be able to calculate these parameters as accurately as the original set, caution must be taken when using the Chebfun parameter values as a reference, as errors may be present. For this reason, the calculation methods used should be explicitly stated alongside the obtained value to inform users of the potential sources of error.
This is good practice that promotes transparency and should be carried out for any method of calculating reference values. In addition, alternative numerical calculation methods can be used alongside the Chebfun methods, and the number of significant figures that agree between both methods can be used as the reference value, increasing the confidence in the presented value. With these reference parameter values obtained, it is now possible to use these values to assess the performance of third-party metrology software packages. The process was performed in a similar method to section 2. 2; the five complex surfaces were sampled to create high resolution 700 × 700. SDF datasets which were then input into each third-party software package to calculate parameters. The results were then normalised to the mathematically-obtained values to enable easier comparisons.
All software packages under test show good agreement with the reference value, deviating by no more than one tenth of a percent. Here, software B shows the greatest amount of variation, suggesting the methods employed to calculate the Sa parameter are not as accurate as those employed by the other three software packages. Again, there is very close agreement between software A, C and D. Figure  8  shows the results for the Sdr parameter. Here, there are significant differences in the values obtained by software A and C, suggesting Sdr is one parameter that the two software packages calculate differently. Similar to the results for the Sdq parameter shown in figure  3 , the Sdr parameter is affected by the resolution of the dataset, and the results here show that surfaces with more high spatial frequency components are the more significantly affected, with each of the software packages performing worse for those cases.
It should be noted here that software D only gave Sdr results to two decimal places, making meaningful comparisons with the other software package results difficult. Through the use of the numerical methods made available using Chebfun, high precision reference parameter values can be obtained not only for parameters whose calculations are prohibitive for symbolic calculations using CASs, but also for surfaces with an increased degree of complexity that would otherwise be too computationally intensive. Using these new methods, a greater understanding of the strengths and weaknesses of the software under test can be performed using a wider range of surface texture parameters. In addition, the use of high complexity surfaces with high spatial frequency components delivers more information about the software under test, and how the calculated parameter values can vary.
Performance assessment The work presented here and in reference  [18]  introduce mathematically-defined reference pairs  [35]  for the performance assessment of surface texture parameter software. An important aspect of this process, however, is the delivery of the analytical surface to the discrete software under test. All surface texture parameter software operates with a discrete surface height dataset as the primary input. As the reference surfaces are defined analytically, it is therefore necessary to perform a discretisation operation in order to create a discrete dataset that can be used by the software. This is achieved by some method of sampling; extracting a finite number of height values by evaluating the surface expression at different points in x and y. By virtue of this finite sampling, however, information about the surface is inevitably lost, as the areas in between the sampling locations contain surface information that is not transferred to the discrete representation.
Due to the loss of information when moving from an analytical representation to a discrete representation, surface texture parameter calculation software will not be able to obtain the exact same results as the mathematical reference. The software is working with less information, and so will deviate from the mathematical reference values in scenarios where the information required has not been sampled and incorporated into the dataset. It is important, therefore, to attempt to account for this discretisation error and assess the software under test fairly, based on the information it is given. This work introduces performance metrics that can be used to numerically assess the performance of surface texture parameter calculation software under test against mathematical reference values, while taking into account the discretisation error introduced from using discrete datasets for testing.
Agreement of significant figures In this section, a method for the assessment of surface texture parameter software performance is introduced. This approach quantifies the number of significant figures given by the software-Table  3. Number of significant figures from the software-obtained parameter value results that agree with reference values obtained using the methods in sections 2 and 3. 2 for 700 × 700 resolution datasets. obtained value that agree with the mathematical reference value. This number is then given alongside the resolution of the dataset used to obtain the software value, giving a performance metric describing of the quality the software's performance relative to the amount of discretisation error present. In addition, this performance metric allows for direct comparisons between third-party software.
Variation due to sampling A stage of the discretisation process that can affect the dataset and, therefore, the resulting parameter values is the sampling method used to obtain discrete height values from the analytical surface. The continuous surface can have different height values at very close x,y locations on the surface, and so small variations in the sampling locations can obtain different height values for use in the dataset. Additionally, averaging methods can be used that obtain single height values that describe areas of the analytical surface instead of specific sampling locations, which could also produce a different dataset for the same evaluation area. There is no 'correct' sampling method, as different choices can be used to represent the height capture methods of different measurement processes.
For example, for a 1000 × 1000 resolution surface spanning 10 mm by 10 mm, height values were sampled between 0 mm and 9. 99 mm in each direction, accounting for the pixel widths which extend the surface size to between -0. 005 mm and 9. 995 mm. The second sampling implementation uses the same spacing between points, but includes an extra point on the end, giving a 1001 × 1001 resolution dataset with height values sampled between 0 mm and 10 mm. This method treats the dataset as a collection of discretely sampled height values with zero pixel width, and so still spans the same evaluation area as the previous implementation. Table  4  gives the same significant figure analysis as performed in table  3 , but for the second sampling method. Software B shows a significant improvement in its agreement with the reference values, while software A, C and D all show worse results.
These performance metrics suggest this style of sampling is well interpreted by software B, whereas the other software packages are more suitable for the previous implementation. Again, neither implementation is 'correct', and clear specification of the sampling choices used when creating a dataset are necessary for proper assessment of metrology software. Table  4. Number of significant figures from the software-obtained parameter value results that agree with reference values obtained using the methods in sections 2 and 3. 2 for 701 × 701 resolution datasets calculated using an alternate sampling method.
This paper presented metrics to assess the performance of surface texture parameter software whilst accounting for discretisation error introduced when creating a discrete dataset from an analytical surface. A technique was presented that calculated the number of significant figures in the software-obtained parameter values that agree with the reference value. This method gave a succinct performance metric for each parameter that enabled easy inter-software comparisons, and allowed for quick assessment of a software's ability to agree with the reference value. The performance metrics for each parameter were also combined to assess the performance of the software as a whole, taking each parameter into account. In addition, the implementation of sampling on the created dataset, and hence the resulting parameter values, was investigated.
The importance of explicitly defining the sampling methods used when producing a dataset were emphasised, and an example comparison of two different sampling implementations were compared, showing a significant effect on different software packages. The combination of the performance metrics and reference surface texture parameter values introduced in this paper provide a novel framework for the validation of surface texture parameter software that improves upon the current state of the art by introducing mathematical traceability and increased accuracy. By incorporating performance metrics, both developers and end-users of metrology software are able to assess and compare software results easily and accurately.
This model is currently used by the Regional Health Agency as a tool for decision support, called "ALBORUN"  (Tran et al. , 2020). In the present study, we modified this ALBORUN population dynamic model to integrate the potential effects of SIT and boosted SIT on the Ae. albopictus populations in La Reunion Island. After controlling its accuracy on the same entomological data used in  Tran et al. (2020) , we first performed a global sensitivity analysis to identify the key parameters affecting the efficacy of SIT and boosted SIT. We then assessed the optimal timing for both control methods under a tropical environment, taking into account the spatial heterogeneity of micro-climates in La Reunion Island to produce a detailed map of the locally-optimal starting months of the control period. Finally, we studied the effects of two different sterile males release strategies, constant or density-dependent, on Ae.
, 2012). Larval mortality (m L ) is similarly increased when their density L increases. Parameters and functions are similar to the ALBORUN model by  Tran et al. (2020)  (Table : 1). Due to the aggregation of female sub-compartments, the value of the parameter µ Fr and the function f F had to be reevaluated to ensure consistency between the original and modified models. The value of µ Fr was estimated using a maximum likelihood method ("Multi-Level Single-Linkage" or MLSL algorithm, nloptr package, R software, https://cran. r-project. org/web/packages/nloptr/index. html) to adjust mALBORUN to the outputs of ALBORUN (i. e. the density of mosquitoes for each compartment). In addition, the mALBORUN f F value was obtained by summing the times spent by the nulliparous and parous females in the host-seeking, blood-feeding and breeding site-seeking compartments in ALBORUN.
For each time step, mALBORUN predicts the abundance of Ae. albopictus for the seven stages and for each operational urban sectors. The model was further validated using the entomological data from  Tran et al. (2020) , i. e. a longitudinal study on the larval stages of Ae. albopictus at five northern sites in 2012 and 2013 A Spearman test was performed to assess the correlation coefficient between the observed larvae abundances and those predicted by the model.
Sensitivity analysis A Sensitivity Analysis (SA) was performed on the four synthetic outputs using the variance-based method of Fourier Amplitude Sensitivity Test  Saltelli et al. (2000)  with the Sensitivity R package (https://cran. r-project. org/web/packages/sensitivity/index. html). The parameters of mALBORUN-SIT (µ , Ms c), mALBORUN-BSIT (µ , Msc d, k F , k B ) and the parameters relative to the release (τ, n, T Start , ,.
Initialization and simulations Models were implemented in R (http://www. rproject. org/). At = t 0, the population consisted in 1000 eggs for each operational urban sectors. Simulations ran over 6 years. We used the weather data from 2011 to 2016 as the input of the models. The first year was not retained for outputs computation. No sterile male has been released during the last year, which allowed computing the time required for the Ae. albopictus population to recover its natural dynamics, i. e. the resilience time (in days).
Results The ALBORUN model has been modified and simplified, in order to model the effects of control methods (mALBORUN). As in the original model, mALBORUN predicts the abundances of Ae. albopictus by stage (eggs, larvae, pupae, adults: females and males) over time for each operational urban sector, using daily rainfall and temperature data over 6 consecutive years as entries. The effects of the SIT (mALBORUN-SIT) and boosted SIT (mALBORUN-BSIT) were then introduced to predict and compare the impact of the two control strategies under different scenarios (Fig. 5 ).
Acknowledgements The authors would like to thank  Pauline Ezanno  ( Ecole nationale vétérinaire, agroalimentaire et de l'alimentation de Nantes -Atlantique -ONIRIS ) for her help on the sensitivity analysis,  J. S. Dehecq  ( Agence Régionale de Santé -ARS ) for the entomological data and  David Pleydell  ( CIRAD-INRA of Montpellier ) for fruitful discussions on the boosted SIT. This work has been funded by the  European Research Council  under the European Union's  Horizon 2020 research and innovation program  (grant agreement no. 682387-REVOLINC ), in the framework of the  One Health Indian Ocean network  (www. onehealth-oi. org). The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
ATLAS event processing requires access to centralized database systems where information about calibrations, detector status and data-taking conditions are stored. This processing is done on more than 150 computing sites on a world-wide computing grid which are able to access the database using the Squid-Frontier system. Some processing workflows have been found which overload the Frontier system due to the Conditions data model currently in use, specifically because some of the Conditions data requests have been found to have a low caching efficiency. The underlying cause is that non-identical requests as far as the caching are actually retrieving a much smaller number of unique payloads. While ATLAS is undertaking an adiabatic transition during the LHC Long Shutdown 2 and Run 3 from the current COOL Conditions data model to a new data model called CREST for Run 4, it is important to identify the problematic Conditions queries with low caching efficiency and work with the detector subsystems to improve the storage of such data within the current data model.
For this purpose ATLAS put together an information aggregation and analytics system. The system is based on aggregated data from the Squid-Frontier logs using the Elasticsearch technology. This paper § describes the components of this analytics system from the server based on Flask/Celery application to the user interface and how we use Spark SQL functionalities to filter data for making plots, storing the caching efficiency results into a Elasticsearch database and finally deploying the package via a Docker container.
Introduction In HEP experiments we use the term Conditions data to refer to non-event data representing the detector status (e. g. calibrations and alignments, data taking conditions and similar). These data are essential for the processing of physics data, in order to reconstruct events optimally and to exploit the full detector's potential. In the ATLAS experiment  [1]  at the LHC these data are stored in relational DB (Oracle), using a model based on the LCG Conditions database infrastructure and the COOL API, both developed mainly by CERN IT  [2]. During data processing these Conditions data are accessed worldwide by thousands of jobs in parallel, which requires a solid architecture for their distribution and access.
Access to Conditions data in ATLAS ATLAS utilizes the Frontier  [3]  system, a Java based application serving Conditions data via HTTP access, and allowing an optimal caching of previously requested data via Squid proxy. The caching performance is determined by the capability of the client to reproduce exactly the same SQL request for the same data loaded. We can see in Figure  1  a schema of the distributed architecture which is used by ATLAS. Each Tier 1 site (CERN, CC-IN2P3 in France, RAL in the UK and TRIUMF in Canada) in which the Frontier system is deployed has a Filebeat service running to transmit the Frontier log file lines to the Logstash service running at CERN. The Logstash process extracts part of the logging information and sends these data to the Elasticsearch  [4]  platform hosted by the University of Chicago, where the information is then stored in well organized indexes for further analysis  [5].
Frontier analytics project The Squid-Frontier system suffered from service degradation leading to failures in particular workflows; the overlay of the underlying event from real data onto the simulated data and other specialised reprocessing. Requests from these workflows were much less likely to be found in the cache (i. e. low caching efficiency). Using Frontier logs we could extract the SQL requests and re-play them on a separate Frontier instance or via COOLR service. The exercise allowed us to determine that several requests were accessing the same payload data but using slightly different SQL requests (essentially the time range selection was different between different jobs). This behaviour indicates that the client is performing an access which may lead to an overload of the caching system because the same data are requested from Oracle (via Frontier) in different ways.
Architecture The application consists of a set of services. The main entry point is a REST API implemented in Python using a Flask  [7]  web server, allowing a given task to be selected and to submit a request for the retrieval of monitoring data from the Elasticsearch index. The request is executed asynchronously by a Celery  [8]  service. Communication between the Flask web server and Celery is performed via Redis  [8]. Once the data are loaded an additional step is performed to merge the collected SQL queries with metadata coming directly from the COOL database at CERN. This step is important to better understand which type of data was requested in each SQL query performed by Frontier. A web application developed in JavaScript Bootstrap allows then to visualize summary results on the queries associated to that task.
Deployment The whole application code is stored in a gitlab repository at CERN. A continuous integration job allows the Flask and Celery based services to be packaged inside two different Docker images, which are then used for the deployment. It has been decided that because of the tight interactions with the Elasticsearch service, the best deployment location is the University of Chicago. Here a cloud infrastructure is available, and the Kubernetes  [9]  orchestrator can be used to manage clusters of machines. The Docker images have been deployed at the University of Chicago for production usage. The application is running on https://frontier. uc. sslhep. org. A similar infrastructure was set up at CERN in a small private Kubernetes cluster, for integration purposes. A summary sketch of the deployment cycle is illustrated in Figure  3.
Results The user interface of the service allows the input data to be filtered and the Parquet files  [10]  to be prepared based on the task IDs that are selected from those problematic workflows. The input data is stored in the Elasticsearch database by extracting the relevant information from the Frontier server log files via the Filebeat and Logstash services  [5]. The Parquet is a columnar storage file format on which we run Spark  [11]  SQL functionalities to filter data for making plots. Then we visualize the data in the form of plots in four categories: 1. The count of cached and not-cached queries per database instances, the type of the notcached queries (first time queries vs. disconnected queries), the count of queries per COOL data schema, the percentage of cached vs. not-cached queries per COOL data schema and the percentage of the queries per node for a given COOL data schema.
2. The time distribution of the queries (wall time and query time). 3. The response size (payload data) of the queries, the percentage of the response size per COOL data schema and the percentage of the response size per node for a given COOL data schema. 4. The count of queries with high processing time (e. g. more than 1 s. ) per COOL data schema and per node for a given schema. As an example two such plots can be seen in Figures  4  and 5  for a proton-lead overlay task. The plot in Figure  4  shows the percentage of the queries (cached vs. not-cached) per COOL data schema and the plot in Figure  5  shows the count of queries with high processing time per node for the ONL_SCT schema which has a high rate of the not-cached queries as seen from the plot in Figure  4. The ONL_SCT is a schema from the online system filled in by the Semiconductor Tracker (SCT) which is a part of the ATLAS inner detector.
Conclusions An application has been developed to analyse the problematic Conditions data access patterns in several workflows in ATLAS. This application benefits from the existing monitoring infrastructure at the sites where the Squid-Frontier system is set up, thanks to all the experts at these sites; CERN, CC_IN2P3 Lyon in France, TRIUMF in Canada, RAL in the UK, and the University of Chicago in the USA. The application will be used by the experts in order to improve the Conditions access stability for the current operations through the LHC Long Shutdown 2 as well as to design a more cache-friendly system for Run 3. In particular the identification of COOL folders for which the impact of the caching efficiency is most significantly affecting the Squid-Frontier system can be addressed by improving the client access with better parameters for the default interval length used in the queries.
Design Process The SafePlan app was built using an agile software development approach  [22]. The agile methodology is an incremental model of app development where requirements are planned and delivered in short, fixed-length time slots, also known as sprints or iterations  [23]. Application requirements are established and refined through active user involvement within the software development process. In this case, external clinicians were recruited to fulfill the role of the user because of the sensitive nature of SafePlan's target audience. Once the initial app requirements were gathered, they were prioritized into a feature backlog based on their importance and completeness, that is, a proposed app feature was placed toward the bottom of the backlog if it was not yet fully defined. The sprints were typically 2-3 weeks in length and contained a number of stages (Figure  1 ).