dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgments We thank the two anonymous referees and the editors of Agricultural Systems for their useful comments that helped improve this manuscript. This research was supported by a project grant from the  Bill and Melinda Gates Foundation , on understanding livestock yield gaps for poverty alleviation, food security and sustainability (LiveGAPS). We also extend our thanks to the  CGIAR Research Program on Climate Change, Agriculture and Food Security (CCAFS)  for providing all data used in the research as well as support in interpreting this data.
Laser Interferometer Measurements The LI is one of the appliances used to estimate the residual error map of the machine tool. Then, fewer linear trajectories are defined in the whole working volume, which is discretized, as a 3D mesh as shown in Figure  7. Once the different elements of the LI are aligned, the positioning error and the vertical and horizontal straightness are measured three times for each of the N points of the trajectory, even if the repeatability of the appliance is acceptable. These length data are used to evaluate the components of the error vector. For that purpose, different optics are used and the ISO 230-2 standard provides the experimental protocol to measure the errors of the linear axes. Due to the dead-zone, counter initialization at the first node of the line is required.
Sequential Multilateration Measurement Using a TL From an experimental point of view, data acquisition is easier with the TL than with the LI. The measurement process is faster but data analysis is more complex. The coordinates in the machine tool reference frame of N points Mi (xi, yi, zi), with i = 1 to N, are estimated using the multilateration technique. For this purpose, a set of four lengths Lij is defined for each point Mi, corresponding to four positions j of the TL. Equation (  4 ) defines the mathematical relationship between the measured length Lij, the coordinates of the different TL positions, the four respective dead-zones (DZj) and the coordinates of the points Mi. TLj (xTLj, yTLj, zTLj) is the TL location for position j. Once the different elements of the LI are aligned, the positioning error and the vertical and horizontal straightness are measured three times for each of the N points of the trajectory, even if the repeatability of the appliance is acceptable.
These length data are used to evaluate the components of the error vector. For that purpose, different optics are used and the ISO 230-2 standard provides the experimental protocol to measure the errors of the linear axes. Due to the dead-zone, counter initialization at the first node of the line is required. Once the error vector of all the nodes is estimated, the residual error map is computed. The norm of each error vector is then calculated, and its mean value is finally defined. Equation  (3)  shows the norm of the error vector (re i ), where pe i , sv i and sh i respectively refer to the positioning error and the vertical and horizontal straightness values measured at the point M i (1 ≤ i ≤ N) of the compensated trajectory. re i = pe i 2 + sv i 2 + sh i 2. ( 3 ) The weakness of this method is the misalignment between the y-axis and the LI axis.
) i H D is the th i D one- dimensional Hermite polynomial. The coefficients a ȕ of the PCE are computed in this paper using a non-intrusive technique where the deterministic calculations are done using the finite difference software FLAC 3D treated as a black box. The most used non-intrusive method is the regression approach  (Blatman and Sudret, 2010). This method is used in the present work. In fact, for a PCE of order p, only the multivariate polynomials E < of degree less than or equal to p should be retained. This leads to a number P of the unknown PCE coefficients (see Equation (  6 )) equal to ( )! ! ! M p M p. It should be noticed that the number of the PCE coefficients to be computed grows dramatically with the size M of the input random vector and the PCE order p. When dealing with a random field as is the case in the present paper (and especially when considering small values of the autocorrelation distance), the discretization of the random field may lead to a significant number of random variables which makes the determination of the PCE coefficients unfeasible because of the significant increase in the number of calls of the deterministic model.
Conclusions A probabilistic analysis of a vertically loaded strip footing resting on a spatially varying rock mass has been performed to compute the ultimate bearing capacity. The rock was assumed to follow the generalized Hoek-Brown failure criterion. The uniaxial compressive strength of the intact rock (ı c ) was considered as a random field and the Geological Strength Index (GSI) was modeled as a random variable. The uncertainty propagation methodology employed in the analysis makes use of a non-intrusive approach to build up a sparse polynomial chaos expansion for the system response. Also, a global sensitivity analysis based on Sobol indices was performed. The deterministic model was based on numerical simulations using FLAC 3D software. The probabilistic numerical results were presented in the case of a weightless rock mass.
Acknowledgements We are indebted to  J. Bouma ,  T. Pinkert  and  R. Kortekaas  for technical assistance, and to  V. Korobov ,  E. Hudson  and  R. Gerritsma  for fruitful discussions. We thank  E. Salumbides  for providing the curve for D 2 in Fig. 4. This research was funded through the  Netherlands Foundation for Fundamental Research on Matter (FOM) , the COST action MP1001 IOTA, and the  Dutch-French bilateral Van Gogh Programme. SURFsara (www. surfsara. nl) is acknowledged for the support in using the Lisa Compute Cluster for MD simulations. J. C. J. K. thanks the  Netherlands Organisation for Scientific Research (NWO)  and the  Netherlands Technology Foundation (STW)  for support.
On the basis of the scoping exercise, we chose to include research methodologies, data collection methods, and triangulation methods in our review. We excluded data analysis methods from the review, e. g. , coding, primarily because of the lack of detail provided in manuscripts, making it difficult to record methods in a manner amenable to our review approach. For example, it was not uncommon to read simply "data were analyzed," or "We used NVivo to analyze the data. " Cells in the worksheet were left blank if the author/s of the manuscripts did not provide details corresponding with the criteria. Each manuscript included in our assessment was assessed against this final list of criteria. In the event that a manuscript contained detail on the research position (i. e. , epistemology), methodology, and methods that were not included as part of the final set of criteria, free-form text was recorded (see Table  A1.
Data and Measurement One of the advantages of the paper is that it relies heavily on administrative records. The main source of data are the admission records from the COMIPEMS assignment process of the year 2014 that allow us to observe the full ranked list of schooling options requested, the score in the admission exam, the cumulative GPA in middle school, and placement outcomes. We link these records to the socio-demographic survey filled out at registration, which provides us with variables such as gender, age, household income, parental education and occupation, personality traits, and study habits, among others. We further match administrative individual records for the academic year 2014-2015 to obtain information on attendance and grades by subject for those applicants enrolled in their assigned high school.
This proposition takes the tracking of defects into account at every step. It integrates software quality assurance processes including code peer reviews and automated software testing. It finally includes an approach designed to ease the correction of defects detected by these procedures. We implement this approach to evaluate it in the framework of the development of the Gysela  [2, 10, 19]  code. This is not the first time these aspects are studied in the field of HPC scientific simulation software. There are indeed workshops entirely dedicated to the question 1 and some work identify lists of best-practices for quality in HPC scientific simulation software  [13]. Some communities have also already implemented quality procedures such as the climate modeling community in the form of an automated testing process known as the "trusting process"  [4].
There are tools to handle this aspect in the form of dedicated databases known as bug (or more generally "issue") trackers. Well known examples are for instance Bugzilla, Trac or Jira 5. Issues can be used to track defects, but also more general requirements of the code such as non-functional behavior or missing features. The issue trackers provide a database of issues with metadata associated to each issue such as for example a category, a list of revisions impacted or comments by the users. They also offer an interface to interact with this database, typically in the form of a web interface. Software forges integrates tools (including issue tacking) around a VCS in the form of a website. Some are provided as a service such as SourceForge or GitHub while others are provided as a software that one can install on its own server such as FusionForge or GitLab 6.
Another classification can be made between forges that are VCS agnostic such as SourceForge or FusionForge and those that are closely linked to a specific VCS, Git in the case of GitHub or GitLab. In our opinion, this second category is much more interesting as it can support a close integration between the various tools of the forge. On both GitHub and GitLab, one can for example directly interact with the issue database from Git and mark an issue as solved in a specific revision on the code by using a dedicated tag in the commit message. To support the work-flow proposed in this paper, we have made the choice to rely on Git as it seems to be one of the most popular free and open-source DVCSs  [3, 22]. In order to be able to retain the control of our data, we have chosen to use a forge that can be installed locally.
Work-flow Many work-flows have been designed around Git to formalize the way to use it, such as for example gitflow  [8] , the GitHub Flow  [12]  and the GitLab Flow  [21]. A common property of all these work-flows is that they rely on the concept of feature branch. A feature branch starts from the shared development branch, focuses on the implementation of a well identified feature only and is destroyed as soon as it is merged back in the shared development branch. The advantage of this approach is that is enables to record intermediate steps of the development of a feature without impacting any shared branch with unfinished work. 2 The page https://en. wikipedia. org/wiki/List_of_version_control_software provides a more exhaustive list of both centralized and distributed VCSs 3 Automated merge typically relies on the diff and patch tools for text files that consider two changes compatible if they affect far enough lines and require human intervention otherwise.
This requires the developers to strictly follow complex procedures and can lead to defects in the code if these are not correctly applied. In the case of HPC scientific simulation software for example, there is no need to distinguish between the release, production and hotfix branches. Finally, the GitLab flow offers an interesting discussion on the two previous work-flows and proposes interesting strategies to handle common problems, but since its purpose is to tackle a large range of cases, it does not define a single well formalized work-flow. These observations have lead us to propose the HPCSSS Gitflow with the specificities of HPC scientific simulation software in mind. It is based on the previously presented work-flows and can be understood either as a simplified git-flow or as the GitHub flow with support for releases.
This pleads in favor of code reviews as frequent as possible to ensure that the amount of change to review remains reasonable. We therefore propose to apply these procedures whenever a feature branch is merged in the integration branch. Other static tests that are not mentioned in the table consist in static code check. This category of tests check that the code complies with pre-defined quality standards and avoid well-known mistakes. There is a large range of tools that implement this kind of tests, especially those based on the CLang compiler front-end  8. Unfortunately, the HPC scientific simulation software are in large part implemented in Fortran for which the CLang-based tools provide no support; as a matter of fact, there is a scarcity of tools for this language. A static test that can be applied for most language do however exist in the form of compilation: it tests whether the code can indeed be compiled and the list of errors and warnings generated by the compiler.
There are however ways to use both model that do not provide reproducible execution in practice such as sharing a variable with locking in OpenMP or using one-sided communications or polling to handle messages in their reception order rather than in a pre-defined order in MPI. There is no general way to make programs using such strategies bit-reproducible, in most cases however the parallelism does not induce non-reproducibility. The last source of non-reproducibility is due to rounding approximations that change for floating-point number depending on the ordering of operations. Operation reordering are applied for optimization purpose and can mostly be linked to two sources. The first is the compiler and the second are libraries that offer high-level operations such as reductions. Regarding compiler reordering, it would sound logical that as long as a piece of code is not changed, the binary does not change either thus leading to the exact same computations and results at run-time.
Tools Tools exist that support both human code review and automated testing. Gerrit or Review Board are well known examples of code review tools 10  but there is also one directly provided with GitLab that we have therefore chosen to use. When a branch is proposed for integration in another (a "merge request" in the GitLab terminology), these tools offer a web-page to display the difference between both branches and offer a comment system to make remarks and suggest improvements. The GitLab tool supports both comments that are either global or associated with a specific line of code as presented on Figure  3. Comments of this category are automatically hidden if the code line is later modified so as not to pollute the review page with outdated comments. Automated tests on the other hand could be implemented with simple tools such as cron and shell scripts but there are platforms specifically designed to integrate them in VCS-based work-flows.
The description of the test itself can be split in subparts that define: (1) how to download the data required for the test (source, input parameters, expected results, etc. ), (2) on which execution machine to run the test, what to execute, (4) and how to report the result. Once again, the developer work is simplified by pre-defined tools that typically support download from multiple sources, including VCSs, description of tests in specific formats or as general purpose batch scripts and many ways to report the result of execution, on the platform website, via emails or what might be the most interesting, on the merge request page of GitLab, thus providing direct feedback on the opportunity of its acceptation. The tools also act as batch schedulers by queuing the tests to execute and only issuing one (or more if so specified) test at a time on each execution machine.
Execution trace comparison In order to circumvent this limitation, we propose another complementary approach to identify the location of a defect. This approach compares the execution of two versions of the code, one where the defect is absent and one where it appeared. Each version of the code is run in the same configuration and a trace of these executions is written, following the most important variables as they are modified. This allows to pinpoint when exactly the results start diverging. The more similar the versions are, the best result the approach gives and it is thus typically used to compare the closest versions possible as identified by the Git bisect strategy. In order to compare the two executions, we have designed a dedicated library called Cktrace. The library provides a macro DBG_CKSUM_PRINT(var) to instrument the code 12  as demonstrated on Figure  4a.
grep allows to filter out lines concerning non looked for aspects (such as file name and line numbers in a first time) while diff allows to identify difference between the result of this filtering. A work in progress is to move to a somewhat more structured file format (json is foreseen) in order to provide a more integrated difference identification tool. The limitation of this approach is that the location of a change can only be pinpointed at the granularity of the code executed between two calls to the Cktrace instrumentation macro. This means that in order to accurately locate a defect, extensive instrumentation of the code is required. Unfortunately, such an amount of instrumentation can make the code less readable. In order to be able to provide extensive instrumentation of the code while not impacting its readability, we limit this instrumentation to a dedicated branch.
Applying the proposed approach to the Gysela code We have applied the approach presented in the previous sections to the Gysela code. This section presents this experiment and offers feedback on this experience. We first describe the code and the platform we have set-up and we characterize the testing domain. Then we present the four categories of tests implemented: static tests, bitwise comparison, unit tests and full system tests. Finally, we discuss this experiment, the gains and costs of the approach.
Gysela however relies on the gyrokinetic approach that reduces this dimensionality and thus the amount of memory and computation required. The result is an advection solver that works in "only" 5 dimensions. This requires the addition of a gyroaverage operator in the coupling between the advection and quasi-neutrality solver. The code base is not overwhelmingly large with about 60 k lines of Fortran90 and 13 k lines of C code. As for most 5D gyrokinetic codes however, the amount of computing power required for runs of Gysela leads to the usage of the largest existing computers. Runs of Gysela have lasted up to a full month on a complete supercomputer (Jade at CINES, France) and runs on the full Juqueen (Jülich, Germany) machine have demonstrated a good scalability with a 91% relative efficiency at 1 835 008 threads compared to 65 536.
To achieve such parallel efficiency, advanced numerical schemes are used and the parallelization (using MPI and OpenMP) represents a large part of the code-base, tightly coupled with the physics related code. This makes the resulting code difficult to write or even understand for both physicists, applied mathematicians and computer scientists. As many research codes, Gysela is used as a testbed for new physics and numerical schemes. Multiple alternative or optional algorithms have been integrated and accumulated in the code over its more than 10 years of history. Ensuring that all the combinations remain functional becomes a challenge. This is even more true since new algorithms and parallelization approaches are developed everyday, making the code a fast moving target. There have been more than 174 k line modifications distributed over more than 1700 commits (excluding merge) in the core repository over the last year.
Platform setup The platform we use to implement the described approach consists in an installation of GitLab hosted by Maison de la Simulation  14  and in an installation of Jenkins provided by CI-Inria 15. We use GitLab to store our issue database and for merge requests where we apply a human code review process as described in Section 2. 3. Together with Jenkins, CI-Inria offers virtual machines (VMs) used as execution machines. The CI-Inria platform provides each project with its own independent Jenkins instance with full administrative rights which enables to use distinct execution machines with specific credentials for each project. We have therefore been able to also use the Poincare cluster of Maison de la Simulation (IDRIS, Orsay, France) as an additional execution machine and to connect Jenkins to our GitLab so that tests are launched automatically whenever a merge request is made on GitLab.
The results of tests execution is also made accessible as a comment on the merge request thus making GitLab the main entry point for developers. The provided VMs can be configured with either one or two cores running at 1 or 2 GHz each and with 1, 2 or 4 GB of RAM. They are also completely administered by members of the project (root access). We have chosen to use the largest possible configuration (2 × 2 GHz + 4 GB RAM) which in the context of HPC remains small. The OS we use is Debian GNU/Linux that provides all the software dependencies of Gysela (GCC and GFortran compilers, OpenMPI and HDF5). This does however not match production environments where software specifically tailored for the hardware is usually available (especially for the compiler and MPI library). Multiple VMs with distinct software can be created to test a larger range of case, however since none of them would really match production configurations we did not explore this approach.
These VMs have not been designed to be interconnected through the network and we do not use multiple VMs together for the execution of parallel MPI jobs. We have created 4 VMs however, but only in order to accelerate the testing process by running distinct tests on multiple VMs in parallel. Poincare is a cluster of 92 dual E5-2670 Sandy Bridge nodes (2 × 8 cores at 2. 6 GHz) with 32 GB RAM each, connected by a QLogic QDR Infiniband interconnect. The software environment is managed through the module command that provides the Intel compiler, intelmpi and HDF5 thus satisfying all Gysela dependencies. This is much closer to production environments than the VMs. In order to take into account the shared nature of Poincare and disturb other users the least possible, we currently limit our use of this platform to 4 tests in parallel and only submit parallel tests during the night.
The Jenkins software is sometimes complex to use, especially when it comes to its administration for installing plugins or connecting with other tools such as GitLab. While connecting to the VMs is well integrated in the CI-Inria platforms, using other execution machines also requires to figure out tricky technical details, integration with the batch scheduler of shared machines is still work in progress. Overall the installation of GitLab from scratch and the configuration of both Jenkins and the execution machines to support all tests described here required an investment of time that can be estimated to around one month of full-time work for a single engineer. This was however not done at a single time but as an incremental work where each new test required additional work, the initial investment to get a simple merge request procedures with compilation work only required a few days.