dataesr/scientific-paragraphs-categorization huggingface dataset:
E. Synthesis The review of the state of the art, therefore, motivates a novel approach, referred to as CLOUDFACTORY, which aims to complement current progress in Cloud workloads by incorporating representative platform-scale workloads. Concretely, CLOUDFACTORY improves upon the existing stateof-the-art application generators by enabling their scaling at both node and cluster levels, while also adhering to high-level specifications of Cloud datasets. In this regard, our solution enables the generation of more realistic scenarios-i. e. , a set of specifications for a given Cloud platform-from a workload analyzer. This approach promotes the utilization and sharing of non-sensitive data, thereby enhancing the generalizability of the generator. III. CLOUDFACTORY OVERVIEW Figure  1  depicts an overview of the CLOUDFACTORY key components.
In particular, we focus on generating IAAS workloads that are representative of production-scale deployments but can be provisioned at any scale-from single compute nodes to cluster-wide platforms or simulators. To do so, we propose to convert raw datasets collected by Cloud providers into a compact set of IAAS statistics that are sufficient to deploy a production-like workload. Interestingly, this approach does not impose the disclosure of sensitive information from the perspective of Cloud providers, who can simply publish such cluster-wide statistics. It is the goal of the workload analyser component detailed in section IV. The workload generator leverages these statistics to generate a usable experiment workload, with the appropriate VM set and usage models. Implementation is detailed in section V.
IV. COMPUTE HIGH-LEVEL STATISTICS After deployment of a client-selected configuration, a VM enters its usage phase, during which resource utilization can vary substantially. This variability can be observed in different ways, ranging from complete idleness to periodic activity, bursty behavior, short lifespan, etc. To account for VM behaviors, we introduce our workload analyzer. This library builds a set of VM usage profiles from a Cloud dataset. The realism of workloads is contingent upon their ability to replicate the behavior of actual systems. While replaybased IAAS workloads meet this requirement, they are often impractical to implement-due to privacy restrictions that limit sharing options, which in turn impacts the reproducibility of experiments. Furthermore, production-scale Cloud clusters cannot be easily reproduced for SUT experimental purposes, thus posing a material constraint.
A. Statistics identification Metrics describing the SUT must be carefully selected to represent as faithfully as possible Cloud context specificities. Our identification of relevant statistics was also motivated by metrics availability from currently published datasets. Furthermore, this set of statistics is voluntarily kept as small as possible to facilitate computation and sharing from undisclosed Cloud datasets. CLOUDFACTORY statistics can be classified in two categories. At the micro level, VMs resource usages are considered. At the macro level, management of a dynamic set of VMs is studied. VM resource usage is considered from the CPU perspective. In addition to CPU utilization bounds (see Section IV-B), we also take into account usage periodicity (see Section IV-C). To account for VM management, CLOUDFACTORY considers VM configuration options distribution (see Section IV-D) and departure/arrival ratios (see Section IV-E).
B. Computing usage The workload analyzer first classifies VMs based on their average and percentile CPU usage metrics to identify resource utilization profiles. We have selected the k-means clustering algorithm, due to its capability to capture a given number of clusters. This capability allows Cloud providers to finetune the granularity of information exposed to researchers by customizing the number of profiles through the parameter k. Figure  2  illustrates this classification on the Azure dataset VMs on four profiles (k = 4). Different VMs clusters are deduced, from those with a low average and percentile usage to those with high average and percentile usage. Each cluster is subsequently translated into a profile, consisting of specific bounds on the observed average and percentile values.
D. Computing VM distribution VM configuration options distribution is an important statistic due to its impact on server consolidation. CHAMELEON and Azure datasets underline the disparity between the observed VM distributions. Therefore, we calculate the ratio of VM configuration, in terms of vCPU and vRAM, observed in Cloud datasets. return PERIODIC 6: end if 7: return NOT PERIODIC a) Avoiding bias: Counting the VM configuration occurrences at the dataset scale biases the results, due to the short lifespan of some deployments. Instead of considering the number of configurations based on deployments, we compute the average VMs distribution presence in nodes (see Equation  2 ). configuration freq (c) = s∈S Frequency(c, s) |S| (1) This later facilitates experiments' representativeness in down-scaled clusters, where server configuration and arrival rates may be significantly lower than the ones observed in production, hence impacting the hosted distribution accuracy.
The provided dataset is therefore considered through time windows of a chosen duration. Distribution presence is computed as the average value observed from all considered time slices (S). With a sufficiently short time-slice duration, this approach allows us to compute the average distribution of each VM configuration option at any given time, mitigating the impact of heterogeneous lifespan. The rest of this paper considered a one-hour time-slice duration. b) Azure example: Interestingly, applying this method to the Azure dataset reveals significant differences with their values, as they adopted the "deployment approach". For instance, the 14 GB configuration option, which is claimed to account for 11% of the VMs, is found to be half as present, accounting for only 6% of VMs over a typical hour.
E. Departure & arrival ratios The rate at which new VMs are deployed is a crucial metric for a IAAS, as it bears a significant influence on the provisioning capabilities of the platform. Conversely, the lifespan of VM deployments may be viewed as a complementary micro-level indicator. In light of our concentration on IAAS workloads, we opt for the macro-level equivalent, namely the departure ratio. Consequently, both arrival and departure ratios are computed for each identified VMs profile. To analyze these metrics, we compute the number of newly arrived VMs relative to those who left within a default one-day window through all the analyzed datasets. With Equations 2 and 3, we transform this quantities into average ratio observed in the specific context. If the arrival ratio is greater than the departure ratio, the profile is considered as increasing, while the opposite reflects a decreasing profile.
In the Azure dataset, we observe that low utilization workloads have a lower degree of dynamism, with reduced departure and arrival ratios compared to more intensive workloads. ˙ȧrrival IAAS = s∈S |departure VM (s)| |VM(s)| |S| (2) ˙ḋeparture IAAS = s∈S |arrivalVM(s)| |VM(s)| |S| (3).
VI. EXPORTERS CLOUDFACTORY can currently generate 3 export types, leading to 3 possible bindings. A. CLOUDSIMPLUS 1) Overview: In a simulation-based experiment, a CLOUDSIMPLUS scenario can be generated as a Java program that incorporates the VM workloads. While this generated Java template file is readily usable, researchers may wish to customize it to evaluate specific clusters (e. g. , number of data centers, number of nodes, size of nodes) or algorithms (e. g. , schedulers). 2) Implementation details: CLOUDSIMPLUS uses various object representations to simulate the execution of a Cloud environment. VM objects are instantiated according to generated configuration. Internal applications are modeled using Cloudlet objects. We create a per-VM Cloudlet implementing a custom utilization model loaded from a Java properties file.
To account for VM lifespan, a maximum Cloudlet duration is specified, and a broker destroys VM without any Cloudlet being assigned to it. The submission delay feature is used to manage arrival rates. B. Bash 1) Overview: In the case of a physical testbed, our tool can generate VM workloads in the form of libvirt-based bash scripts. CLOUDFACTORY outputs VMs deployment script jointly with a VMs workloads script to deliver a reproducible behaviour. To mimic the heterogeneity of the Cloud workload, different images with different applications can be considered. The generated scripts transform targeted CPU levels into benchmarking tool parameters using editable configuration files. Additionally, constraints on VM distribution can be expressed at the generation level to prevent, for instance, memoryintensive benchmarks from being deployed on lightweight VM configurations.
Although this bash exporting option requires an initial setup involving the use of pre-generated qcow2 images with SSH keys already injected, it remains a simple way to deploy a large number of VMs on a worker node. The resulting workload scripts can be used both locally and remotely, with Network Address Translation (NAT) management offered with the latter option. 2) Implementation details: Various applications are used to represent the heterogeneity of the workload in the Cloud. Idle VMs are characterized as workloads with no specific CPU activity, except for the guest operating system. Batchoriented VMs simulate CPU-intensive workloads using the StressNG load test with variable CPU usage. Database workloads are represented with VMs hosting a POSTGRESQL instance serving a TPC-C workload where request rates are adapted.
VII. CASE STUDY While CLOUDFACTORY can be used for multiple purposes, we demonstrate its added value to study cluster sizing issues, given multiple workloads characteristics. Cloud physical resources remain underused, hence severely impacting the cost and efficiency of these infrastructures at large  [4, 34]. To overcome this inefficiency, IAAS providers usually compensate for oversized VMs by offering more virtual resources than are physically available on a host. However, studying oversubscription strategies implies considering realistic VM usage. In this section, we highlight the distribution impact on the sizing of a IAAS cluster, based on the study of Chameleon and Microsoft Azure datasets.
B. Generate usage profiles As the Chameleon dataset does not contain usage metrics, Azure ones-computed from four usage profiles inferred from workload analyzer-were applied to both contexts. Furthermore, two deployment strategies were tested: a static and a dynamic deployment. In the static deployment case, all profiles were assigned arrival and departure ratios equal to 0. The initial set of VMs is therefore deployed immediately, and run on all experiment duration, with no new VMs arriving. In the case of dynamic deployment, the computed departure and arrival ratios are left unchanged for each profile. Once the initial set of VMs is deployed, some of them are leaving and others arrive continuously, while maintaining a similar overall quantity. In this scenario, the provisioning capabilities were evaluated over a one-week window.
C. Experiment Considering a hosting target of VMs, and given a VM distribution and deployment type, we compute the minimal amount of servers required to host the targeted number of VMs. To do so, the workload generator is used to obtain a CLOUDSIMPLUS workload for each combination, using a server baseline of 64 CPUs and 256 GB. The configuration baseline was chosen due to the prevalence of 64-core servers in at least one Cloud dataset  [32]  and an assumption that an allocation of 4 GB memory per core would be representative. Given a distribution and deployment type combination, CLOUDSIMPLUS simulations are run sequentially, with an increasing number of hosts, until the minimum amount of servers required is found. This is done by verifying that the default VM scheduler was able to schedule all the provisioned VMs.
D. Results Results are shown in Figure  3. Compared to the static deployment, the flexibility required by a fluctuating number of provisioned VMs implies a significant overhead for both datasets, on average 1. 31 more servers for Azure and 1. 46 for Chameleon. While being relatively stable on an increasing hosting objective, this factor underlines that heavy-tail arrival rates, reflecting grouped VMs deployments, impose an infrastructure cost. Conversely, in a system where the arrival rate can be managed based on, for example, a queuing mechanism, the cost associated with the same VM hosting objective is lower. Cloud providers can leverage this by offering their customers an incentive to choose a queued deployment instead of the state-of-the-art "as fast as possible" strategy. The Chameleon distribution requires VMs with larger amounts of resources, on average.
This decision was made for two main reasons: the widespread availability of CPU usage in datasets and the presumed correlation between CPU usage and the utilization of other resources, based on the specific application being used. However, we acknowledge that certain benchmarks could benefit from incorporating information about the usage of other computing resources. We offer the capability to scale a IAAS workload down to a single node. However, this functionality relies on the assumption that the workload is evenly distributed among nodes, which may not always hold in practice. For example, Cloud providers may manage dedicated clusters for different premium levels or service tiers.
IX. CONCLUSION In this paper, we introduced CLOUDFACTORY, a realistic IAAS workload generator. We first provide a Cloud dataset analyzer, able to compute context-based metrics on VM configuration options distribution and usage. These statistics can be shared with the wider community, enabling researchers to consider multiple Cloud-based contexts. They also can be used by our generator to compute a workload scenario in a simulated context, leveraging CLOUDSIMPLUS capabilities, or using a physical testbed using bash or CBTOOL deployments. A case study example was presented with the cluster sizing example, underlying the importance of considering representative workload to produce coherent results. As future work, we would like to consider other VM metrics on deployments, such as disk and network activities, which were not included in this version, due to the lack of available datasets.
Access to sample-level metadata is important when selecting public metagenomic sequencing datasets for reuse in new biological analyses. The Standards, Precautions, and Advances in Ancient Metagenomics community (SPAAM, https://spaam-community. org) has previously published AncientMetagenomeDir, a collection of curated and standardised sample metadata tables for metagenomic and microbial genome datasets generated from ancient samples. However, while sample-level information is useful for identifying relevant samples for inclusion in new projects, Next Generation Sequencing (NGS) library construction and sequencing metadata are also essential for appropriately reprocessing ancient metagenomic data. Currently, recovering information for downloading and preparing such data is difficult when laboratory and bioinformatic metadata is heterogeneously recorded in prose-based publications.
Introduction The field of palaeogenomics has been praised as a role model for scientific data reporting and data availability. 1  When compared against FAIR principles (Findability, Accessibility, Interoperability, and Reusability),  2  ancient DNA (aDNA) sequencing data have been consistently made available in standard data formats on public data repositories, satisfying the principles of accessibility, interoperability and, to a certain extent, reusability. However, the findability of the uploaded data still poses challenges, often due to the lack of inclusion of key metadata specific for aDNA in the standardised sample metadata fields used by public sequencing repositories such as the European Bioinformatic Institute's European Nucleotide Archive (EBI ENA), the US National Center for Biotechnology Information's Sequence Read Archive (NCBI SRA), and the Japanese National Institute of Genetics' DNA Data Bank of Japan (NIG DDBJ).
Furthermore, the library-level metadata currently available in public repositories often lack key information about aDNA library treatments and other laboratory information needed to reproducibly reanalyse palaeogenomic datasets obtained from different studies. An ancient metagenome can be generally described as the entire genetic content of a sample, within which at least a portion of the DNA has degraded over time. 3  As the number of ancient metagenomics samples and shotgun sequenced library files steadily increases (currently >2500 host-associated metagenome, >3000 single-genome, and >700 environmental metagenome sequencing run accessions as of April 2024; Figure  1 ), the need to efficiently identify, curate, and.
REVISED Amendments from Version 1 In the revised version of this manuscript we describe a new command command line subcommand 'download', as well as an updated viewer GUI and convert CLI that allows for library metadata filtering. At the request of a reviewer, we've added support for SRAToolkit as additional sequencing data download option. We have also improved installation and hardware requirement documentation, and fixed a few bugs also identified by reviewers. download such data is becoming more pressing. Although the original AncientMetagenomeDir releases provided project-or sample-level accession numbers that point to data primarily hosted by the ENA, SRA, and DDBJ, the metadata tables did not provide direct links to the data themselves. This meant that researchers still needed to manually search for each project or sample accession number in public data repositories and then manually identify and download the relevant associated files.
3). Third, AMDirT now provides users with a web browser-based GUI that allows researchers to explore relevant ancient metagenomics-related sequencing datasets in AncientMetagenomeDir tables (viewer command) and CLI interfaces (download and convert CLI commands) to download metadata and export data download scripts from International Nucleotide Sequence Database Collaboration (INSDC) repositories. Finally, as an additional functionality, both AMDirT viewer GUI and CLI interfaces can generate template input configuration files for a suite of standard aDNA metagenomics-related pipelines in order to further automate and accelerate the processing of such aDNA data. AMDirT is available for installation via PyPI (https://pypi. org/) or Bioconda,  13  with source code on GitHub under https://github.
Implementation AMDirT tool implementation. Members of the SPAAM community an international and open community of nearly 500 researchers work on ancient metagenomics (https://spaam-community. org), developed AMDirT through a series of code sprints and hackathons, using Python (v3. 9, https://www. python. org/; RRID:SCR_008394). It is accessible via a command-line-interface written using Click or via a python API (https://click. palletsprojects. com/). The autofill command uses the ENA portal API (https://www. ebi. ac. uk/ena/portal/api/) 14 to automatically query and return metadata associated with the sequencing library level, such as all project, samples and library accessions, location and size of FASTQ files, sequencing instrument model, library strategy and layout, as well as read count.
Data validation in the validate subcommand is performed using the jsonschema python library (https://python-jsonschema. readthedocs. io/) by validating the dataframes containing the sample level and library level metadata against their respective JSON schema, and using a variety of checks written using Pandas 15 to avoid data duplication and ensure consistency of new entries. Additionally, validate will also check that each publication has its own valid DOI, that each sequence archive accession is valid, unique, and associated with the correct project accession. Any errors will be reported in table format, indicating the type of error, the line and column location of the error, and a short explanation of the error, and how to fix it. Both tools are primarily used within automated GitHub actions processes on the AncientMetagenomeDir GitHub repository, however are also usable by submitters and curators running on their own machines.
The GUI data exploration interface of the viewer command was developed using Streamlit (https://streamlit. io/), and the streamlit-aggrid library 16 is used to allow the end-user to interactively filter and prepare configuration files to process ancient (meta)genomic data in bioinformatics pipelines. AMDirT is packaged thanks to setuptools, 17 and is distributed on PyPi and Bioconda. 13  The source code is available on GitHub (github. com/SPAAM-community/AMDirT), and associated documentation is provided online (amdirt. readthedocs. io). Furthermore, an online serverless version of the AMDirT viewer tool is available at https://spaam-community. org/AMDirT thanks to the stlite library (https://github. com/whitphx/stlite), a port of streamlit to WebAssembly that is supported (at the time of writing) by most Chrome-based browsers.
The CLI based convert command reuses the backend of the viewer command to provide a terminal based filtering functionality for more advanced users. Finally, the download command provides a CLI interface to download the different AncientMetagenomeDir tables using the standard python library, with the possibility of specifying the release and the table type. AncientMetagenomeDir library metadata aggregation. To extend the original AncientMetagenomeDir 3 repository to include library metadata, we created new tab-separated value (TSV) tables and their associated validation checks in the form of JSON schema files, following the original AncientMetagenomeDir structure. We retained the TSV format for maximum software compatibility, as originally described in Ref. 3. Fields included in the new library-level schema were selected after consultation with ancient metagenomics researchers of the SPAAM community, and, where relevant and possible, by mirroring existing metadata fields and controlled vocabulary from the ENA repository.
3. Since the community events, the AMDirT autofill command has been developed to improve the library metadata submission experience by community members contributing new metadata (Figure  3 ). The autofill sub-command automates the pulling of ENA metadata into a 'draft' library-table format during the continuous integration tests (CI) of a GitHub pull request of sample-level metadata, replacing and improving upon the manually executed R scripts used in the initial pull-down for the community events. Submitters to AncientMetagen-omeDir can then copy over much of the metadata and fill in the remaining missing metadata not covered by the existing ENA metadata fields.
Operation AMDirT requires a UNIX-based terminal (e. g. , Linux, OSX, Windows Subshell for Linux) for both installation and initial usage; however, the toolkit is written in Python and can therefore be used on a wide range of platforms and operating systems. To install, users are recommended to use the pip or conda package managers. Users who wish to use the GUI based table viewer and downloader will also require any modern web browser supported by Streamlit (https://streamlit. io/). For example, to install and load the help message: $ pip install amdirt or via conda in a dedicated environment $ conda create -n amdirt -c bioconda amdirt The AncientMetagenomeDir submission workflow, as updated since. 3  The general workflow remains the same, with issue creation for publication proposals, metadata submission by contributors via a branch and pull request, something that undergoes automated validation (with AMDirT validate), and later peer-review by AncientMetagenomeDir curators.