dataesr/scientific-paragraphs-categorization huggingface dataset:
RELATED WORK IN MULTICLOUD INFRASTRUCTURE SECURITY any distributed virtualization infrastructures (for example, microhypervisors, nested virtualization, container platforms, and library operating systems), isolation and trust management technologies, and protection automation techniques have tackled security challenges related to multiprovider interoperability and vulnerable software layers, but without meeting requirements for user control, low attack surface, interoperability, and legacy compatibility. The Supercloud hybrid virtualization architecture enables flexible but efficient user-centric tradeoffs in terms of both interoperability and security for the multicloud. Many solutions, such as Google Drive and Dropbox, allow users to store their own data on the cloud. However, most don't permit user-centric data encryption.
In current cloud-based data storage solutions, no commercial product uses advanced cryptographic tools for data confidentiality protection, such as those we propose to use in Supercloud. Most major infrastructure-as-a-service providers offer replication solutions across multiple datacenters to support dependability; however, this remains limited to proprietary protocols and single administrative domains. Software-defined networking-based virtualization solutions allow cloud providers to offer complete network virtualization. 1 They give tenants the freedom to specify their network topologies and addressing schemes, while guaranteeing the required level of isolation. These platforms, however, have been targeting the datacenter of a single cloud provider with full control over the infrastructure.
Static Architecture The Supercloud architecture allows customers to instantiate U-Clouds that run on the underlying infrastructure. Figure  2  shows the three abstraction planes, each addressing a particular aspect of the Supercloud system. Each plane is realized with resources from the underlying CSPs. The compute plane enables users to instantiate computational nodes regardless of physical servers hosting computations. The data plane realizes an abstract cloud data storage service transparent to providers and data resources providing the physical storage space. The network plane provides the connectivity between computational and storage resources regardless of the networking infrastructure realizing physical connectivity between servers hosting computational nodes and data storage. A security management framework provides fine-grained control to users over protection of any computational, data, and networking resources in the abstraction planes.
The self-management infrastructure implements autonomic configuration and management of security aspects for the distributed cloud. Such automation means simpler, faster, and more efficient detection and response to threats, minimizing overall human intervention. U-Cloud-specific components also let users control their U-Cloud's security settings. An overall component arbitrates between such settings and provider security requirements. The security response to a threat is elaborated by orchestration of multiple autonomic security loops across infrastructure layers and providers. Other services include flexible isolation, trust management, configuration compliance for auditability, and authorization. users of the Supercloud storage infrastructure. Ordinary clients interact transparently with the data plane via storage proxies.
This requires minimal changes to clients without installing additional libraries. In contrast, direct accessor clients run Supercloud-specific logic as a client library and can interact and access storage servers and L1 cloud provider services directly. Direct accessor clients can also have certain features of storage servers built-in. Such clients could thus also be independent of storage servers. Proxies, typically L2 VMs, facilitate client access to Supercloud storage and data management offerings, such as for encryption and secure deduplication. They're usually stateless and can be easily added dynamically to the system. Servers, typically stateful L1 or L2 VMs, perform housekeeping of critical portions of metadata vital to the Supercloud data plane's operation, such as metadata for storage, data integrity, or configuration management.
Cloud provider services (CPSs) are L1 cloud storage services that direct accessor clients or proxies can directly access. They expose different APIs, notably object storage and block storage. Examples include OpenStack Swift and Amazon's Simple Storage Service (S3) and Elastic Block Store. Cloud provider data nodes are L1 VMs in the distributed provider infrastructure. Complementing CPS, they can perform computation and have locally mounted L1 block storage for Supercloud user data. Security self-management components allow arbitration between provider and user data security settings. Network plane. Figure  3c  illustrates the Supercloud network virtualization architecture. Its main design goals are network controllability; full network virtualization to guarantee isolation between users, while enabling them to use their desired addressing schemes and topologies; and VM snapshotting and migration for availability and flexibility.
To fulfill these objectives, the architecture leverages software-defined networking (SDN),  11  which provides logically centralized control over forwarding and configuration state of the software switches running in the Supercloud VMs. OpenFlow and Open vSwitch (OvS) technologies provide finegrained control of packet forwarding and of switch configurations, respectively. Logical centralization of control facilitates isolation, for example, through flow rule redefinition at the network edge, with translation of physical to virtual events. Availability goals extend well-proven techniques to the multicloud setting. For each user, a specific set of network applications that control the virtual network will run on top the Supercloud network hypervisor that maps the virtual and physical resources.
These include an address translator (to offer L2 and L3 address virtualization), a topology abstraction module (for topology virtualization), and a resource isolation application (to slice network resources among tenants, such as switch CPU and forwarding tables). The network hypervisor controls and configures the OvS switches that are installed in all VMs. An SDN controller will establish secure connections with each OvS switch to control the forwarding plane. The network hypervisor is built as an application that runs in the Supercloud SDN controller. Each cloud will host a specific VM, the network proxy, where secure tunnels are set up to all other clouds. In a distributed configuration, each proxy will host an instance of the SDN controller. Security management is facilitated through the interplay of overall security self-management and network security management components, which enable Supercloud users to specify user-specific settings for network configurations inside their U-Clouds.
Dynamic Architecture Figure  4  illustrates two typical workflows between some key Supercloud architecture components. User 1 interacts with its VM (u1VMx) through a set of APIs. Providers 1 and 2 host compute (VMx), networking (NVMx), and storage management (DVMx) VMs. Provider 1 also hosts a physical storage service. Supercloud considers a nested architecturethat is, u1VMx runs inside VMx. Supercloud users interact through four interfaces to deploy their applications in the cloud. The network plane interface, typically the network hypervisor, interacts with the SDN controller and network proxies, hosted in the NVMx machines, to handle communication and establish secure tunnels with other clouds. The data plane interface, typically storage proxies, interacts with the providers' DVMx VMs to ensure access to the user's private data.
The compute plane interface, typically the L1 hypervisor, interacts with providers' VMx machines to provide memory and CPU resources. We describe the interfaces between Supercloud elements in several scenarios. The first scenario relates to requesting data from the cloud storage; the second relates to establishing communication between two VMs hosted in the Supercloud. The last example shows how the Supercloud security management interfaces enable to deploy security services. Access to cloud storage. In this scenario (steps a-f in Figure  4 ), during a request to the data layer (step a), the user VM (uVM) sends a request to the data management VM (DVM) (step b). The DVM is aware of the resource's physical location inside the cloud infrastructure. It provides this information to the hypervisor hosting the uVM (step c), which will ask the network management VM (NVM) (step d) to establish a connection between resource and uVM through the SDN network (steps e and f).
Hospital Imaging Archive The amount of diagnostic imaging data is quickly increasing, imposing great challenges on hospital archive infrastructures, which must ensure high data availability, security, and regulatory compliance. A cloud-based solution can help address these challenges. Such a solution's architecture should minimize the risk of security breaches and privacy violations, including unprivileged access to data (both at rest and during processing) with regard to defined policies. These policies might include hospital-specific policies context, legal country boundaries, and user groups. In terms of performance, robust data processing with low latency is desired, especially across different clouds. Hospitals can store their clinical data as well as their imaging studies in on-premises private cloud storage.
Archiving in the cloud helps simplify the data management and hospital archive infrastructure-especially due to high-volume imaging studies that are often as large as 1 Gbyte. Since on-premises storage can be limited, it makes sense to store this data securely in public cloud storage. For example, a hospital might store data from the last six months in the private cloud's on-premises storage, while storing older data (10 years or more) in the public cloud. Figure  5a  shows a sample Supercloud implementation of such a solution. In Figure  5a , three hospitals (A, B, and C) share a private cloud to store and manage their clinical data. A VM on the compute plane is dedicated to each hospital for its operations. Whenever a hospital VM wants to store or retrieve clinical data (for example, MRI imaging data), it communicates with a picture archiving and communication system (PACS) VM interfacing with the data plane.
The data plane provides an abstraction to the user VM, making all underlying storage directly accessible (including encrypting stored data). Data older than six months is stored on the public cloud, whereas recent data is kept in the private cloud's on-premises storage, providing instantaneous access to it. Here, the network plane is responsible for handling all communications across different clouds and VMs. Hospitals can also define their security policies, such as how other hospitals can access their data. Components that are dedicated to data security and security management across the L1 hypervisor and compute VMs will prevent any unprivileged access to data based on security policies defined by each hospital.
Healthcare Laboratory Information System This use-case demonstrates the impact of the Supercloud architecture for Maxdata Software, a healthcare software vendor that aims to deploy its software on the cloud as SaaS while enforcing the security requirements of different healthcare institutions. The CLINIdATA®LIS healthcare laboratory information system (LIS) is a cross-platform Web application in which server components can run on any common operating system and relational database. The CLINIdATA®LIS must integrate with dozens of other clinical and nonclinical information systems (such as intensive care units, patient identification, billing, and regional health portals). It includes a set of real-time interfaces with physical electronic equipment (automated analyzers). The solution consists of three components on the server side: a stateless application, a database engine, and database data.
The Supercloud approach allows each healthcare institution to define the U-Cloud that best fits its needs. Concrete deployment on physical cloud providers is then automated. The considered setting is a large hospital cluster that employs thousands of professionals, processes tens of millions of transactions per day, and is located in a country where personal data protection must be guaranteed. In a typical U-Cloud specification, • the application and database engine are replicated across several VMs on the compute plane (fault tolerance and load balancing); • data is split among different storage nodes in the data plane (offering confidentiality, even if one storage node is compromised); • a set of networks connect application VMs to automated analyzers running on hospital premises and to database engine VMs, which in turn are connected to storage nodes; • VMs on the compute plane ensure confidentiality, integrity, and 99.
99 percent availability; • storage nodes on the data plane ensure data integrity and 99. 99 percent availability; and • data may be processed and stored only in a predefined set of countries. As Figure  5b  shows, a Supercloud infrastructure can then deploy the VMs on a trusted private cloud to ensure confidentiality on the compute plane, instantiate the storage nodes on a set of public cloud providers running security mechanisms (such as encryption and secret sharing) to ensure confidentiality, and connect the different components using virtual networks provided by the network plane. Deployments consider the locations or countries specified by the healthcare institution. Replicated instances of the CLINIdATA®LIS application run on VMs on the compute plane. These instances then connect to the database engine running on a different VM linked with the data plane.
Technological advances in molecular biology over the past decade have given rise to high dimensional and complex datasets offering the possibility to investigate biological associations between a range of genomic features and complex phenotypes. The analysis of this novel type of data generated unprecedented computational challenges which ultimately led to the definition and implementation of computationally efficient statistical models that were able to scale to genomewide data, including Bayesian variable selection approaches. While extensive methodological work has been carried out in this area, only few methods capable of handling hundreds of thousands of predictors were implemented and distributed. Among these we recently proposed GUESS, a computationally optimised algorithm making use of graphics processing unit capabilities, which can accommodate multiple outcomes.
In this paper we propose R2GUESS, an R package wrapping the original C++ source code. In addition to providing a user-friendly interface of the original code automating its parametrisation, and data handling, R2GUESS also incorporates many features to explore the data, to extend statistical inferences from the native algorithm (e. g. , effect size estimation, significance assessment), and to visualize outputs from the algorithm. We first detail the model and its parametrisation, and describe in details its optimised implementation. Based on two examples we finally illustrate its statistical performances and flexibility.
Introduction The investigation of associations between genetic and genomic characteristics, such as genome-wide scan or methylation profiles, and complex phenotypes relies on the capacity to link several datasets comprising tens to hundreds of thousands of measurements available usually in hundreds (if not thousands) of individuals and an outcome of interest. In some cases (e. g. , metabolic syndrome) the outcome can be complex and may consist in several correlated measures of continuous variables. In Figure  1 , we illustrate the most general situation of p predictors (typically OMICs measures) being analyzed in relation to q correlated outcomes based on n observations. With the genome-wide association study (GWAS) era, strong methodological efforts have been carried out, and reliable statistical methods for the analysis of such large and complex sets of data have emerged.
This limits the number of outcomes and to ensure interpretability, it is recommended to restrict the use of R2GUESS to a small number (no more than 10) outcomes. In case of a larger number of outcomes, filtering/clustering approaches among the (high dimensional) responses are more suitable through partitioning algorithms  (Monni and Tadesse 2009)  or by adding a hierarchical framework onto the GUESS variable selection procedure  (Bottolo et al. 2011b ). Here we introduce R2GUESS, an R package which provides a user-friendly interface to run the GUESS algorithm  (Liquet and Chadeau-Hyam 2014). In addition to wrapping the C++ source code, R2GUESS also automates the management of input/output files, includes functions to post-process outputs from GUESS and offers additional resources to assess statistical significance and to estimate effect size of the variables identified.
3. Install the R software environment for statistical computing (R Core Team 2013). During installation, R2GUESS tries to automatically detect the location of all required and optional libraries. GPU capabilities are automatically enabled if the CUDA and CULA Dense libraries are found on the system. If CUDA has not been detected, R2GUESS will be installed without GPU support, and linear algebra operations will be performed exclusively on the central processing unit (CPU). The GPU version of R2GUESS yields substantial computational improvements for datasets with large n. However, it may be slower than its CPU alternative on small datasets due to extensive data transfers becoming rate limiting. In such cases, GPU capabilities can be disabled by specifying the argument CUDA = FALSE to the main function R2GUESS().
Usage In this section we describe how to use R2GUESS. Based on a simulated dataset, we will first illustrate the high specificity of our model selection procedure and will investigate its computational efficiency. The full capacity of R2GUESS will be further investigated by a step-by-step analysis of a realistic dataset embedded in the package. We will exemplify the use of the main functions that are useful to analyze the outputs the code generates (as detailed in Tables  3  and 4 ). Our approach offers, as a default, automatic tuning of most hyper-parameters. This tuning has been developed with the aim of improving convergence of the MCMC procedure, and default values compiled in the xml parameter file, were defined such that they fit most of the datasets. However, for datasets in which convergence appears slower, these can be userdefined in a personalized parameter file.
Our simulation presented in (  19 ) was further generalized in order to account for the effect of potential confounders (noted ), where is an k × q matrix compiling the regression coefficients linking the k confounders in and the q outcomes in. As above, c is calibrated such that the expected proportion of variance explained is no greater than 5%. We ran our simulator including confounders using the same parameters as above for the simulation containing two "causal" SNPs (r = 2). In that setting, k was set to 2 and we chose (23) assuming a strong confounding effect of the two covariates. The two covariates are generated from two independent standard Normal distributions. Analyzing data-Based on our simulation model, we created two datasets setting n = 1, 500, and p = 5, 000. These were analyzed using R2GUESS setting E(p γ ) = 5, VAR(p γ ) = 5, and L = 3.
Among the two remaining signals, one had lower MPPI values but was found significant (SNP 4209, MPPI > 0. 89). SNP 3682 had an MPPI lower than 0. 01 but corresponded to the 8th highest value. In Figure  7 , the posterior distribution of the regression coefficients derived from the best model is summarized, using the samplebeta() function. Results are presented for the simulated dataset comprising two causal SNPs (1396 and 2009) which were allocated regression coefficients with respect to Y 1 , Y 2 , and Y 3 as described in (21). From Figures  7(a ) and (b) it is apparent that R2GUESS successfully inferred the effect size of the causal SNPs with relatively narrow distributions containing the true value used for the simulation, particularly for SNP 2009. Greater error is observed for SNP 1396, which can be attributed to our simulation setup resulting in higher residual variance for that SNP.
R2GUESS was also run on the simulated dataset including two confounders as detailed in (23); results are summarized in Figure  8. Despite strong confounding effects, R2GUESS identified both causal SNPs used for the simulation (Figure  8 (a)). As in the original simulation, SNP 1396 was included in all 100 best models (MPPI = 1). In contrast, SNP 2009 showed lower MPPI than in the model without confounding. This is due to the fact that while adjusting for the strong effect of confounders, the best model (MPP = 0. 57) did not include SNP 2009. That second SNP only appeared in the second best model (with a MPP = 0. 38). In addition. Figures  8(b ) and (c) show highly consistent effect size estimates for the model including confounders, with the exception of the third outcome which corresponds to weaker effect size and small proportion of variance explained (simulated proportion of explained variance was around 5 × 10 -5 , which was 40 and 10 fold lower than for the first and second outcomes respectively).
Computational performance: GPU/CPU choice-Enabling GPU capabilities in R2GUESS will re-route computationally expensive matrix operations to the GPU and will therefore generate extensive data transfer with the CPU. In some cases, typically for small datasets, matrix operations are not rate limiting, and data transfer between CPU and GPU represents a major bottleneck, leading to the GPU version being slower than the CPU one. In these instances it may thus be desirable to disable GPU support. This can be easily achieved by specifying the argument CUDA = FALSE in the call to the function R2GUESS(). To guide the choice of the user, we extended our simulations to several values of n ranging from 100 to 3,000, p from 500 to 250,000 and three different values of r = 2, 8, and 15. For each of the 60 simulated datasets, we ran R2GUESS and recorded computing times.
As expected, computing time increases with n, and to a lesser extent with p and r in both versions of R2GUESS. Relative computing performances for the CPU and GPU versions of R2GUESS seem to generally favor the CPU version for n ≤ 500 irrespective of p and r. Computational benefits of the GPU version of R2GUESS are clear for large datasets (n ≥ 3, 000) and are increasing with p. As an indication, genome-wide runs reported in  Bottolo et al. (2013) (n = 3, 122, p = 273, 675)  took around 80 hours for 60,000 iterations using the GPU version, while after 200 hours, the CPU version had not reached 15,000 iterations.
R2GUESS in practice: Real data example The example dataset included in R2GUESS originates from a larger study  (Heinig et al. 2010 ) from which we selected the Hopx genes, as in  Petretto et al. (2010). For each gene, we investigated the ability of R2GUESS to identify a parsimonious set of predictors that explains the joint variability of gene expression in four tissues (adrenal gland, fat, heart, and kidney). The dataset consists of 770 SNPs in 29 inbred rats as a predictor matrix (n = 29, p = 770), and the 29 measured expression levels in the 4 tissues as the outcome (q = 4). In our example, we follow the parametrization of  Petretto et al. (2010)  and fix E(p γ ) = 5 and VAR(p γ ) = 5. This supposes an a priori number of predictors ranging from 0 to 12, with increasing penalization of values outside this range.