dataesr/scientific-paragraphs-categorization huggingface dataset:
The dependencies required to build the container are not described within the container. (c) Guix workflow uses the list of software and packages combined with a fixed state of dependencies defined in a channel. With these two inputs, Guix build the computation environment. Here, all steps of computing environment compilation are transparent and reproducible. a practical viewpoint. Instead, the binary container is gathered from binaries usually produced by some package managers. This approach is widely deployed and, at some extent, has successfully been used for reproducing analysis  10, 12. However, when reproducing an analysis using a container, two core questions need to be addressed: (i) how to inspect the binary container for validating the results  13  , and (ii) how to reproduce later this container.
Some popular Linux distribution provides snapshots of their state at specific moments, but, to our experience, their use is complex  15. Online infrastructures: delegate the issue. On a side note, effort is currently being developed to implement interactive scripts within articles  16  or interactive web-based interface to analyze data (e. g. Cytobank  17  , Omiq, Metaboanalyst  18  , Galaxy  19  ). These tools are useful to ease interaction with complex data and to provide a simplified workflow of analyses. However, these do not capture the whole computational environment required to run analyses from the source code. Moreover, it raises the question about the long-term support for the computational infrastructure running these scripts, assuming such infrastructure are fully transparent and verifiable.
To our knowledge, these online infrastructures hit the same core question as the ones for package managers and containers. Solution: share reproducible computational environment. For being truly long-term reproducible, the solution must capture the whole computational environment, control the complete recursive stack and be able to redeploy anytime. Guix (https://guix. gnu. org) attempts to apply principles from functional programming to package management, work pioneered by Nix (https://nixos. org). The installable binary package is modelled by "pure functions": the installable binary package corresponds to a process where its output only depends on the inputs (build-time and run-time dependencies)  20. Therefore, Guix provides a deployment system that ensures reproducibility by design. The Guix system is implemented using the Scheme language  21  , from the core to the high-level domain-specific language (DSL) for specifying and declaring the configuration.
To our opinion, the main difference between the Guix and Nix systems is, for the former a continuity from the high-level declarative configuration to the core which allows to adapt or extend the Guix system, and for the latter, on one hand "Nix expressions" written in a DSL specifically designed to define these "pure functions" (derivation), and on the other hand another language for the core. This difference is slight in practice but emphasized by the data processing workflow engines Guix Workflow Language (GWL) based on Guix and BioNix  22  based on Nix (https://youtu. be/pwYhPqaUiGg, https:// youtu. be/tpLcwfRXL28). Last, to our knowledge, the Nix system does not provide yet a mechanism easing the time travel. Reproducible computational environment using Guix. Here, we describe how computational part of the reproducibility cycle is addressed when using Guix.
As exposed previously, two components have to be provided: the list of software effectively used and an identifier committing the complete stack. First, the manifest listing the top-level software or library names effectively used by the analysis is provided in a text file, e. g. , named manifest. scm. For instance, this manifest file contains the software or library names which are often already described by some papers. Software are packaged in Guix using a recipe, and this recipe notably points to the location of the upstream sources, provides the version label and lists the dependencies for building and running. If the required tool is not indexed yet by Guix, the missing package may be then locally defined by providing an extra file which describes the recipe to build such tool. Moreover, Guix also provides custom channels feature to ease the exchange of such recipes contributed by the community or dedicated to a particular field.
2c ). Based on these two files manifest. scm and channels. scm, an independent user is able, using the subcommands "environment" (or newly renamed "shell") and "time-machine", to deploy the exact same computational environment. If the infrastructure requires a container image, Guix has the capacity to directly pack Docker or Singularity images (Fig. 3 ). For transparency, it is an encouraged practice  7  to version these additional manifest. scm and channels. scm files along with the other source files required by the analysis. Last, when upstream sources are no longer available on their initial web address (URL), Guix provides a bridge to the Software Heritage (SWH) initiative. The mission of SWH is to collect, archive and preserve scientific knowledge residing in source code  24. Therefore, the computational environment managed by Guix can Fig.
3  Comparison of workflows in building and sharing environment. (a) Multiple contributors may participate in one project. Even with the same list of software and libraries, local dependencies are required to build the environment. Thus, each contributor will use a unique environment that differs from the other ones. To circumvent this issue, one user can build a container and share it. But, the container may be lost in the future. Since systems and dependencies are evolving fast, there is no guarantee that future scientist will be able to build the initial container again. (b) Using Guix, the version of the dependencies graph (channel. scm) is described with the list of software and packages (manifest. scm). Any contributor can build the environment or even pack a container at any time. One user can thus travel through time of systems dependencies graph just by changing the channel.
scm file and reproduce a lost container or an old environment on which previous analyses were performed. This ensure that reproducibility issues do not come from changings in computational environment. be deployed regardless of the availability of all initial sources, if these sources have been archived by SWH and upstream is missing, then Guix automatically uses the SWH archive as fallback. case study: cytometry analyses on an environment reproduced by Guix. The Guix workflow is straightforward. It requires two components, the list of required software and packages and the graph modeling the complete stack of dependencies. To illustrate how Guix may be used for reproducible research, we consider a fully open access, open data, open source research article  25. This example allows us to point out two levels of details: first we present how to implement the Guix workflow at the time of publication; and second, we describe how Guix concretely helps in the reproduction once the analysis published.
10 released on October, 2019. We assume that, at the time of the publication, the authors provided as Materials and Methods the file channels. scm fixing the Guix state at that time. Next, we describe the software (R libraries) used for the analyses in the file manifest. scm (Fig. 4b, c ). Note that the package "r-cydar" is not part of the package collection that Guix provides by default. We thus need to extend the package collection and describe by ourselves the recipe to build this package from its sources hosted on Github. Guix provides facilities to obtain such recipe (https://guix. gnu. org/manual/devel/en/guix. html#Invoking-guix-import) (Fig. 4d ). The recipe we used can be found within the file "my-pkgs. scm" in the directory "my-pkgs". From these two files manifest. scm and channels.
scm" and "manifest. scm". As a proof of concept for inspection, we partially run the analysis using Gitlab. com runners as foreign infrastructure, partially because we applied a downsamplig to reduce the size of the data in order to satisfy the resource offered on this public Gitlab instance. Using this framework, the environment as it was used at time of publication is saved and can be redeployed in other systems or in the future. If the addresses of source code are unavailable, Guix automatically will fetch source code from SWH (Fig. 4e ). This last feature allows long-term reproducibility of computational environment. The main challenges for reproducing the output from the markdown file were not related to software but to data access. Data had to be fetched manually because of the lack of public application programming interface (API) on Flowrepository.
Discussion Computational reproducibility is not only a matter of transparency but also a matter of backward compatibility. Hardware and software are evolving fast. Old digital supports are no more compatible with current technologies. Likewise, source codes of analyses from 10 years ago are difficult to reproduce nowadays  26. Here we described how Guix, a package manager, may be used in daily practice to perform analyses on transparent and reproducible computational environment. One of the main advantages of Guix is its backward compatibility. Unexpectedly, Guix development provided a practical example of such software evolution and how potential incompatibilities may be tackled. While we wrote this manuscript, a new subcommand, "shell", that aims at replacing the "environment" one was introduced (https://guix.
gnu. org/en/blog/2021/ from-guix-environment-to-guix-shell). Reproducibility of computation from the source code written for this manuscript is guaranteed by the subcommand "time-machine". Although the subcommand "environment" is disappearing, by pointing to the older revision in which this subcommand is available, Guix is able to build an old version of itself. Then, because this old version of Guix capture the graph of dependencies, it becomes simple to instantiate again the exact same computational environment as we demonstrated when reproducing one paper from two years ago. Fig. 4  Anatomy of Guix workflow used in the case-study paragraph. (a) The channels. scm file defines the channel that will be used to build the graph of dependencies from a list of recipes. This list is fixed at one time in a Git repository.
This time-point is accessed with the commit number written in the channel definition. (b) The manifest. scm file defines the list of software and packages used in the computational environment. The "r-cydar" package is not defined in the channel thus we have to write the recipe to build it. The command line "guix import" is used to access the recipe from Guix. (c) Guix uses the recipes defined in the channel to build the environment, from compilers to the list of software and libraires defined in the manifest. scm. (d) All software and packages are defined with the same arguments that are described on the figure. Briefly, a list of dependencies (modules) is defined at the start of the recipe, then the package definition starts with a commit number to version the package. Because the package comes from Git, a git-fetch method is used to gather the source code which is checked for integrity with a hash number (sha256).
Next, the method to build the binary is defined with the run-time and build-time dependencies that will be required to run the package. (e) The previous steps rely on the hypothesis that URL addresses of the source codes and channels are available to build the environment. In case these addresses are lost, Guix provides a bridge to Software Heritage source code archive to ensure long-term support. Guix implementation is straightforward for users used to command lines interactions. Guix already support more than 20,000 packages and more are regularly added. With only two text files, users can define their computational environment. For most users, the state of all the dependencies are usually specified at the beginning of a project and consists on describing the revision of Guix (commit number).
This can be achieved by running one command line that do not require knowledge on Guix Git repository. Readers can access the "R_workflow" directory of our Git repository to start using Guix to build a simple R environment and create their first "channels. scm" and "manifest. scm" files. Moreover, the required tools are just listed in a file and the missing one, if any, can be locally added. Compared to containers, the Guix approach is more flexible and transparent. The environment is not fixed and can evolve alongside with the project without requiring to build new container when new tools must be implemented. There are several limitations to Guix. The first one is that Guix operates only the Linux kernel. To our knowledge, the full control of the build-time environment is the key to success in reproducible research and such fined-grained control is only available using low-level Linux kernel features requiring special privileges.
This limitation about running on the Linux operating system is rooted in solving the chicken or the egg problem of bootstrap (the deep roots of the graph). This limitation is counterbalanced by the fact that Guix requires root access only in the installation process and then any user is able to run Guix commands without special privileges. Furthermore, users without root access or who are not using Linux, can still run the transparent and reproducible container images generated with Guix. Another limitation is that proprietary software are poorly not supported by Guix and pipelines requiring their use cannot be reproduced in that way. This limitation is strongly moderated by the fact that opaque proprietary software is not transparent and thus does not support open research. The availability of data, source code, scripts, paper, material and methods are necessary requirements for open research but not a sufficient condition for inspecting such research.
For instance, their availability tends to decrease after being reported in an article  27, 28. Open access implicitly implies the resilient lookup. It asks, for one about robust identifier and integrity verification, and for two about distributed workload. This latter is out of our scope and it refers to addressing the link rot phenomenon by designing other networks, such as IPFS (https:// ipfs. io), GNUnet (https://www. gnunet. org/en/index. html) or RINA (http://csr. bu. edu/rina/index. html). For the former, intrinsic identifiers, which only depend the content itself, opposed to extrinsic identifier attributed by an external authority, aims at providing persistent, unforgettable and verifiable systems. For example, a version of source code referred by a label name is extrinsic and the identification is not always straightforward because this label is not necessarily unique or immutable.
On the other hand, Git commit hash summarizes the content itself and thus identifies the source code without any ambiguity (modulo hash function collision). Other examples of intrinsic identifier for citing software are used by the Software Heritage source code archive and discussed in detail by Alliez et al. 29   Reproducibility of the computational environment is driven by transparency. To be fully reproducible one computational environment must be defined by (i) the source code of the software and libraries used (ii) the various options or configuration are required at build-time or run-time and (iii) the complete graph that fixes all the dependencies. Package manager like Nix  22  and Guix are designed around these three requirements. By using Nix or Guix, scientists are now able to easily share their computational environment.
Our key contribution is to introduce a 2D vector noise combined with a subsequent more complex, two-dimensional transfer function. Our bi-variate approach significantly increases the range of patterns that can be modeled using only noises yet keeping the shader program very simple (thus adapted to real-time applications). Furthermore, it also comes with a known filtering method. After a review of the literature (section 2), this paper presents the following contributions: • a new stochastic pattern model, based on the composition of a 2D transfer function by a vector noise (section 3); • a real-time method to estimate the footprint statistics (section 4), which allows for accurate real-time filtering; • a practical GPU implementation using WebGL (section 5); • a series of results (section 6) exhibiting a variety of new procedural patterns, as well as improvements for known techniques (LEAN mapping, phasor noise).
Implementation and performance To allow easy experimentation of our method for all readers, we choose to do the implementation using WebGL2. 0. (based on the specification of OpenGL ES 3. 0). This allows us also to ensure that it could really be implemented on almost any graphics hardware. The tiling and blending part has been inspired by the original code from Deliot et al. [DH19]. The input textures (noises, variances, and color-maps) can be stored on 1-byte fixed precision channel as usage of 32 bits floating-point storage does not improve visual quality. As the variance values are always below 0. 05 we multiply it by 16 to optimize the fixed precision of the eight bits channel. All intermediate computations are done and temporarily stored with floating-point precision to avoid approximation.
Introduction IoT (Internet-of-Things) devices are inexpensive, lightweight, commodity hardware that are mostly used to interact with real-world or cyber-physical entities. They are tiny pieces of computational hardware, equipped with substantial storage and confined software that helps run the assigned task. Earlier in the 1990s, they were widely used in the industrial environment where physical tasks were automated. In current times, it has become easier to integrate IoT devices in more use cases such as smart-homes, automated vehicles, medicine, and hardware crypto wallets. With this development, the challenge to secure the huge data generated by IoT devices has become more pressing. Moving away from legacy solutions by alleviating the need for a trusted third party, the decentralized nature of blockchains can fit well with the IoT use cases  [1].
In DAG-based ledgers, the scope of scaling is not well-defined  [29]  and its use cases have been difficult to comprehend as per any current and potential demand. In this paper, we discuss the offline scaling aspects of DAG-based IOTA blockchain and how accommodating the real-world trend of IoT devices being taken offline will be a feature moving forward. As shown in Figure  2 , the use of partial-synchronization of data between public blockchain and private networks where IoT devices are deployed can solve the problem described in Section 2. 1. It is essential moving forward that blockchains are offering offline scaling along with other features as mentioned above in Section 2. 2.
Such conditions would make it quite complex to accommodate the private/offline ledger use cases. In the work of Karlsson et al. [33] , a fault-tolerant permissioned blockchain has been proposed where, in order to let the IoT blockchain grow under network faults assumption there is a support blockchain and powerful relay nodes. The solution is novel but relies heavily on support blockchain and relay nodes that drive both complexity and cost. More theoretical and exploratory work  [34]  has been put forward by Alsboui et al. The issue of offline resiliency is very briefly described with quite a narrow description of what it entails and what the solution would look like. Here no data and studies have referred to why it is a problem worth solving other than IoT attributes. They have pointed out that IOTA has the capability but have not described the underlying details of whether it will actually work or not.
IOTA Background IOTA ledger, unlike other block-based DLTs, is more suitable to the needs of IoT or cyber-physical devices such as no transaction fee, high scalability, and throughput. As shown in Figure  3 , IoT devices get access to the IOTA ledger, and the transactions (tx) sent by IoT devices are added to the growing ledger. After a certain amount of time, the transactions attain finality. Any IoT device running the IOTA node software is able to add and gossip transactions to its peers. IOTA software follows a light design to lower the resource consumption so that a wide range of IoT devices can directly run the node software and do not depend on any third-party service. Here is a brief overview of how the IOTA blockchain works. The structure of IOTA DLT is called a Tangle  [10]. Nodes in the IOTA network share Tangle and the incoming transactions are validated or added as per the consensus rules.
Coordinator In the present IOTA implementation (Available online: https://github. com/gohor net/hornet, accessed on 21 December 2021), every node comes with a hardcoded address of a special node called Coordinator. The Coordinator acts as a central entity that helps IOTA transactions to achieve finality by releasing the milestones at regular intervals. In IOTA, transactions per second (TPS) are different from confirmed transactions per second (CTPS). The former is when a node accepts the new incoming valid transaction and adds it to its Tangle and also broadcasts it to its peer nodes. But the transactions achieve finality (which is a way of making sure that the state of the ledger is then irreversible) using special transactions called milestones. At present, the IOTA foundation controls the Coordinator node and in future releases, i.
Experiments To showcase the issues discussed on IOTA scaling as mentioned in Section 5, experiments are developed to closely observe and analyze the problems using an official IOTA private Tangle implementation framework (Available online: https://github. com/iotaled ger/one-click-tangle accessed on 21 December 2021). The experiments are entirely based on the official IOTA Github repository that uses the currently operational IOTA node software (version Hornet) which is a part of the Chrysalis update  (1. 5). This section will discuss the setup specifications and the experimental observations.
Experimental Analysis We ran the use cases which allowed us to study the issues mentioned in Sections 5. 1 and 5. 1. 1. We made minor changes to the configuration of IOTA private tangle implementation to accommodate the given issue. Changes include adding another additional normal node, spammer node, and private networks to orchestrate the offline use case. The experimental runs are open (Available online: https://github. com/WiSeCom-UPF/one -click-tangle/blob/chrysalis/hornet-private-net/README_Research. md accessed on 12 January 2022) for everyone to run and observe similar results. The experimental setup is a one-click solution with the following manual adjustment to orchestrate the particular use cases under observation: • Node 1 Network Disconnect: The goal of the exercise is to observe the behavior once the public blockchain nodes are unreachable or a group of IoT nodes are isolated.
This way, every 80-s period of non-synchronization among Node 1 and Node 2, will lead to a very high chance that upon synchronization post 80-s period, the offline Tangle at Node 2 will become stale and unreachable from the new set of transactions. From the experiment runs, we observed that the old offline part of the Tangle was detached entirely from the new one. The IOTA visualizer can not update the old data if there is a significant gap between the new and old transactions. Due to this, two visualizations can be drawn from the experiment. As shown in Figure  8 , the old Tangle after the milestone (in blue) was disconnected from the Coordinator and after the time mentioned in Equation (1) when the Coordinator was again reachable then the unconfirmed transactions (in yellow) became disconnected from the new Tangle.