dataesr/scientific-paragraphs-categorization huggingface dataset:
A. EVALUATION THE PERFORMANCE OF THE PLANAR FSS The unit cell of the proposed ring slot FSS is simulated using Computer Simulation Technology (CST) Microwave Studio software. The simulation was done using the frequency domain solver as it is suitable for the simulation of a highly resonant structure as well as acknowledging the examination of the FSS performance with the variation of the angle of incident and polarization. The periodic boundary condition is set in both horizontal and vertical direction and z-direction is set to be open for locating the ports. To reduce the simulation load, CST full floquet port is utilized to simulate unit cell of FSS to model the proposed FSS as an infinite array in the CST simulation window. The simulated transmission response at the normal incident for both TE and TM polarisation of the proposed FSS is demonstrated in Figure  3.
B. EVALUATION THE PERFORMANCE OF THE CONFORMAL FSS In order to scrutinize the performance of the FSS when it is bent, Figure  4  illustrates the mechanism utilized to realize the conformal FSS. However, the aforementioned method which is the floquet port simulation is not directly applicable for the engineering-essential curved FSS as it is impractical to organize the FSS elements in a purely 2-D periodic sense when the FSS is bent. In order to evaluate the bending effect of the FSS array in the CST software, the unit cell simulation is not applicable as it will assume each and every single unit cell is bent. Thus, a finite model analysis is proposed in the evaluation of the bending effect of the FSS  [16] , but this required a heavy computational loading. Therefore, in this paper, a semi-infinite model is proposed in the evaluation of the bending of the FSS array.
The simulation setup employed to investigate the proposed conformal FSS structure is the conventional unit cell simulation set-up in the CST software. The unit cell of the FSS is bent with a radius of 4mm and the x-direction and y-direction is defined as unit cell, while z-direction is defined as open(add space). By employing this set-up the simulation loading is reduced significantly as compared to the full finite array simulation. Figure  8  exemplifies the simulated transmission response of the unit cell FSS with planar and conformal features for TE and TM polarization. From the results, it can be contemplated that when the unit cell of the FSS is bent with a radius of 4mm, the resonant frequency is altered from 10 GHz to 10. 4 GHz for TE polarization and from 10 GHz to 9. 6 GHz for TM polarization.
Implementing scalable, reproducible, portable and easy-to-use workflows is particularly challenging. Results: H3ABioNet has built four workflows to support (1) the calling of variants from high-throughput sequencing data; (2) the analysis of microbial populations from 16S rDNA sequence data; (3) genotyping and genome-wide association studies; and (4) single nucleotide polymorphism imputation. A week-long hackathon was organized in August 2016 with participants from six African bioinformatics groups, and US and European collaborators. Two of the workflows are built using the Common Workflow Language framework (CWL) and two using Nextflow. All the workflows are containerized for improved portability and reproducibility using Docker, and are publicly available for use by members of the H3Africa consortium and the international research community.
Therefore, an important subsidiary goal was to develop capacity for portable, reproducible workflow building in Africa. An important constraint on this development was that the workflows should be as portable as possible, given the heterogeneous computing environments of the different groups e. g High Performance Computing (HPC) centers, University and lab clusters, and cloud environments, where accessible. The use of container technology (Docker, in our case) was considered crucial, though the workflows do not rely solely on Docker, as many high-performance computing clusters offer alternative implementations such as Shifter (https://github. com/NERSC/shifter) or Singularity (https://www. sylabs. io/docs/). This paper reflects on the technical aspects and details of implementing these workflows, and the lessons learned.
Nextflow Nextflow  [12]  is a workflow language and system developed at the Centre for Genome Regulation in Barcelona. Although it has a few specific built-in features to support bioinformatics, it is a general-purpose workflow system that runs on Unix-like systems including Linux and MacOS. The language is a domain-specific language built on Groovy. Nextflow supports: execution of workflows, with partial resumption; containerisation with Docker and Singularity; and multiple execution modes including local execution, execution on clusters, Amazon EC2 (cloudinit and AWS Batch), Kubernetes, and OpenStack. The Nextflow workflows are highly portable, e. g. a scientist can run the same workflow: • on a dedicated computer with all the underlying application software installed; • distributed across a compute cluster (again assuming all underlying application software has been installed): the Nextflow program submits the necessary jobs to the cluster job manager on the scientist's behalf, considering dependencies between tasks; the Nextflow monitoring process itself will run on the head node; • without any of the bioinformatics software installed on the system, and they are set up using Nextflow's Docker support (locally, on a Docker Swarm or on Amazon EC2).
Workflow A: whole Genome/Exome NGS data analysis Whole genome and whole exome shotgun sequencing has become an essential tool for research and medical applications  [13] [14] [15]. The H3Africa projects will be generating exome and whole genome sequence data, hence implementing an automated variant calling data analysis workflow for analysis of African genomic data is essential. The H3ABioNet hackathon participants opted to implement an extended version of the Broad Institute's Genome Analysis ToolKit (GATK)  [16]  Best Practices version 3. 5  [17, 18]. This GATK best practices for variant calling has been extensively validated and accepted as an industry standard for human NGS data analysis  [18]. The workflow (Fig. 1 ) was extended during the H3ABioNet hackathon to include: 1 Sequencing adaptor trimming with Trimmomatic  [19] , which provides extensive short read trimming, including sequencing adaptors and barcode trimming, and base quality based trimming.
6 Indels and single nucleotide variant (SNV) annotation: SnpEff  [21]  extends the VCF file containing the variants with information relevant for downstream analysis. The information included ranges from the SNP rsID, to clinically relevant variants from ClinVar  [22]. The workflow takes advantage of Docker integration with CWL to handle the tools' dependencies, with the exception of GATK, where the user has to provide their own GenomeAnalysisTK. jar file as one of the workflow inputs for licensing reasons. The workflow is available on the CWL workflows library on GitHub: https://github. com/h3abionet/h3agatk and the container at Dockstore: https://dockstore. org/workflows/ github. com/h3abionet/h3agatk.
• Taxonomic assignment of OTUs are performed using QIIME (http://qiime. org). • A phylogenetic tree is created from the OTU sequence alignments using QIIME. • Some descriptive statistics and plots are generated from the resulting BIOM and tree file using Phyloseq  [24]. The 16S rDNA workflow consists of several steps, each represented by one CWL workflow description, as shown in Fig. 2. Since the workflow has been developed using CWL which already provides support for the use of Docker, all the tools have been included in the form of a Docker container. It should be noted that since USEARCH requires a license agreement, users should first go through the license application process prior to using this component in the workflow. The resulting workflow for the 16S rDNA Diversity Analysis is available on GitHub at https://github.
Workflow C: genome wide-association studies The H3Africa Consortium will genotype over 30k individuals using a custom designed African genotyping array. This effort will create the first large influx of data for a range of genome-wide association studies (GWAS), facilitating the need for the development of a robust and efficient workflow. GWAS data analysis is a multi-step approach beginning with several QC steps prior to the downstream association tests. A GWAS data analysis workflow (Workflow C) was therefore implemented using Nextflow. The workflow (Fig. 3 ) consists of 3 modules, which can be swapped in and out depending on the analysis needs: 1 Conversion from Illumina TOP/BOTTOM call format to PLINK format. 2 The core workflow carries out a set of QC steps, starting with standard PLINK files and resulting in quality controlled PLINK files.
While, for example, some users of our workflow will have a homogeneous group to study, others may have samples with significant admixture. The goal of the association testing workflow is to perform an initial analysis and review the results, allowing scientists to gain further insights into the complexity of their data before performing their own bespoke analysis. This workflow is under active development as H3A groups analyse data from round 1 of H3A. Sample runs and extensive documentation can be found at: http://github. com/h3abionet/h3agwas.
Genotyped positions are then prephased using SHAPEIT in parallel on each chromosome. After prephasing, IMPUTE2  [28]  is run in parallel across all 500 kB blocks in the entire genome. Imputed blocks are then combined into a single compressed haplotype file using a perl script which is provided with the workflow. Finally, we convert this file back to a PLINK dataset for integration back into the GWAS workflow. The workflow as implemented is capable of using multiple reference panels, and has been tested in whole-genome imputation using the Haplotype Reference Consortium panel as well as the 1000 genomes panel phase 3 (which is utilized by default). Because assuring genotype and reference strand alignment is critical for proper imputation, we have also included a perl script that is capable of strand flipping user-supplied ped and map files given an Illumina TOP/BOT probe strand identification file, a subset dbSNP VCF file, and a reference genome to Fig.
Workflow A: whole Genome/Exome NGS data analysis The workflow (https://github. com/h3abionet/h3agatk) has been tested on local machines, EGI FedCloud resources (Fernández-del-Castillo et al. 2015), AWS EC2 as well as on a Microsoft Azure VM both with and without Docker. The workflow requires Docker to be installed, and the GATK jar file and sequence reads in fastq format as input files. We tested the pipeline using several whole-exome and whole genome datasets such as the Genome in a Bottle (GIAB) NA12878 Garvin exome. For instance, the user can use the testprepare_test. sh script to set up a test environment and download the necessary data files to run GAIB NA12878 exome. Running this test example on a 16 core, 128 GB+ Ubuntu VM running on Azure machine takes less than 8 h and requires about 500 Gb of storage space available during the analysis.
Workflow B: 16S rDNA diversity analysis This workflow (https://github. com/h3abionet/h3abionet 16S) has been tested on local computers (Linux and MacOS) with and without Docker, AWS EC2 and Azure VMs with and without Docker, an SGE cluster with Docker support and a PBS cluster without Docker support. Documentation to setup the package and run the workflow has been created and can be accessed here: https://github. com/h3abionet/ h3abionet16S/tree/master/workflows-cwl. For testing we used a 16S rRNA dataset that comprised of three dogs which were treated with increased percentage of a compound in their diet on 5 levels. The total dataset had 15 samples with an average of 25,000 reads per sample and an overall size of 2. 4 GB. We used the the greengenes database (3. 7 GB) for classification and phylogenetic tree generation and the gold.
fa "Gold" database (16 MB) for chimera checking. We ran the CWL pipeline using the cwltool and it took 36 min to complete on a single core with 8 GB of RAM. An output of 4 GB was created (excluding the CWL cache size of 4. 8 GB). The final OTU file consisted of 187 OTUs. Visually inspecting the per sample diversity plot, heatmap and abundance plot pointed to difference between the 3 dog groups. Pulling the BIOM file into R and analysing the results with the MetegenomeSeq showed that there is a significant differential abundance between the dog groups. Inspecting ordination plots with Phyloseq also showed a clear difference between the groups.
Workflow C: genome wide-association studies This workflow (http://github. com/h3abionet/h3agwas/) has been tested on local computers (Linux and MacOS) with and without Docker, clusters running Torque (with and without Docker) and the Bright Cluster Manager (without Docker), Docker Swarm and cloud-init (http://cloudinit. readthedocs. io). Nextflow has direct support for Amazon EC2 which allows the dynamic creation of EC2 clusters using Nextflow commands. We have packaged an Amazon AMI for users to support our workflow (and would work for the other workflows). The same workflow runs across all environments, using different parameters for start-up. The workflow setup requires installation of Nextflow (a one line command) and Java 8, and either a Docker engine or the installation of the underlying application software.
For those unable to use Docker, e. g. , on HPC systems which do not support it, the underlying application software such as PLINK and Python will need to be installed and added to the default PATH at the moment of the execution. The workflow also supports Singularity. The pipelines have been successfully used by three H3A groups to analyse their H3A project data. The largest analysis we know was that of the AWI-Gen group where approximately 11. 5 k samples were genotyped using the H3A Genotyping array (approximately 2. 2 m SNPs). The AWI-Gen project  [29]  is exploring genetic and environmental factors in cardio-metabolic disorders in African populations. Almost 12,000 participants have been recruited at six sites in four African countries, have been finely phenotyped and all genotyped on the H3A Genoyping arrays.
Workflow D: SNP imputation This workflow has been tested on local computers (Linux) with and without docker, an SGE cluster without Docker support, and an OpenStack cloud with Docker support. Documentation to set up and run the workflow is present at https://github. com/h3abionet/chipimputation. We ran the workflow on a modest, publicly available dataset of 471 samples genotyped on the Affymetrix SNP6 array against the standard IMPUTE2 reference panel of 2504 samples (85M sites). On a 192-core cluster the workflow completed in 58 h, utilising 17 k CPU hours. 17 k processes were executed, with maximum and minimum runtimes of 1 and 250 min respectively. The final output dataset was roughly 45 GB. Maximum memory usage was 8GB across all processes. It is worth noting that earlier runs reported processes consuming 256 G RAM, a result of PLINK reserving half of a machine's RAM by default.
Discussion While several workflow management systems are available, they are designed to offer a specific set of functionalities. For example, Galaxy  [30]  and Taverna  [31]  focus on providing a user friendly "point and click" graphical interface. While other platforms such as COSMOS and Pegasus, among many others, are focused on offering frameworks for a high-level of parallelisation. However, these platforms each use unique workflow definition languages, and operate at different levels of complexity. Earlier efforts to enable interoperability between different workflow definition languages was Tavaxy  [32]  enabling the running of workflows defined in Galaxy and Taverna. Community driven projects such as CWL offer a more robust approach towards standardisation of workflow definitions, whereas Nextflow addresses more specialised needs such as the partial resumption of a workflow without the need to restart the whole analysis.
Related work Building upon the experience of Workflow A, "H3ABioNet GATK Germline Workflow", the Human Genetics Informatics team at the Wellcome Trust Sanger Institute built "gatk-cwl-generator" which generates CWL descriptions from the GATK documentation https://github. com/wtsi-hgi/gatk-cwl-generator/. M. Crusoe used his experience helping the Workflow B team ("H3ABioNet 16S rDNA diverstity analysis") when he assisted EMBL-EBI in converting their core Metagenomics service pipelines from in-house scripts to CWL: https://github. com/EBI-Metagenomics/ebimetagenomics-cwl though the initial version of those CWL descriptions did not have accompanying Docker software containers, unlike the work of the Workflow B team. There are no directly comparable workflow systems for Workflow C (GWAS). The closest for QC is the work of Ellingson and Fardo  [33] , which is a collection of Python and R scripts for performing QC.
GenCloud  [34]  was a workflow for GWAS analysis using grid-based technology for authentication and running in an Open-Stack environment; however, no further work has been done since 2014 and it is not available for general installation. GWASpi  [35]  is a Java program that provides end-to-end analysis of data. However, it has not been updated for several years, and only provides limited functionality. Several groups have developed in-house systems of great power and flexibility (e. g. the Edinburgh GWAS pipeline [Wilson and Joshi, personal communication], https://www. ikmb. uni-kiel. de/research/geneticsbioinformatics/bioinformatics/gwas-pipleline). However, these are not designed for easy porting to other environments and may not even be available to other researchers. Our pipeline is distinguished by more general functionalities and being easier to be customised by users.
Reflections on workflow building and use The primary goal of the project was to produce out of the box operational workflows, and workflow languages used for implementation were chosen for pragmatic reasons. Discussions of the possibility of standardising on one workflow language were had, but there was a desire by different groups to use either CWL and Nextflow. The use of the two workflow languages would allow expertise and capacity in both languages to be developed within H3ABioNet and allow the exploration of different technologies. Both infrastructures offer robust workflow development environments, and have a range of useful features and very responsive support communities. Beyond learning how to use and implement them, the H3ABioNet hackathon was not designed to evaluate them individually or compare and contrast the workflow languages.
CWL and Nextflow are different in their philosophy and syntax which partly reflects their very different origins. Nextflow comes from one research group which drives the Nextflow language and system development using its community as a sounding board. CWL is a language rather than a system, and is developed by a multi-vendor community. The standards are agreed upon by the community, and tools from different vendors support it. Our tentative experience was that Nextflow is easier to learn and may fit the needs of smaller and mid-size groups better; however, these findings are based upon subjective experiences and may simply reflect that different programmers have personal preferences beyond objective justification. At the time of this hackathon none of the CWL graphical interfaces which have since been written, such as the Rabix Composer, were available.
Likewise, one can specify what return codes mean that a temporary or a permanent error has occurred, but advanced error handling logic beyond that is specific to each CWL implementation. For example, IBM's "CWLEXEC" for LSF has its own error handling directives. CWL users can also insert conceptual checkpoint steps that verify that the data at a certain point in the workflow meets desired parameters, forcing an early termination if it does not. There are CWL engines that are able to submit to cluster environments, however they were not tested on the h3abionet16S CWL workflow; the CWL reference runner (cwltool) that was used in testing purposely does not provide that functionality. The Nextflow version of the h3abionet16S package is now also available in the GitHub repository (https://github.
com/h3abionet/h3abionet16S/ tree/master/workflows-nxf). One complication of workflows is that exceptional events or errors may be obscure for the user. The GWAS workflow does some pre-checks of the user data; however, many errors can only be detected when the actual computation is done. Nextflow's error messages are intended for people comfortable with Nextflow. Within these constraints we try to print meaningful error messages, and have requested modification to Nextflow to allow greater control of what errors appear. H3ABioNet plans to make the imputation workflow available as a service to African researchers, together with an African-specific reference (software and computational resources). There are informal arrangements within the network where the better-resourced nodes make their resources available to other nodes or African researchers.
Availability of data and materials All data underlying the results are available as part of the article and no additional source data are required. All four described pipeline implementations are available on the H3ABioNet github account (https:// github. com/h3abionet). Workflow A: h3agatk; Workflow B: h3abionet16S; Workflow C: h3agwas; Workflow D: chipimputation. The containers for the workflows can be found on Quay. IO (https://quay. io/organization/h3abionet_ org). The GWAS pipeline dependencies (e. g. Python, PLINK, LaTeX) are all available under open-source licences. The executables used in the imputation pipeline are made available under GPLv3, except for IMPUTE2 which restricts commercial use.
Acknowledgements Rob Clucas developed the first dockerised version of the WitsGWAS pipeline on which the H3Agwas pipeline was developed. We acknowledge with thanks advice and help from: Ananyo Choudhury, Dhriti Sengupta, Alex Rodriguez, Segun Jung, Abayomi Mosaku, Anmol Kiran and Harry Noyes. Development and testing were performed using facilities provided by the University of Cape Town's ICTS High Performance Computing team (http://hpc. uct. ac. za). Development and testing were performed using the Wits Core Research Cluster of the University of the Witwatersrand. Hackathon activities were performed on Nebula, the OpenStack system at the National Center for Supercomputing Applications (https://wiki. ncsa. illinois. edu/display/NEBULA/ Nebula+Home), USA. The Variant calling workflow was tested on AWS using a courtesy allocation granted by the University of Illinois at Urbana Champaign to expand student engagement in cloud computing (https://techservices.
illinois. edu/services/amazon-web-services). The variant calling workflow also used the EGI Applications On Demand Service, which is co-funded by the EGI-Engage project (Horizon 2020) under Grant number 654142. This courtesy allocation was granted by an agreement contract between CBSB at the University of Khartoum and EGI. As members of H3ABioNet and the H3Africa Consortium Shakuntala Baichoo, Sumir Panji, Gerrit Botha, Ayton Meintjes, Scott Hazelhurst, Hocine Bendou, Eugene de Beste, Phelelani T. Mpangase, Oussema Souiai, Mustafa Alghali, Long Yi, Shaun Aron, Fourie Joubert, Azza E.