dataesr/scientific-paragraphs-categorization huggingface dataset:
The running time was 1,467 milliseconds. Furthermore, comparing to Figure  13  experiment with 10 SNPs, there is now an expected slight increase in the SNP selection software algorithm running time (star marker line) because now a larger number of SNPs have been checked. Nevertheless, even increasing the SNP set size by 100x times (from 10 to 1,000 SNPs scenario, the longest time have just approximately doubled in average (200 to 500 ms). Similarly, the longest time for the exhaustive verification, took approximately 2,000 ms in the 42nd round. We also evaluated the impact of colluding biocenters on aggregate statistics. When facing colluding biocenters, DyPS has also to evaluate combinations of genomes. This results in an increased running time due to the additional verifications. Considering the same scenario, and now using f equals to (B -1), we noted that DyPS's running time increases slightly.
DyPS over a large-scale GWAS We now consider another real genome dataset, dbGAP phs001039. v1. p1  [6] , which consists of more than 35,000 genomes from which we could use 27,895 under the General Research Use (GRU) consent, of which 14,860 genomes are cases and 13,035 are controls, respectively. We study the SNP positions that appear in both cohorts. We consider chromosome 1 as it is the chromosome with the largest number of remaining SNPs. We consider 5,000 SNP positions to evaluate DyPS's algorithm over this larger dataset. Besides, we multiplied both the addition and removal lambda parameters by 16 (λ = 128 for additions and λ = 96 for removals), so that more genome operations are generated per round. We considered the whole control dataset (13,035 genomes) as the adversary reference group.
In Figure  17 , we show the performance of DyPS over this larger dataset. Overall, 12,418 genomes were added, and 5,120 genomes were removed. Compared to the experiment in Figure  15 , this experiment had an expected longer running time (average of 207 seconds, and peak of 2,500 seconds, when a cohort made of more than 27,800 genomes was studied) for the SNP selection algorithm because of the larger genomes cohort (i. e. , more participating genomes and a larger reference group). On the other hand, Figure  17  shows a shorter running time for the exhaustive verification step due to a smaller number of SNP positions over which statistics could be released. This was because most of the SNP positions were being filtered out by the linkage disequilibrium and MAF step of DyPS over previous rounds.
Related work Defenses against membership attacks. Several works proposed solutions against membership attacks for static datasets, while DyPS targets dynamic datasets. DyPS builds on SecureGenome  [11]  for singlewise frequencies, and extends it to pairwise frequencies in its SNP selection algorithm (using the T r  [3]  and/or Λ [12] metrics), to determine the set of SNPs over which frequencies can be safely released. Craig et al. [35]  advocated for a similar approach based on the Positive Predictive Value (PPV). Im et al. [9]  showed that the membership attack power increases when regression coefficients from quantitative multi-phenotype are available. Fernandes et al. [36]  considered separating a genome over multiple sensitivity levels to prevent reidentification attacks.
Privacy-preserving GWAS releases. Zhou et al. [12]  evaluated the theoretical complexity of attacks on GWAS results. DyPS further builds on their results by offering a dynamic and federated architecture. Data anonymization methods enforce privacy properties such as t-closeness, k-anonymity and ldiversity  [21]. However, k-anonymous genomic datasets have been deanonymized  [37] [38] [39] , even with high dimensional data  [40]. Differential Privacy (DP)  [41] , which adds noise to the results, has also been used  [42] [43] [44] [45] [46] [47] [48]. In comparison, DyPS leaves the data unmodified. Jiang et al. [47]  proposed a privacy-budget approach based on the LR-test that balances data perturbation with privacy risks. Simmon et al. [46]  propose two DP frameworks for GWAS: PrivSTRAT applies data perturbation considering the group stratification in a study and PrivLMM is based on Linear Mixed Models (LLMs).
Johnson et al. [43]  offer a DP approach for GWAS based on adding noise to data based on their shifting method that considers distance scores. Lu et al. [48]  described a Distributed Differential Privacy (DDP), in which parties perturb their local genomic data shares before sharing them. Similarly, another noise-based approach  [39]  combines the addition of minimal amounts of noise perturbation with Bayesian and Markov Chain Monte Carlo techniques. Nevertheless, given that the privacy level certainty sustained by DP depends on the statistical independence of the records in a dataset, previous works have shown that highly correlated records in datasets can diminish the DP's guarantees  [49, 50]. In addition, if not well designed, DP approaches can suffer from collusion attacks, which can disclose individuals' data  [51].
Kamm et al. [57]  a secure MPC framework where institutes share their genome dataset to a thirdparty data storage for χ 2 tests computing. Zhang et al. [23]  use secret sharing that assumes (n, t)-threshold for corrupted parties. [21]  performs χ 2 and p-tests in a privacy-preserving way, and  [22]  performs privacypreserving χ 2 and MAF processing. However, these two approaches are restricted to two parties, and can not be applied as is in a federated system. Recently,  [20]  also proposed MPC techniques for privacy-preserving GWAS based on population biases, however, they have not offered any mechanisms to avoid attacks on aggregate released results. Raisaro et al. [14]  offer a decentralized and privacy-preserving data sharing of genomic data to answer health record queries and build on Unlynx  [58] , which incorporates known privacy-preserving techniques, such as HE and DP.
Conclusion In this paper, we presented DyPS, a novel framework to conduct federated genomic data analysis that enables both secure computation and release of GWAS results even when facing collusion among participating dataholders. In addition, DyPS enables dynamic releases of GWAS results according to the evolution of the considered number of genomic variations, individuals, or involved biocenters while enforcing privacy. To further speed up the release of the results, DyPS uses a scaling mechanism that progressively increases the number of considered genomic variations. DyPS leverages an Intel SGX enclave to secure the data of each biocenter. We extensively evaluated its performance considering up to 300,000 SNPs and more than 6 million simulated genomes, and using two datasets made of 2,000 and 35,000 real genomes, respectively.
A. 2 Pseudocode DyPS uses the algorithm reported in Figure  18  to select the biocenters that participate in a batch of requests to be executed. In the case of test statistics, all addition requests from a selected biocenter are selected, and a lower or equal number of removals. This algorithm assumes that up to f biocenters are colluding, with f ≤ (B -1). DyPS first retrieves and binds the requests to their corresponding biocenters in FIFO order (line 7 to 9), and adds them to bioList. After gathering the requests from the biocenters, DyPS sorts the list of biocenters according to their number of addition requests (line 10), before selecting a batch of requests (lines 11 to 34). The rationale behind the selection algorithm is to select a group of biocenters such that their combined requests cannot be attacked by the f biocenters that participate the most, and who might be colluding.
B. 2 Pseudocode At this point, DyPS had already selected a safe batch of requests to use to update test statistics, as explained in Appendix A. DyPS then checks whether aggregate statistics can be updated using the selected batch of requests. This process is shown in the algorithm reported in Figure  19. DyPS first collects the safe SNP positions that can be released given the selected genomes and all combinations of genomes considering up to f adversary biocenters (line 5). For each selected SNP, DyPS then collects the previous releases where it has been previously updated, and checks whether they involved genomes that participate in the current batch of genomes (lines 6 to 14). DyPS then generates and loops over all combinations of releases that share the same SNPs (lines 15 to 23). For each possible combination, DyPS executes the SNP selection software over the resulting set of genomes.
Infiniband is also used for a switched interconnection between the servers and the 4 available file systems. A thorough technical description of Zorba is available in Section A2 of Zafeiropoulos et al. [40]. More than 200 software packages are currently installed and available to users at Zorba, covering the most common analysis types. These tools allow assembly, HTS data preprocessing, phylogenetic tree construction, ortholog finding, and population structure modeling, to name a few. Access to these packages is provided through Environment Modules, a broadly used means of accessing software in HPC systems  [42]. During the last 2 years, Zorba has been moving from systemdependent pipelines previously developed at IMBBC (e. g. , Para MetabarCoding) towards containerization of available and new pipelines/tools.
A complete metabarcoding analysis tool for various marker genes (PEMA)  [43] , the chained and automated use of STACKS, software for population genetics analysis from shortlength sequences  [44]  (latest version), a set of statistical functions in R for the computation of biodiversity indices, and analyses in cases of high computational demands  [45] , as well as a programming workflow for the automation of biodiversity historical data curation (DECO) are among the in-house developed containers. The standard container/image format used on Zorba is Singularity. Singularity images can be served by any Zorba partition; Docker images can run instantly as Singularity images. A thorough description of the software containers developed in Zorba can be found in Section D of Zafeiropoulos et al. [40].
Zorba's daily functioning is ensured by a core team of 4 fulltime, experienced staff: a hardware officer, 2 system administrators, and a permanent researcher in biodiversity informatics and data science. More than 70 users (internal and external scientists), investigators, postdoctoral researchers, technicians, and doctoral/postgraduate students have gained access to the HPC infrastructure thus far. Support is provided officially through a help desk ticketing system. An average of 31 requests/month have been received (since June 2019), with the most demanded categories being troubleshooting (38. 2%) and software installation (23. 8%). Since October 2017, monthly meetings among HPC users have been established to regularly discuss such issues. Proper scheduling of the submitted jobs and fair resource sharing is a major task that needs to be confronted day to day.
To address this, a specific usage policy for each of the various partitions and a scheduling software tool set have been adopted in Zorba. Policy terms are dynamically adapted to the HPC hardware architecture and to the usage statistics, with revisions being discussed between the HPC core team and users. The Simple Linux Utility for Resource Management (SLURM) open-source cluster management system orchestrates the job scheduling and allocates resources, and a booking system helps users to organize their projects and administrators to monitor the resource reservations on a mid-to long-term basis. A SLURM Database Daemon (slurmdbd) has also been installed to allow logging and recording of job usage statistics into a separate SQL database (see Section C1 in Zafeiropoulos et al. [40] ). An extended description of user and job administrations and orchestration can be found in Section C1 of Zafeiropoulos et al.
xlsx in Zafeiropoulos et al. [40] ). In comparison, studies in the Biotechnology and Agriculture fields indicate contemporary and beyond-marine orientations of research at IMBBC, respectively (see Section B2 in Zafeiropoulos et al. [40] ). In addition, 8 methods of data acquisition (experimental or in silico) have been defined (Fig. 3 ). Among these methods, whole-genome sequencing and whole-transcriptome sequencing have been widely used in multiple fields (Biotechnology, Organismal Biology, Aquaculture). Conversely, Double digest restriction-site associated sequencing (ddRADseq) has been solely employed for population genetic studies in the context of Aquaculture. The 47 published studies employed different computational methods (sets of tasks executed on the HPC facility). These studies served different purposes, from a range of bioinformatics analyses to HPC-oriented software optimization.
High memory was commonly associated with computational methods, including de novo assembly; all relevant research concerned non-model taxa and involved short-read sequencing or combinations of short-and long-read sequencing. By contrast, phylogenetic analysis studies did not involve intensive RAM use; this is largely due to the fact that software used by IMBBC users adopts parallel solutions for tree construction. Long computational times (Fig. 4a ) were most often observed at the functional annotation step in transcriptome analysis, DE analysis, and comparative and evolutionary omics, when this step involved BLAST queries of thousands of predicted genes against large databases, such as nr (NCBI). Finally, a common challenge emerging from all bioinformatic approaches is significant storage limitations (Fig.
All servers, except file systems, run Debian 9 (kernel 4. 9. 0-8-amd64). CCBY icons from the Noun Project: "nfs file document icon" by IYIKON, PK; "Earth" By mungang kim, KR; "database": By Vectorstall, PK; "switch" by Bonegolem, IT cases is by no means exhaustive, but rather an attempt to highlight different fields of research supported by the facility, along with their distinct computational features.
DE analysis of aquaculture fish species sheds light on critical phenotypes Distinct, observable properties, such as morphology, development, and behavior, characterize living taxa. The correspond-ing phenotypes may be controlled by the interplay between specific genotypes and the environment. To capture an individual's genotype at a specific time point, molecular tools for transcript quantification have followed the fast development of technologies, with Expressed Sequence Tags as the first approach to be historically used, especially suited for non-model taxa  [56]. Nowadays, the physiological state of aquaculture species is retrieved through investigation of stage-specific and immune-and stress response-specific transcriptomic profiles using RNAseq. The corresponding computational workflows involve installing various tools at Zorba and implementing a series of steps that often take days to compute.
The most long-lasting solution has been the adoption of a per user quota system to allow storage sustainability and fairness in our allocation policy. This quota system nevertheless constitutes a limiting factor in pipeline execution, since lots of software tools produce unpredictably too many intermediate files, which not only increase storage but also cause job failures due to space restrictions. We managed the above issue by adding a scratch file system as an intermediate storage area for the runtime capacity needs. Following completion of their analysis, a user retains only the useful files and the rest are permanently removed. A storage upgrade scheduled within 2021 (see Section Future Directions) is expected to alleviate current storage challenges in Zorba. However, given the ever-increasing data production (e.
An example of such synergies concerns technical solutions (e. g. , containerization) that address long-standing software sharing issues. In our experience, a workflow/pipeline can be developed by experts within the context of a specific project in a regional HPC facility. Once a production version of the pipeline is packaged, it can be distributed to centralized systems to cover a broader user audience (see Section The IMBBC HPC Facility From a Single Server to a Tier 2 System). Singularity containers have been developed to utterly suit HPC environments, mostly because they permit root access of the system in all cases. In addition, Singularity is compatible with all Docker images and can be used with Graphics Processing Units (GPUs) and Message Passing Interface (MPI) applications. This is why we chose to run containers in a Singularity format at Zorba.
However, as Docker containers are widely used, especially in cloud computing (see more about cloud computing in Section Cloud Computing), workflows and services produced at IMBBC are offered in both container formats. Containers are an already established technology, used by the biggest cloud providers worldwide and increasingly by non-profit research institutes. Despite indirect costs (e. g. , costs to containerize legacy software), we believe that these technologies will become the norm in the future, especially in the context of reproducibility and interoperability of bioinformatics analysis.
Academic/publicly funded providers are also available: e. g. , the EMBL-EBI Embassy Cloud. Cloud computing services are being increasingly adopted in research, mainly because they offer simplicity and high availability to users with reduced or even no experience in HPC systems, through web interfaces. For this type of user, the time needed for data manipulation, software installation, and usersystem interaction is significantly reduced compared to using a local HPC facility. Container technologies, especially Docker, along with container-management systems such as Kubernetes combined with OpenStack, have been widely used in a number cloud computing systems, in particular in the research domain. It should be noted, however, that tool experimentation and benchmarking is more limited in cloud computing compared to local facilities and is costly, since it demands additional core hours of segmented computation.
5 TB of RAM, hosted on a single node. Eventually, more users will be able to concurrently load and analyze big data sets on the file systems. Over the coming 2 years, Zorba is also expected to have 2 major additions: i. the acquisition of a number of GPU nodes to build a new partition, especially for serving software that has been ported to run on GPUs; and ii. the design of a parallel file system (Ceph or Lustre) to optimize concurrent I/O operations to speed up CPU-intensive jobs. The expectation is that the upcoming upgrade of Zorba will further enhance collaborations with external users, since the types of bioinformatic tasks supported by the infrastructure are common to other disciplines beyond marine science, such as environmental omics research in the broad term. A nationwide survey targeting the community of researchers studying the environment and adopting the same approaches (HTS, biodiversity monitoring) has revealed that their computational and training needs are on the rise (A.
Gioti et al. , unpublished observations). Usage peaks and valleys were observed in Zorba (see Section B1 in Zafeiropoulos et al. [40] ), similarly to other HTS-oriented HPC systems  [31]. It is therefore feasible to share Zorba's idling time with other scientific communities. Besides, the Zorba upgrade is very timely in coming during a period where additional computational infrastructures emerge: the Cloud infrastructure Hypatia, funded by the Greek node of ELIXIR, is entering its production phase. It will constitute a national Tier 1 HPC facility, designed to host ∼50 computational nodes of different capabilities (regular servers, GPU-enabled servers, Solid-State Drive-enabled servers, etc. ) and provide users the option to either create custom virtual machines for their computational services or to upload and execute workflows of containerized scientific software packages.
This operational structure has evolved over the years based on the needs of the facility's users and the available resources. The practical solutions adopted-from hardware (e. g. , depth/breadth balanced structure, user quotas, and temporary storage) to software (e. g. , modularized bioinformatics application maintenance and containerization) and human resource management (e. g. , frequent intercommunication, continuous cross-discipline training)-reflect IMBBC research to a large extent. However, and by incrementing previous reviews  [31] , other Institutes and HPC facilities can be informed on the lessons learned (see Section Lessons Learned), and reflect on the computational requirement analysis of the methods presented (see Section Computational Breakdown of the IMBBC HPC-Supported Research) through the spectrum of their own research so as to plan ahead.
Acknowledgements The authors thank  Dr. Pantelis Topalis ,  Institute of Molecular Biology and Biotechnology / Foundation for Research and Technology Hellas , for fruitful discussions on high-performance computing strategic design. We also thank the  ELIXIR-GR Compute platform and Resource Allocation Committee  for their advice and ideas exchange. We thank  Dr. Ioulia Santi ,  Dr. Anastasios Bounas , and  Romanos Siaperas  for their feedback on the systematic labeling of the published studies used for this review.
A linear fit to this unknown linear phase in the two continuum regions provides the unknown linear phase across the Brα line necessary to derive the desired target Fourier phase in the Brα line region. The images presented in this paper were reconstructed from the visibilities, closure phases, and Fourier phases by using the MATISSE data reconstruction pipeline. Image reconstruction is described in Sect. 9. 6 and D. 2 in ESO's MATISSE Pipeline User Manual 1 (in image reconstruction tool mat_cal_imarec, which is an extension of IRBis). The start image of all reconstruction runs was a circular Gaussian, which was fit to the observed visibilities of η Car. The pixel grid used for the reconstructions was 64 × 64 pixels corresponding to 100 × 100 mas on the sky. A computed quality parameter of the reconstructions (called qrec; see  Hofmann et al.
Acknowledgements. MATISSE was designed, funded and built in close collaboration with ESO, by a consortium composed of institutes in France (J. -L. Lagrange Laboratory -INSU-CNRS -Côte d'Azur Observatory -University of Côte d'Azur), Germany (MPIA, MPIfR and University of Kiel), the Netherlands (NOVA and University of Leiden), and Austria (University of Vienna). We thank all ESO colleagues for the excellent collaboration. This work has been supported by the French government through the UCAJEDI Investments in the Future project managed by the National research Agency (ANR) with the reference number ANR-15-IDEX-01. The Konkoly Observatory and Cologne University have also provided some support in the manufacture of the instrument. K. O. acknowledges the support of the Agencia Nacional de Investigación y Desarrollo (ANID) through the FONDECYT Regular grant 1 180066.
S. K. and A. K. acknowledge support from an STFC Consolidated Grant (ST/V000721/1) and ERC Starting Grant (Grant Agreement No. 639889). The research of J. V. and M. H. is supported by NOVA, the Netherlands Research School for Astronomy. T. H. acknowledges support from the European Research Council under the Horizon 2020 Framework Program via the ERC Advanced Grant Origins 83 24 28. A. G. acknowledges support from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme under grant agreement No 695099 (project CepBin). P. A. acknowledges support from the Hungarian NKFIH OTKA grant K132406, and from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme under grant agreement No 716155 (SACCRED).