dataesr/scientific-paragraphs-categorization huggingface dataset:
Simulation study A simulation study was carried out to check that STPGA can optimize the D criterion. Its R code can be found in Supporting Information. In this study, the population consisted of a theoretical pedigree comprising 80 individuals, which reproduced by outcrossing and which were divided into 10 unrelated families (see online Appendix C for more information). The candidate and target sets both comprised all the individuals. Sample size was either equal to 10 or to 70. Breeding values were modeled using the pedigree. In total, 80 design searches were carried out with different values of variance components in cases when optimal/efficient designs were known. For example, when n = 10, sampling the individuals of the last generation was optimal (Section 4. 1). STPGA performed rather well since it always generated designs as efficient as the reference designs, except in two cases.
Simulation study 5. 2. 1 Experimental setup. The influence of sample size and the genetic architecture of the trait on sampling was studied by means of simulations. The R code of this study can be found in Supporting Information. For the sake of simplicity, the experimental setup had a smaller size than real association studies: the population was composed of 16 individuals, genotyped at 18 loci. The candidate and target sets both consisted of the whole population. The population was divided into 4 subpopulations comprising 4 individuals. Allele frequencies varied between subpopulations (see online Appendix E for more information). Each locus was assumed to be at Hardy-Weinberg equilibrium in each subpopulation. Genotypes were simulated independently between individuals and between loci, that is, there was no linkage disequilibrium.
Acknowledgements This study was funded by the  French BASC project Itemaize. The authors are grateful to the  INRAE MIGALE bioinformatics facility (MIGALE, INRAE, 2020. Migale bioinformatics Facility , doi:  10. 15454/1. 5572390655343293E12 )for providing computing resources. The authors thank the associate editor and the three referees for their helpful comments. They also thank  Gail Wagman  for improving the English of the article. This is the accepted version of the following article: David, O. ,  Le Rouzic , A. , Dillmann, C. ( 2021) Optimization of sampling designs for pedigrees and association studies. Biometrics, which has been published in final form at https://doi. org/10. 1111/biom. 13476. This article may be used for non-commercial purposes in accordance with the  Wiley Self-Archiving Policy  (http://www.
Step 5: Apply the Monte Carlo stochastic sampling simulation to propagate the parameter uncertainty within specific intervals by the uniform probability distribution. Besides, the values of the characteristic parameters are recorded and stored as the input data for correlation analysis. Step 6: Repeat the FEM computation and transfer the resonant frequencies of graphene as the output data. Step 7: Based on the huge stochastic sample spaces of input and output data, the Pearson correlation coefficient and Spearman correlation coefficient are calculated. It is important to be mentioned that for the Monte Carlo stochastic sampling method in Step 5, the Latin Hypercube sampling (LHS) method is performed to ensure the sampling efficiency and reduce computational costs. By dividing the range of each variable into disjoint intervals with equal probabilities, the samples are randomly selected from each interval.
Acknowledgements The authors gratefully acknowledge the financial supports from the  National Natural Science Foundation of China  (Grant No. 12102203 ,  61901235 ), the  Natural Science Foundation of Jiangsu Province  (No. BK20200971 ), the  Natural Science Foundation of High Education in Jiangsu Province  (No. 19KJB130001 ) and also  Large Instruments Open Foundation of Nantong University.
We consider two sets of instances, i. e. , Erdös-Rényi graphs defined according to a specified edge probability (see Section 4. 1), and the classical DIMACS instances commonly used to test the performance of coloring algorithms (see Section 4. 2). The BP algorithm was implemented in C++ by using the API provided by SCIP and using CPLEX to solve the linear relaxations. The pricing problems are solved by the combinatorial branch-and-bound algorithm for MWSS proposed by Held, Cook and Sewell  [10]. Our experimental environment is a desktop PC running Linux with an Intel Core i7-3770 processor at 3. 40GHz and 8Gb RAM. For all formulations, the upper bound on the strength of the graph is set to k = ∆(G) + 1. The initial set of variables of the RMP must contain a feasible solution in order to start the CG procedure, see Section 3.
On the other hand, papers with any form of empirical evaluation would likely benefit from being reviewed as Registered Reports. Of course, it should be up to the authors to choose which format they prefer. As an example, an author who wants to publish a novel technique or system with an evaluation would submit a first-stage Registered Report that contains an introduction of the problem the new system or technique is intended to solve, an overview of related work, a full description of the novel system or technique (ideally with an implementation available for reviewers to try it), and a final section detailing how the empirical evaluation will be conducted, what data will be collected and how the data will be analyzed. As another example, if an author wants to compare existing techniques or conduct a study that does not involve any new technique, their Registered Report would contain all the sections previously mentioned with the exclusion of the section on the novel system or technique.
Timing Once the reviews for the alt. VIS workshop are released, we will use the feedback from our reviewers to improve our survey design, our data analysis plan, and our quasi Registered Report (this article). We will then submit our study protocol for ethics approval, and post the revised quasi Registered Report as a preprint linked to our OSF repository. Once we receive ethics approval, we will immediately start data collection. Soon after the alt. VIS workshop and after the survey is closed, we will publish a third and final version of this manuscript that includes all of our results and our final conclusions. In order to remain as close as possible to a Registered Report, we will send our last revision to the workshop organizers for approval,  if they agree to do so (see letter to workshop organizers submitted together with this article).
Survey The current draft of our survey is available for review on our repository (osf. io/4nrma/). It currently consists of five different pages. The first page details the aim of the survey and asks for the participant's informed consent. The second page aims to gather participants' research experience through Likert items, asking them, for example, how long they have been active in the visualization community. The third page asks participants if they know what a Registered Report is, before giving, on the fourth page, the definition of Registered Reports according to the Center for Open Science. After having been explained what Registered Reports are, participants are invited to answer four Likert items to assess: Q1 how helpful they think it would be to have their study design reviewed before data collection, Q2 how willing they would be to submit a Registered Report, Q3 how willing they would be to review a Registered Report, Q4 how interested they would be in having Registered Reports as a publication option in the visualization community.
Introduction A major trend in system and software development relates to DevOps, closely followed in time by DevSecOps. DevOps is about breaking the siloes between development, quality assurance and operations, to ensure continuous integration and delivery. A short history of DevSecOps  [1]  recalls that the first spark for DevOps was given in 2009, by a Flickr talk  [2] , promoting the lowering of risks of change with automation tools, and an adequate enterprise culture. In 2015, DevSecOps put the spotlights on security, recalling that security should be given precedence over new features  [3] , and stressing that security is not under the responsibility of the sole security experts. These approaches have been immensely popular, and commercially successful, especially related to automation.
g. , Carnegie Mellon  [28] ) and even industry (e. g. , Mozilla  [29] ) or associations (e. g. , CLUSIF  [30] ). Amongst these, only a few processes (e. g. , ISO 3100  [31] ) and methods (e. g. , the EBIOS Risk Manager  [9] , OCTAVE ForTE  [28]  or RRA  [29] ) really encourage joint work as a key factor of success. None provide practical details on how to facilitate brainstorming sessions involving general engineers, management or legal staff, in addition to security experts. The need to equip these methods is only greater, and several proposals have been suggested, e. g. ,  [32] [33] [34]. These tools are software solutions based on knowledge bases, allowing easy access to threats or security measures present in the standards and literature  [35]. They also allow automating specific tasks.
However, these tools do not help end-users understand the fundamentals of a method, and even less address the required soft skills. Many people imagine that buying a tool will help them correctly implement the method. It is a lure. Software solutions support many options, offer a wide range of databases, and are usually highly configurable. Adapting them to your needs requires some significant experience and does not always allow for a proper understanding and consideration of each other's concerns. The topic of soft skills, and the underlying collaboration between actors, recently emerged as a need in project management at large, and for risk management in particular  [36] [37] [38] [39]. According to Crawford et al. [40] , employers are beginning to focus more on behaviours or what are often referred to as soft skills in addition to, or in some cases rather than, hard technical skills.
Results Obérisk is a tool-up approach to the French EBIOS Risk Manager  [9]  method. Understanding the pros and cons of Obérisk requires some knowledge of the method. This paper does not aim to present or promote the EBIOS Risk Manager method; however, we provide an overview of the method's key features in Appendix A to allow for a self-contained article. In this section, we also recall the main goals of each workshop before presenting the Obérisk features related to that workshop. Obérisk is made available in the form of PowerPoint™ slides under the CC BY-NC-SA (i. e. , Creative Commons Attribution + Non-Commercial + Share Alike) licence. The Obérisk package includes a set of datasheets, a user guide and a full-blown example. The datasheets and example are in English. The user guide is in French.
• At the top, the organizational assets, such as human resources and their structuring; • In the middle, Information Technology (IT) or Operational Technology (OT) assets, covering hardware, software and networks; • At the bottom are significant physical assets used but are not usually an integral part of the system-under-study; this includes premises where the system-under-study is located and large infrastructures used by the system-under-study, e. g. , the World Wide Web. It is often practical for the IT/OT supporting assets to copy-paste a functional architecture schema on the Obérisk datasheet and annotate the architecture with sticky notes where and when required. On the first Obérisk datasheet, we saw that Section 3 was dedicated to applicable regulation, policies and security standards.
Analysis pipelines commonly use high-level technologies that are popular when created, but are unlikely to be readable, executable, or sustainable in the long term. A set of criteria is introduced to address this problem: Completeness (no execution requirement beyond a minimal Unix-like operating system, no administrator privileges, no network connection, and storage primarily in plain text); modular design; minimal complexity; scalability; verifiable inputs and outputs; version control; linking analysis with narrative; and free software. As a proof of concept, we introduce "Maneage" (Managing data lineage), enabling cheap archiving, provenance extraction, and peer verification that been tested in several research publications. We show that longevity is a realistic requirement that does not sacrifice immediate or short-term reproducibility.
The caveats (with proposed solutions) are then discussed and we conclude with the benefits for the various stakeholders. This paper is itself written with Maneage (project commit eeff5de). Appendices -Two comprehensive appendices that review the longevity of existing solutions; available after main body of paper (Appendices A and B). Reproducibility -All products in zenodo. 4291207, Git history of source at gitlab. com/makhlaghi/maneage-paper, which is also archived in SoftwareHeritage.
I. INTRODUCTION Reproducible research has been discussed in the sciences for at least 30 years  [1] ,  [2]. Many reproducible workflow solutions (hereafter, "solutions") have been proposed that mostly rely on the common technology of the day, starting with Make and Matlab libraries in the 1990s, Java in the 2000s, and mostly shifting to Python during the last decade. However, these technologies develop fast, e. g. , code written in Python 2 (which is no longer officially maintained) often cannot run with Python 3. The cost of staying up to date within this rapidly-evolving landscape is high. Scientific projects, in particular, suffer the most: scientists have to focus on their own research domain, but to some degree, they need to understand the technology of their tools because it determines their results and interpretations.
II. LONGEVITY OF EXISTING TOOLS Reproducibility is defined as "obtaining consistent results using the same input data; computational steps, methods, and code; and conditions of analysis"  [2]. Longevity is defined Manuscript received MM DD, YYYY; revised MM DD, YYYY. as the length of time that a project remains functional after its creation. Functionality is defined as human readability of the source and its execution possibility (when necessary). Many usage contexts of a project do not involve execution: for example, checking the configuration parameter of a single step of the analysis to re-use in another project, or checking the version of used software, or the source of the input data. Extracting these from execution outputs is not always possible. A basic review of the longevity of commonly used tools is provided here (for a more comprehensive review, please see appendices A and B).
The former has the same longevity as the OS, while some of the latter (such as Conda and Spack) are written in high-level languages like Python, so the PM itself depends on the host's Python installation with a typical longevity of a few years. Nix and GNU Guix produce bit-wise identical programs with considerably better longevity; that of their supported CPU architectures. However, they need root permissions and are primarily targeted at the Linux kernel. Generally, in all the package managers, the exact version of each software (and its dependencies) is not precisely identified by default, although an advanced user can indeed fix them. Unless precise version identifiers of every software package are stored by project authors, a third-party PM will use the most recent version. Furthermore, because third-party PMs introduce their own language, framework, and version history (the PM itself may evolve) and are maintained by an external team, they increase a project's complexity.
With the software environment built, job management is the next component of a workflow. Visual/GUI workflow tools like Apache Taverna, GenePattern (deprecated), Kepler or VisTrails (deprecated), which were mostly introduced in the 2000s and used Java or Python 2 encourage modularity and robust job management. However, a GUI environment is tailored to specific applications and is hard to generalize, while being hard to reproduce once the required Java Virtual Machine (JVM) is deprecated. These tools' data formats are complex (designed for computers to read) and hard to read by humans without the GUI. The more recent solutions (mostly non-GUI, written in Python) leave this to the authors of the project. Designing a robust project needs to be encouraged and facilitated because scientists (who are not usually trained in project or data management) will rarely apply best practices.
g. , PDF or HTML. (8)  It can run automatically, without human interaction. Criterion 2: Modularity. A modular project enables and encourages independent modules with well-defined inputs/outputs and minimal side effects. In terms of file management, a modular project will only contain the hand-written project source of that particular high-level project: no automatically generated files (e. g. , software binaries or figures), software source code, or data should be included. The latter two (developing low-level software, collecting data, or the publishing and archival of both) are separate projects in themselves because they can be used in other independent projects. This optimizes the storage, archival/mirroring, and publication costs (which are critical to longevity): a snapshot of a project's hand-written source will usually be on the scale of ×100 kilobytes, and the version-controlled history may become a few megabytes.
In terms of the analysis workflow, explicit communication between various modules enables optimizations on many levels: (1) Modular analysis components can be executed in parallel and avoid redundancies (when a dependency of a module has not changed, it will not be re-run). (2)  Usage in other projects. (3)  Debugging and adding improvements (possibly by future researchers). (4) Citation of specific parts. (5)  Provenance extraction. Criterion 3: Minimal complexity. Minimal complexity can be interpreted as:  (1)  Avoiding the language or framework that is currently in vogue (for the workflow, not necessarily the high-level analysis). A popular framework typically falls out of fashion and requires significant resources to translate or rewrite every few years (for example Python 2, which is no longer supported).
IV. PROOF OF CONCEPT: MANEAGE With the longevity problems of existing tools outlined above, a proof-of-concept solution is presented here via an implementation that has been tested in published papers  [8] ,  [9]. Since the initial submission of this paper, it has also been used in zenodo. 3951151 (on the COVID-19 pandemic) and zenodo. 4062460. It was also awarded a Research Data Alliance (RDA) adoption grant for implementing the recommendations of the joint RDA and World Data System (WDS) working group on Publishing Data Workflows  [7] , from the researchers' perspective. It is called Maneage, for Managing data Lineage (the ending is pronounced as in "lineage"), hosted at https://maneage. org. It was developed as a parallel research project over five years of publishing reproducible workflows of our research.
Its primordial implementation was used in  [10] , which evolved in zenodo. 1163746 and zenodo. 1164774. Technically, the hardest criterion to implement was the first (completeness); in particular restricting execution requirements to only a minimal Unix-like operating system. One solution we considered was GNU Guix and Guix Workflow Language (GWL). However, because Guix requires root access to install, and only works with the Linux kernel, it failed the completeness criterion. Inspired by GWL+Guix, a single job management tool was implemented for both installing software and the analysis workflow: Make. Make is not an analysis language, it is a job manager. Make decides when and how to call analysis steps/programs (in any language like Python, R, Julia, Shell, or C). Make has been available since 1977, it is still heavily used in almost all components of modern Unix-like OSs and is standardized in POSIX.
Acting as a link, the macro files build the core skeleton of Maneage. For example, during the software building phase, each software package is identified by a L A T E X file, containing its official name, version, and possible citation. These are combined at the end to generate precise software acknowledgment and citation that is shown in the appendices (C), for other examples, see  [8] ,  [9]. Furthermore, the machine-related specifications of the running system (including CPU architecture and byte-order) are also collected to report in the paper (they are reported for this paper in the acknowledgments). These can help in root cause analysis of observed differences/issues in the execution of the workflow on different machines. The macro files also act as Make targets and prerequisites to allow accurate dependency tracking and optimized execution (in parallel, no redundancies), for any level of complexity (e.
g. , Maneage builds Matplotlib if requested; see Figure  1  of  [5] ). All software dependencies are built down to precise versions of every tool, including the shell, important low-level application programs (e. g. , GNU Coreutils) and of course, the high-level science software. The source code of all the free software used in Maneage is archived in, and downloaded from, zenodo. 3883409. Zenodo promises long-term archival and also provides a persistent identifier for the files, which are sometimes unavailable at a software package's web page. On GNU/Linux distributions, even the GNU Compiler Collection (GCC) and GNU Binutils are built from source and the GNU C library (glibc) is being added (task 15390). Currently, T E XLive is also being added (task 15267), but that is only for building the final PDF, not affecting the analysis or verification.
Just before reaching the ultimate target (paper. pdf), the lineage reaches a bottleneck in verify. mk to satisfy the verification criteria (this step was not available in  [9] ). All project deliverables (macro files, plot or table data, and other datasets) are verified at this stage, with their checksums, to automatically ensure exact reproducibility. Where exact reproducibility is not possible (for example, due to parallelization), values can be verified by the project authors. For example see verify-parameter-statistically. sh of zenodo. 4062460. To further minimize complexity, the low-level implementation can be further separated from the high-level execution through configuration files. By convention in Maneage, the subMakefiles (and the programs they call for number crunching) do not contain any fixed numbers, settings, or parameters.
Parameters are set as Make variables in "configuration files" (with a. conf suffix) and passed to the respective program by Make. For example, in Figure  1  (bottom), INPUTS. conf contains URLs and checksums for all imported datasets, thereby enabling exact verification before usage. To illustrate this, we report that  [12]  studied 53 papers in 1996 (which is not in their original plot). The number 1996 is stored in demo-year. conf and the result (53) was calculated after generating tools-per-year. txt. Both numbers are expanded as L A T E X macros when creating this PDF file. An interested reader can change the value in demo-year. conf to automatically update the result in the PDF, without knowing the underlying low-level implementation. Furthermore, the configuration files are a prerequisite of the targets that use them.