dataesr/scientific-paragraphs-categorization huggingface dataset:
), but these variables are typically defined in the (gnu packages. ) modules that Guix comes with. Thus the precise packages being installed depend on the version of Guix that is available. Specifying the Git commit of Guix in addition to the declaration in Figure  3  is all it takes to reproduce the exact same /gnu/store items. Another approach to achieve bit-identical reproduction of a user's profile is by saving the contents of its transitive closure using guix archive --export. The resulting archive can be transferred to another system and restored at any point in time using guix archive --import. This should significantly facilitate experimentation and sharing among peers.
Customizing Packages Our colleagues at Inria in the HiePACS and Runtime teams develop a complete linear algebra software stack going from sparse solvers such as PaStiX and dense solvers such as Chameleon, to run-time support libraries and compiler extensions such as StarPU 4  and hwloc. While developers of simulations want to be able to deploy the whole stack, developers of solvers only need their project's dependencies, possibly several variants thereof. For instance, developers of Chameleon may want to test their software against several versions of StarPU, or against variants of StarPU built with different compile-time options. Finally, developers of the lower-level layers, such as StarPU, may want to test the effect of changes they make on higher-level layers. This use case leads to two requirements: that users be able to customize and non-ambiguously specify a package DAG, and that they be able to reproduce any variant of their package DAG.
Guix allows them to define variants; the code for these variants can be stored in a repository of their own and made visible to the guix commands by defining the GUIX PACKAGE PATH environment variable. Figure  4  shows an example of such package variants: based on the preexisting starpu variable, the first variant defines a package for a new StarPU release candidate, simply by changing its source field, while the second variant adds the optional dependency on the SimGrid simulator-a variant useful to scheduling practitioners, but not necessarily to solver developers. These StarPU package definitions are obviously useful to users of StarPU: They can install them with guix package -i starpu and similar commands. But they are also useful to StarPU developers: They can enter a "pristine" development environment corresponding to the dependencies given in the recipe by running guix environment starpu --pure.
This command spawns a shell where the usual PATH, CPATH etc. environment variables are redefined to refer (define starpu-1. 2rc ;release candidate (package (inherit starpu) (version "1. 2. 0rc2") (source (origin (method url-fetch) (uri (string-append "http://starpu. gforge. inria. fr/files/" "starpu-" version ". tar. gz")) (sha256 (base32 "0qgb6yrh3k745grjj14gc2vl6a99m0ljcsisfzcwyhg89vdpx42v")))))) (define starpu-with-simgrid (package (inherit starpu) (name "starpu-with-simgrid") ;name shown in the user interface (inputs '(("simgrid" ,simgrid) ,@(package-inputs starpu))))) precisely to the inputs specified in the recipe. This amounts to creating a profile on the fly, containing only the tools and libraries necessary when developing StarPU. This is notably useful when dealing with build systems that support optional dependencies.
(define (make-chameleon name starpu) (package (name name) ;; [other fields omitted] (inputs '(("starpu" ,starpu) ("blas" ,atlas) ("lapack" ,lapack) ("gfortran" ,gfortran-4. 8) ("python" ,python-2))))) (define chameleon (make-chameleon "chameleon" starpu)) (define chameleon/starpu-simgrid (make-chameleon "chameleon-simgrid" starpu-with-simgrid)) Fig. 5. Defining a function that returns a package object for the Chameleon solver. Now that we have several StarPU variants, we want to allow direct and indirect users to select the variant that they want. A simple way to do that is to write, say, a function that takes a starpu parameter and returns a package that uses it as its input as show in Figure  5. To allow users to refer to one or the other variant at the command line, we use different values for the name field.
This approach is reasonable when there is a small number of variants, but it does not scale to more complex DAGs. As an example, StarPU can be built with MPI support, in which case Chameleon also needs to be explicitly linked against the same MPI implementation. One way to do that is by writing a function that recursively adjusts the package labeled "mpi" in the inputs field of packages in the DAG. No matter how complex the transformations are, a package object unambiguously represents a reproducible build process. In that sense, Guix allows environments to be reproduced at different sites, or by different users, while still supporting users needing complex customization.
Limitations and Challenges Privileged daemon. Nix and Guix address many of the reproducibility issues encountered in package deployment, and Guix provides APIs that can facilitate the development of package variants as is useful in HPC. Yet, to our knowledge, neither Guix nor Nix are widely deployed on HPC systems. An obvious reason that limits adoption is the requirement to have the build daemon run with root privileges-without which it would be unable to use the Linux kernel container facilities that allow it to isolate build processes and maximize build reproducibility. System administrators are wary of installing privileged daemons, and so HPC system users trade reproducibility for practical approaches. Cluster setup. All the guix commands are actually clients of the daemon. In a typical cluster setup, system administrators may want to run a single daemon on one specific node and to share /gnu/store among all the nodes.
At the time of writing, Guix does not yet allow communication with a remote daemon. For this reason, Guix users at the MDC are required to manage their profiles from a specific node; other nodes can use the profiles, but not modify them. Allowing the guix commands to communicate with a remote daemon will address this issue. Additionally, compute nodes typically lack access to the Internet. However, the daemon needs to be able to download source code tarballs or pre-built binaries from external servers. Thus, the daemon must run on a node with Internet access, which could be contrary to the policy on some clusters. OS kernel. By choosing not to use a full-blown VM and thus relying on the host OS kernel, our system assumes that the kernel interface is stable and that the kernel has little or no impact on program behavior.
While this may sound like a broad assumption, our experience has shown that it holds for almost all the software packages provided by Guix. Indeed, while applications may be sensitive to changes in the C library, only low-level kernel-specific user-land software is really sensitive to changes in the kernel. The build daemon itself relies on features that have been available in the kernel for several years. Non-determinism. Despite the use of isolated containers to run build processes, there are still a few sources of non-determinism that build systems of packages might use and that can impede reproducibility. In particular, details about the operating system kernel and the hardware being used can "leak" to build processes. For example, the kernel Linux provides system calls such as uname and interfaces such as /proc/cpuinfo that leak information about the host; independent builds on different hosts could lead to different results if this information is used.
Related Work Reproducible builds. Reproducible software environments have only recently become an active research area. One of the earliest pieces of work in this area is the Vesta software configuration system  [9]. Vesta provides a DSL that allows users to describe build operations, similar to Nix  [3]. More recently, projects such as Debian's Reproducible, Fedora's Mock, or Gitian have intended to improve reproducibility and verifiability of mainstream package distributions. Google's recent Bazel build tool relies on container facilities provided by the kernel Linux and provides another DSL to describe build operations. Reproducibility can be achieved with heavyweight approaches such as full operating system deployments, be it on hardware or in VMs or containers  [1, 8, 10, 11]. In addition to being resource-hungry, these approaches are coarse-grain and do not compose: if two different VM/container images or "software appliances" provide useful features or packages, the user has to make a binary choice and cannot combine the features or packages they offer.
Furthermore, "Docker files", "Vagrant files", and Kameleon "recipes"  [11]  suffer from being too broad for the purposes of reproducing a software environment-they are about configuring complete operating systems-and from offering an inappropriate level of abstraction-these recipes list commands to modify the state of the system image to obtain the desired state, whereas Guix allows users to declare the desired environment in terms of software packages. Lastly, the tendency to rely on complete third-party system images is a security concern 5 Building upon third-party binary images also puts a barrier on reproducibility: Users may have recipes to rebuild their own software from source, but the rest of the system is essentially considered as a "black box", which, if it can be rebuilt from source at all, can only be rebuilt using a completely different tool set.
HPC package management. In the HPC community, efforts have focused primarily on the automation of software deployment and the ability for users to customize their build environment independently of each other. The latter has been achieved by "environment modules", a simple but efficient tool set that is still widely used today  [4]. Build and deployment automation is more recent with the development of specialized package management tools such as EasyBuild  [7]  and Spack  [5]. Both EasyBuild and Spack have the advantage of being installable by unprivileged users since they do not rely on privileged components, unlike Guix and Nix. The downside is that they cannot use the kernel's container facilities, which seriously hinders build reproducibility. When used in the user's home directories, each user may end up rebuilding the same compiler, libraries, etc.
, which can be costly in terms of CPU, bandwidth, and disk usage. Conversely, Nix and Guix support safe sharing of builds. EasyBuild aims to support multiple package variants, such as packages built with different compilers, or linked against different MPI implementations. To achieve that, it relies on directory naming conventions; for instance, OpenMPI/-1. 7. 3-GCC-4. 8. 2 contains packages built with the specified MPI implementation and compiler. Such conventions fail to capture the full complexity of the DAG and configuration space. For instance, the convention arbitrarily omits the C library, linker, or configuration flags being used. EasyBuild is tightly integrated with environment modules  [4] , which are familiar to most users of HPC systems. While modules provide users with flexible environments, they implement an imperative, stateful paradigm: Users run a sequence of module load and module unload commands that alter the current environment.
This can make it much harder to reason about and reproduce an environment, as opposed to the declarative approaches implemented by guix package --manifest and guix environment. Like EasyBuild and similarly to Guix, Spack implements build recipes as first-class objects in a general-purpose language, Python, which facilitates customization and the creation of package variants. In addition, Spack provides a rich command-line interface that allows users to express variants similar to those discussed in Section 4. 2. This appears to be very convenient for common cases, although there are limits to the expressivity and readability of such a compact syntax.
Conclusion Functional package managers provide the foundations for reproducible software environments, while still allowing fine-grain software composition and not imposing high disk and RAM costs. Today, GNU Guix comes with 2,060 packages, including many of the common HPC tools and libraries as well as around 50 bioinformatics packages. It is deployed on the clusters of the MDC Berlin, and being discussed as one of the packaging options by the Open Bioinformatics Foundation, a non-profit for the biological research community. We hope to see more HPC deployments of Guix in the foreseeable future. GNU Guix benefits from contributions by about 20 people each month. It is the foundation of the Guix System Distribution, a standalone, reproducible GNU/Linux distribution.
Moonlighting proteins are defined by their involvement in multiple, unrelated functions. The computational prediction of such proteins requires a formal method of assessing the similarity of cellular processes, for example, by identifying dissimilar Gene Ontology terms. While many measures of Gene Ontology term similarity exist, most depend on abstract mathematical analyses of the structure of the GO tree and do not necessarily represent the underlying biology. Here, we propose two metrics of GO term functional dissimilarity derived from biological information, one based on the protein annotations and the other on the interactions between proteins. They have been collected in the PrOnto database, a novel tool which can be of particular use for the identification of moonlighting proteins. The database can be queried via an web-based interface which is freely available at http://tagc.
In this paper, we present the metrics, the webtool we provide to the community as well as different usage examples among which our recent characterization of potential moonlighting proteins from the human PPI network  (Chapple et al. , 2015). The current version of the PrOnto database contains probabilities for human, mouse, fly, worm and yeast (see Supplementary Table  1  for database statistics). The database will be regularly updated to keep up with annotation and interaction data. PrOnto is free and accessible through a simple webbased interface (see Figure  2  available at http://tagc. univ-mrs. fr/ pronto).
Building High Quality PPI Networks To calculate the IPs, a high quality interactome was compiled for each target species. Interaction data were retrieved using the PSIQUICK  (Aranda et al. , 2011)  interfaces of the APID  (Prieto and Rivas, 2006), BioGrid (Chatr-Aryamontri et al. , 2013) , IntAct  (Kerrien et al. , 2012) , DIP  (Salwinski et al. , 2004) , MINT  (Ceol et al. , 2010) , MatrixDB  (Chautard et al. , 2009) , Reactome  (Croft et al. , 2011) , InnateDB  (Lynn et al. , 2008) , MolCon, Spike  (Elkon et al. , 2008) , and TopFind  (Lange and Overall, 2011)  databases. Interaction data were filtered by identification method and only binary interactions between proteins were kept. A full list of the PSI-MI IDs used to build out networks is provided as Supplementary Table  2. Protein names were mapped to UniProt IDs, and sequences, downloaded from UniProt, clustered using CD-HIT  (Fu et al.
, 2012). TrEMBL/SwissProt protein pairs sharing ≥95% similarity were considered to be the same protein: interactions of the TrEMBL protein were then inherited by the Swiss-Prot protein. Self interactions were discarded. The final result was high quality interactomes consisting entirely of experimentally verified, direct, binary interaction pairs  for each species studied. These networks will be regularly updated with each update of PrOnto. Current interactomes are available on the downloads page of the PrOnto database (http://tagc. univmrs. fr/pronto/index. php?id=downloads).
Tools and Resources Used The probabilities were calculated using the phyper function of the R statistical environment (R Core Team, 2012) and protein annotations were taken from the EBI's QuickGO service  (Barrell et al. , 2009)  (ftp://ftp. ebi. ac. uk/pub/databases/ GO/goa/). The power of the test was calculated using the power. fischer. test function of the statmod R package and 1000 simulations per pair. Jaccard indeces and Cohen's kappa were calculated using a simple awk script. The PrOnto webpage is written using a combination of HTML, PHP, and Javascript, the data are stored in a MySQL database which is queried using a Perl script.
Globally, as shown in Table  1 , where the percentages of dissimilar and not dissimilar GO term pairs are reported for each species, most GO term pairs are not dissimilar according to PrOnto (AP, 84. 1-87. 1% and IP, 54. 2-72. 3%). Since the cell is a complex system whose constituent parts are very often interlinked  (Schwikowski et al. , 2000) , many GO terms cooccur more often than expected by chance among gene/protein annotations or between interacting proteins. This link between processes in the cell is thus captured by PrOnto which is based on functional data. As expected, since PrOnto is based on existing protein annotations, dissimilar terms according to PrOnto are rare (AP, 0. 2-0. 6%). That they are more numerous in the IPs (0. 5-4. 9%) shows functions that are rarely carried out by interacting proteins, therefore suggesting that they are performed by different functional modules, known as groups of interacting proteins involved in the same biological process  (Spirin and Mirny, 2003).
Among the striking features, candidates are more connected in the network, enriched in short linear motifs and in disease-related proteins compared to noncandidates, and are less intrinsically disordered than network hubs  (Chapple et al. , 2015; Zanzoni et al. , 2015). These results therefore underline that PrOnto is particularly well suited to identify moonlighting candidates from biological data since it is especially stringent when determining term dissimilarity (see Tables  1, 2 ). As we provide PrOnto probabilities for multiple species, we predict that it will be soon used for the identification of moonlighting candidates in these other species. Finally, it should be noted that a recent analysis of GO terms has been proposed to identify moonlighting candidates in E. coli  (Khan et al.
Other PrOnto uses Overall, APs can be used to identify cellular processes that are rarely carried out by the same proteins (i. e. , "dissimilar"), whereas IPs can offer insights into the links between different cellular processes mediated by protein interactions. In addition their use for the investigation of the links between the functional modules formed by interacting proteins in PPI networks as described above, APs and IPs could also be used to score protein interaction predictions. In some cases, in the absence of experimental data, protein-protein interactions are predicted using bioinformatics approaches. One may then want to assign a confidence score based on real biological data to these predictions. Because PrOnto probabilities are derived from biological knowledge and experimental data, they can be used for this purpose and a lower score can be assigned to predicted interactions between proteins annotated to dissimilar terms.
Depending on the analysis, either symmetric or asymmetric probabilities might be preferred. In addition, both methods (QuickGO and FAM) provide co-occurrences calculated from the entirety of the UniProt database whereas PrOnto considers a specific species' proteome or interactome. A species-specific measure can indeed be considered an asset depending on the analysis being undertaken since cellular and physiological functions often differ between species, essentially due to tissue-specificity. Term co-occurences are therefore expected to be different across species. Moreover, neither method provides the user with the ability to input a list of terms and obtain a list of probabilities nor the possibility of querying for specific pairs. The web-based interface of PrOnto is designed with that in mind and is a simple and practical way of quantifying GO term functional dissimilarity.
Finally, PrOnto is, to our knowledge, the only tool that offers a measure of GO term functional dissimilarity based on a species' interactome. A similar approach was undertaken by  Dotan-Cohen et al. (2009)  to identify "Process Linkage Networks" rather than to assess GO term functional dissimilarity. While they used interactome data of a single species to build these networks, they did not provide a tool to the community.
Conclusion We have presented PrOnto, a novel tool for quantifying GO term functional dissimilariy based on two species-dependent metrics of GO term association derived from either the annotations or the interactome data of the species in question. This tool was developed for the specific goal of identifying moonlighting proteins from interactome data. As such, the emphasis has been on the identification of dissimilar functions. The current version of PrOnto is using a relatively simple statistical approach which, nevertheless provides robust results (see  Chapple et al. , 2015  and Supplementary Figure  1 ). In the future, in addition to the hypergeometric probability, power and Jaccard indeces, we plan to implement other statistical measures and combine them into a single metric of GO term similarity.
The required coordination between the participating organizations (e. g. , along a supply chain) further complicates this issue. Hence, there is a strong need for an integrative infrastructure enabling the collaboration between different organizations developing product lines. The approach needs to support different variability modeling languages, notations, and tools. It also needs to support variability at different levels of granularity to model, e. g. , customer-facing features, architectural elements, or configuration decisions. We propose the Invar approach, which facilitates the integration of heterogeneous variability models 2  potentially created by different teams. In this paper we focus on the product configuration aspects of our integrative infrastructure. Invar deliberately hides the internal technical aspects of using different variability models for configuration from the stakeholders performing the configuration.
The specific tools or data formats (see  [3, 4, 5] ) used for defining the variability models are not relevant for the end users who primarily focus on the available configuration choices and their implications. Invar unifies configuration operations on variability models and allows modelers to freely choose a data representation by accessing variability models through web services. Our approach does not force organizations to integrate their configuration tools by adapting the internals of the tools. Instead, we allow them to compose their configuration mechanisms using wrappers and interface definitions. We validate our approach by integrating three different variability modeling "dialects", i. e. , feature modeling, orthogonal variability modeling (OVM), and decision modeling. We also show how typical scenarios in software ecosystems can be supported with Invar and assess the performance of Invar regarding the different model enactment strategies of the approach, e.
For instance, the ERP Vendor Feature Model shown in Figure  3  defines the features CRM, Project Management and Accounting as optional subfeatures of the feature ERP Solution. The Orthogonal Variability Model (OVM). OVM is commonly used for documenting software product line variability  [8]. In an OVM model a variation point (VP) defines a variable item that can vary from one product to another. Variants (V) document how the variation points can vary. For instance, in the OVM model Calendar Supplier 1 shown in Figure  3  Messaging is a VP and SMS and MMS are Vs. All VPs are related to at least one V and each V is related to exactly one VP. Both VPs and Vs can be either optional or mandatory. A mandatory VP must be bound in all products of the product line which is not the case for optional VPs.