Computational notebooks (e.g., Jupyter [1] or Apache Zep pelin [2]) have become a popular choice for scientifi c comput ing. Notebooks support interactive development of workflows in which users get immediate feedback on executed parts of a workflow. This is useful as users can test and debug workflows as they develop. The programming style induced by notebooks is also contrary to classical workflow systems which require the entire workfl ow to be specifi ed upfront. Consequently, notebooks are being used for a variety of workfl ows for exploring data, executing models, and visualizing results. Application virtualization is a lightweight method for sharing code, data, and environment of an application that addresses 'dependency hell' scenarios. Several recent sys tems [3], [4], [5] use application virtualization as a method to audit the execution of a program, and create a container like package comprising all fi les (code, data, and environment) referenced by the program during its execution. This package repeats the application in different environments. These system tools have much to offer, especially to enable computational reproducibility [6] of scientific models and collaborative ana lytics [7], [8] shared on notebook-based platforms. However, these systems currently assume batch workfl ows, which are classicall y developed with scripts and are non-interactive.
They do not support web-based, interactive notebooks, which necessitates auditing client-server communication protocols required to enable interaction.
A straightforward approach would be to extend application virtualization to the underlying client and server modules of the notebook system. However, we observe that such an extension only enables strict reproducibility of notebooks, i.e., a user can only repeat the audited notebook but not modify it, since modification introduces new communication between the client and server that was not previously audited. This is a severe limitation for notebooks which enable interactive development and in which users can add, modify, and delete cells and change their order of execution. Thus, we need to extend application virtualization in such a way such that the resulting notebook containers can be seamlessly shared, repeated and flexibly reproduced by changing code and data in different environments. Such containers must preserve the fundamental interactive property of notebooks-to add, modify, and delete cells-so that users' interaction with the new environment is at least as powerful as the original environment.
In this paper, we describe how to systematically extend application virtualization to notebook-based platforms by preserving the connection information and redirecting it as needed. To extend, FLINC creates compatible kernels for a notebook fi le, ensuring that the fi le is correctly audited in the host environment and reproduced in the target environment.
During audit phase, FLINC creates a lightweight notebook container which includes all the dependency fi les that are necessary to reproduce the notebook file. During repeat phase, FLINC transparently uses the lightweight notebook container for a notebook fi le in the target environment. To ensure repeatable execution, FLINC uses the audited provenance to determine if the notebook file has changed since being audited.
If it has not changed, the container is used; otherwise the redirection ceases and regular execution resumes. FLINC also uses the provenance audited during application virtualization to export the contents of the container to other container like virtual environments. The export mechanism is particu larly needed to enable reproducibility of notebooks on non notebook platforms.
The current implementation of FLINC is for JupyterHub which is the most popular notebook platform. However, the design of FLINC is general; FLINC only relies on two prop erties which are generic across all notebook platforms, namely interactive computation and a client-server architecture [9]. We have used FLINC with HydroShare [10], a cyber infras tructure for sharing geoscience data and models. To support notebook-based analysis, HydroShare supports multiple com putational environments, such as CUAHSI JupyterHub [11] 2 and CyberGIS-Jupyter for Water (CJW) [12]. These environ ments have their own hardware configuration and maintain a unique set of software dependencies to support analysis tasks of their user base. HydroShare allows users to interactively run notebooks within each environment. However, users often de velop workfl ows that must be executed across environments to couple with other workfl ows or to simply take advantage of improved hardware or software in the other environment.
Currently, users can create and reproduce notebooks success fully as long as they remain in the same environment. With FLINC, a user can easily document dependencies for a non notebook environment or transfer packages to be executed in a notebook environment.
The rest of the paper is organized as follows: section II describes types of reproducibility issues that users face when sharing notebooks. In section III, we describe the current model of notebook execution and sharing. Section IV describes the FLINC system, how it extends application virtualization to notebook platforms, and how it ensures reproducible execution in heterogeneous environments. In section IV-D we describe how provenance logs are used to ensure reproducible execution and provide fl exible reproducibility. We describe the implementation and performance of FLINC in section V, discuss its generality to other platforms and packaging solu tions in section VI, highlight the related work in section VII, and conclude in section VIII with an overview and future directions.
We describe the reproducibility issues that arise when sharing notebooks. Such issues come up regularly in cyber infrastructure that enable notebook-based interactive analytics for its users.
Consider three scientists, Alice, Bob, and Charlie, who are collaboratively engaged in analyzing maximum daily stream fl ow as a function of maximum snow water equivalent. Alice, the primary scientist, has developed a notebook that: (i) downloads data for a region of interest, (ii) preprocesses it, (iii) uses climate data to run a simulation model; (iv) compares simulated streamfl ow data with the simulated snow water data, and, finally (v) plots and visualizes the fi t function. Figure 1 shows the steps divided into cells with some sample code.
Alice develops her notebook in Python and C; it uses Python packages to perform preprocessing and visualization (steps (i), (iv) and (v)) and C and Fortran 2 binaries to run simulation model and perform the comparison (steps (ii) and (iii)). Some of these are standard packages such as Numpy and Matplotlib, but it also includes special simulation model packages such as PySumma, ArcGIS, GeoPandas, Rasterio, PyRhessys, etc. which are specific to the field of hydrology.
The C packages are executed by invoking the shell with a '!' from the notebook, as shown in cells 1 and 3.
To collaborate, Alice has successfull y repeated her notebook execution several times to ensure it produces the same/similar results. Now, Alice wants to share her notebook with Bob and Charlie, who also aim to repeat her workfl ow. The following scenarios illustrate the reproducibility-related issues that arise at their ends: The reproducibility challenge in the fi rst case arises because the environment is not transported with the notebook fi le. In the second case, the environment is shared, but it is not fl exible to be extended to include new simulation models and data that are available outside the environment. A solution that accounts for these two use cases must also account for the more general, 'different interface, different environment' use case.
We describe the current model of interactive computing within notebook platforms and sharing notebooks.
Notebook platforms operate in a client-server architecture, as shown in Figure 2. Users edit notebook fi les and execute in a read-eval-print-loop (REPL)-style via a web browser. In REPL-style, an interactive process reads cell-worth of code and executes it. The next read-evaluate (akin to a loop), which is specifi ed in the next cell, proceeds from the computational state of the previous evaluation. Notebook fi les assign each cell evaluation with a sequence number. The notebook file preserves this sequence, and it shows a safe order for cell re-execution, thus obtaining the same result at a later time.
On notebook platforms, the server (remote or local) main tains the kernel, a programming language-specifi c interactive process that runs independently and maintains the state of the notebook fi le computations as it progresses. For example, Jupyter notebook platform supports the !Python kernel for Python programs, Xeus Cling for C++ programs [13] and Xeus-sql for SQL-based programs [14].
Since the kernel maintains the state of the notebook com putation, it is also aware of the computational environment and any dependencies in the environment under which the computation runs. For example, if the !Python kernel of a Jupyter platform contains Apache Spark in its environment, then possible notebooks that will necessarily compute and execute are notebooks that include the Spark library and use the specifi c version of Python interpreter used in the !Python kernel. If the notebook specifi ed in Figure 1 is executed within this platform, it will report dependencies such as GeoPandas and Rasterio, as missing. Typically, for executing a variety of notebooks, the kernel is confi gured to run in a container or a virtual environment (such as Anaconda) that is aware of the dependencies and software packages required to support the notebooks.
Since notebook fi les do not transport environments, users adopt certain practices to make notebooks repeatable across heterogeneous environments. One practice is to only use Python dependencies in a notebook. With this restriction, users can install Python dependencies in their user space of the target environment. For example, in the notebook in Figure 1, the user is allowed to install 'rasterio' in cell 1 within the user space. The kernel recognizes this instruction and will therefore successfully execute it. An alternate practice is to create Docker containers and share the notebook fi le as part of a container image.
Neither of the practices generalize to all kinds of notebooks or fundamentally resolve the reproducibility issue. As the ex ample illustrates in cell3, scientific computing notebooks often combine Python with C, Fortran, and shell utilities to concep tualize a workflow and its steps. For non-Python languages, installing dependencies in user space is often not sufficient as the install requirements vary per computing platform. Custom libraries are generally not available through standard package managers, and often do not properly follow offi cial packaging guidelines. Further, installin g all the required dependencies with their correct versions is a manual and labor-intensive task. The key idea in application virtualization is to use the Linux system utility strace to monitor the processes associated with an executing program and record its interactions with the operating system for resources. strace internall y relies on the ptrace system call to attach itself to the executing program, which intercepts system call s to the operating system for resources such as access to fi les and spawning of processes.
The accessed resources are copied and virtualized into a container-like package [3].
AV can also be used to audit an interactive program or audit client-server programs that include network connections, since network connections also take place via system call s.
Unlike previous work [15], [16], we do not need to audit both the client and the server in notebook platforms, since the kernel performs all the computation. The client program is the notebook fi le which is already shareable. Therefore, in FLINC, we extend AV to the server-side kernel only.
In extending AV to the kernel, we distinguish between two primary, but independent, features of a notebook platform: The audit kernel is a clone of the default kernel except the interactive programming language-specifi c process spawned by the default kernel is now observed using strace and any access for a file resource is encapsulated in a package.
By observing this language-specifi c process which executes code from the notebook fi le, and is therefore aware of the environment variables and any datasets or binaries accessed by the notebook fi le, the audit kernel is able to encapsulate all the necessary and sufficient dependencies.
The audit kernel creates a notebook container which con tains all the dependencies that a notebook fi le accesses. A crucial part of this container is the connection information used by the notebook to connect to the kernel process. However, an important dependency missing from it is the notebook fi le itself. This dependency is missing because the audit kernel -owing to client-server architecture -is unaware of the notebook fi le and only executes the code that is communicated via socket messages. While in our current implementation, the user can use FLINC to add the notebook fi le to the container post execution, notebook fi les can continue to be shared outside the container as they are routinely shared. The absence of the notebook fi le in the container, however, creates issues when repeating since fi les may change externally. We address such issues in Section IV-B.
To repeat the notebook fi le in a new target environment, it must execute using the dependencies from the notebook container. In general, the notebook fi le by default will attempt to make a connection to the kernel process resident in the target environment. To reroute this connection to the notebook container, the repeat kernel substitutes the old connection information in the container with the new connection informa tion. The connection information is an environment variable that is typically read by application virtualization methods before creating a container. This substitution is achieved dynamically to support interactive development. The substitution method is also used to support any changes to dependencies such as data fi les or newer versions of a library and accessed by notebook fi les. Note that such changes are not the same as changing the notebook fi le, which we describe in Section IV-B.
A notebook platform that hosts different kinds of kernels for interactive development can use FLINC to create corre sponding audit kernels for each hosted kernel. Thus, if the notebook platform hosts two kernels, then FLINC can create two audit kernels. The platform, however, only needs to create only one repeat kernel, which is specifi c to the location where the notebook containers are stored.
In FLINC, the audit kernel creates the notebook container which includes all dependencies used by the notebook fi le, except the notebook fi le itself. This absence of notebook fi le in the container creates two issues when using the container to repeat the notebook fi le: First, it is not possible to map the container contents to the specifi c version of a notebook fi le which was initially used to generate the container. Con sequently, given a notebook fi le, the container may execute, but it is not possible to guarantee that execution is the same as during audit or repeat. Second, the outputs of the container are included in the notebook fi le and not the container. These outputs are often necessary to compare reproducible execution. We illustrate these issues through a use case.
Consider the notebook fi le N1 of Figure 1, which Al ice intends to share with Bob. For this, Alice has con tainerized N1 using the audit kernel, which now contains all the referenced fi les such as python3.8, pytorch.py, re sent18.model, weather2016-2018.dat, and other confi guration fi les. She shares with Bob the container and the notebook fi le N1. Bob is able to successfully repeat N1 and then creates another version of the fi le N2 by modifying N1 's threshold parameter and by adding a data transformation step to the training dataset, as shown in Figure 4. N2 executes without any failures but a different threshold value modifies the generated output fi le, and the addition of data transformation steps change the internal system call sequence. Since the result of N2 is similar to that of N1, the user might think that the notebook reproduced correctly. However, there is no valid means to compare the result produced from the previous execution as outputs are sent via messages. Consequently, the container does not map its contents to the specifi c version of a notebook fi le, which was initially used to generate that container.
We solve this issue by auditing per cell provenance of the application during creation of the container. The per cell provenance is generated by diff erentiating between the contents of the notebook fi le and its execution, and maintaining a map between the cell code and its provenance generated during execution.
Let N be a notebook fi le consisting of cells N = [ c1, c2, ... , en], where ci represents the i th execution of the cell. The state ps0 which is just before the first cell is executed, includes the value of the connection fi le and any initial input.
The audit kernel receives the code for cell Ci and after its execution, it maintains the following details about each program state psi:
• code hash, hi , computed by hashing the code in cell i, and
• state lineage, gi, which is determined by combining three features: (i) the predecessor cell's lineage, (ii) the sequence of system events Ei that are triggered by program instruc tions in the cell i and finally (iii ) the hashes hi of the associ ated external data dependencies. Thus, 9i = {9it. Ei , hi }, where Ei is the ordered set of system call events in the cell and hi is the hash of the content accessed by the event Ei. Initially, go = { } .
We emphasize that the execution of the program code in cell i (and the code in previous cells) resulted in psi. Therefore, psi at the end of a cell's execution depends on its (i) initial environment, (ii) code that is run, and (iii ) external input data.
The environment is determined by the execution state at the start of the cell. Thus, (i) and (ii) are captured via 9i-l and Ei. Further, every external input data fi le is accessed via a system call event. For each such event, we record a hash of the file's content in h i 3 • establish reproducible execution, FLINC stores the de tails about a notebook file in the container during audit time.
During repeat, it establishes equality between states after the execution of the cell, i.e., it determines if the cells are (i) equal with respect to their code, and (ii) have identical state lineage Yi (note that state lineage of i th cell depends on state lineage of previous cell). We state this formall y as: Definition 1 (State equality). Given two program versions L1 and L2, state psi in L1 is equal to state psi in L2, denoted psi =psi, if and only if (i) h i = h j, (ii) Yi = Yi• Program states do not remain equal when cell code is edited, which changes the hash value of that cell and any subsequent cell state. Equating state lineage depends on the system events audited during the creation of the container. Since in FLINC, system events are audited at the level of system calls, there are some pre-processing steps that are necessary to establish equality, such as accounting for partial orders, abstracting real process identifiers. We describe these issues in Section IV-D.
So far we have considered notebook containers that are created and repeated within the interactive client-server archi tecture of the notebook platform. In our motivating use case, such notebook containers improve sharing and reproducibility for users such as Bob who also use notebook platforms that are hosted in a different environment. We now consider how notebook containers can help users such as Charlie, with whom Alice would also like to share the notebook container but such users are neither operating on a notebook platform nor are they familiar with the REPL-style notebook programming.
FLINC extends application virtualization to export the contents of a notebook container to non-notebook isolated en vironments. By exporting, FLINC creates a new environment for the user, similar to the notebook container, but into which users can add or remove files or change existing notebook files. Figure 3 shows the exp ort action in FLINC.
The export is based on a log of all files, collected as part of the auditing phase. For correctness, FLINC does not copy the files in the log, but collects the lineage of all cells and uses the specification of the external input data to determine the soft ware packages that must be installed in the new environment.
Typically, each external input data file is accessed via a system call event. Since access is based on file paths, the system event also knows the path of the external input data file in the source environment. Export maps each file to its software library package by using the path specification as software package files are generally only accessible from within the software package. Thus, for example, if the lineage of a cell specifi es accessing the external input file libcrypto . so .1. 1, then the software library to install is libssl as this software library is mentioned in the file path to libcrypto . so . 1 .1.
Once export determines the appropriate software packages and libraries used by the notebook application, it determines 3 Such hashes are typically obtained while copying content in the container.
the version for each of them. Due to the presence of vari ous packaging standards and the lack of strict enforcement of packaging guidelines, identifying the correct version of an install ed package is chall enging and depends on some programming language-specific rules. Identifying the specific version of a software package is also not a guarantee that a package manager will always install the specific version of the package, which is a function of naming convention and organization adopted by the package manager. For example in Python, two popular packaging conventions are wheels and eggs which respectively use the dist-info and egg-info formats for storing the package metadata. If either of these fi les/directories are present for a package, we explore the package directory to find the version of that package. The *-info files or directories contain a METADATA folder which contains the version information. However, it is not required to have that folder and we found several packages which did not contain the folder. We then search for a file named version.py or a similar name in the installed package directory and scan that file to find the version of the package. Nevertheless, for prominent programming languages such as C, C++, R, and Fortran, FLINC follows standard conventions as a best effort to find version numbers, though the conventions do not guarantee identification.
After determining the packages, FLINC instantiates new virtual environments. In particular, FLINC maintains a sep arate directory where software packages are copied and in stalled. For example, in Python this will be a virtualenv and in C/C++, these packages are installed in a user-configured location such as tmp or usr.
Application virtualization captures the execution of a pro gram using the ptrace system call which captures the details of each instruction executed by the program using operating system primitives. In FLINC these events are captured on a per cell basis in a provenance log. Each line in the log file corresponds to a system event that took place as a result of an instruction executed within that cell, and contains the instruction timestamp, process identifi er, instruction type, and the operands of that instruction. This log represents the lineage of the interactive kernel process modeled as an activity.
In export, we process the inferred provenance to determine (i) files that are inputs to activities, (ii) fi les that are read by activities, and (iii) fi les that are outputs. Within this classifi ca tion, we determine files that are in user directories versus files that are in system directories. This is necessary as system files that are read by activities determine which packages to install.
We note that the log is noisy in that it also contains information about temporary fi les, outputs, and process memory execution.
We filter such fi les as this is execution-specific information and not relevant for determining which packages to install.
For reproducible execution, we must establish state equality per Definition 1. Lineage equality implies that at end of cell i of version N1, Yi is the same as that at end of cell i TA BLE 1: Characteristics of the fi ve notebooks in the dataset used in our experiments.
of version N2• This is true if and only if the sequence of system call events (and their parameters)-till i in N1 and i in N2-exactly match. But if a cell, e.g., forks a child process, which itself issues system calls, then each version's sequence will contain the parent calls and the child process calls interleaved in possibly different orders. To address this problem, we initially separate the events of all cells into PID specifi c sequences and then compare corresponding sequence to generate the provenance. Note all time and process spe cific information is abstracted. Memory accesses cannot be abstracted and we just count the number of accesses in a cell.
V. EXPERIMENTS FLINC relies on application virtualization to create note book containers. We reused application virtualization as avail able with Sciunit [17], [4], and modifi ed it to support transpar ent connection of repeat kernel with the container. The audit and repeat kernels are wrappers over the Sciunit Python API, and FLINC adds per cell information to the resulting logs obtained via execution.
To conduct our experiments, we used HydroShare [10] which is an open source platform used by geoscientists for collaborative and reproducible research. HydroShare provides tools for managing and publishing models and data by lever aging interactive development and access to cloud services. It supports multiple computational platforms where users can de velop and share their scientifi c models. Two of these platforms are CyberGIS Jupyter for Water (CJW) [12] and CUAHSI They provide users with basic hardware and software setup to support dependency management and isolation through the use of one or more kernels. Users can use the pre-existing kernels or create their own kernel in their user space. We run our experiments on these two platforms using notebooks which use Python, C, and Fortran dependencies. The experiments were run on a Docker instance with memory size of 30GB and disk size of 64GB, and running Ubuntu 20.04 on a 64 bit machine with 8 CPU cores.
Our dataset of experiments consists of fi ve notebooks. They are written in Python and C language and also invoke utilities via shell commands. Each notebook corresponds to a different use case; two from the fi eld of hydrology and three from data science. The hydrology notebooks perform water flow analysis using data from different sources with the help of standard hydrological models. In the data science notebooks, -------�------------, ., " two notebooks use machine learning algorithms to analyze and predict market behavior and the third notebook performs image classifi cation using neural networks. We describe the important characteristics of our notebooks in Table I.
We perform two different experiments with FLINC using our dataset. First, we study the overhead incurred during note book execution due to application virtualization. We analyze the execution time and storage size in both the audit and repeat modes of notebook execution using the audit and repeat kernel respectively. We term this the Interactive-AV method. We compare the performance of the FLINC method against two other methods. The fi rst method is executing a Python fi le that corresponds to the notebook, but one that uses the application virtualization in batch mode. We term this method Batch-AV. Comparison with this method will help us learn the overheads, if any, due to interactive computation. The second method is the base performance of the notebook using the original kernels (i.e, without application virtualization). We term this method No-AV method.
Figure 5 shows the execution time and the corresponding storage footprint generated by the three methods for each notebook. Figure 5a shows that the execution time using In summary, executing and repeating a notebook using FLINC adds little overhead in terms of execution time com pared to running the notebook itself, and uses less time compared to running the notebook with Batch-AV method.
Compared to Docker containers, FLINC takes almost half the time to create a new virtual environment and about the the fundamental concepts of FLINC can be applied to other storage fo otprint to store the virtual environment. operating systems as well.
We discuss the generality of FLINC while encapsulating and sharing dependencies. FLINC is an open-source sys tem [18]. Currently, we do not fo cus on the medium of containerization or the fo rmat of the resulting container, which is beyond the scope of this paper. The objective in FLINC is to automatically determine the dependencies and provide a sandbox instead of manually creating a package and then sandboxing it. If the container is a package then one of the emerging fo rmat such as Flatpak [19] or NEXTSTEP/MacOS bundles [20] can be used. If the container has namespace isolation, then Docker or Singularity images can be used.
FLINC currently depends on ptrace, a process tracing utility that is only available on Linux platforms. While this restricts FLINC to Linux, the fun damental concepts in FLINC can also be extended to other operating systems through the use of event tracing systems specifi c to them. For example, as shown previously [21] the Process Mon itor (procmon) application on Microsoft Windows and Mac OS X kernel's auditing of system calls with OpenBSM reporter collects the same fi delity of provenance and content details as ptrace on Linux. Thus 9 VII. RELAT ED W ORK Notebooks are increasingly becoming part of cyberinfras tructure fo r scientifi c computing [22], [10]. Policies and standards with respect to reproducible notebooks [23] are also emerging. Several current efforts aim to determine the most appropriate notebook platform fo r scientifi c computing and data exploration. [9] provides an excellent survey of about 60 different notebook platforms. They state REPL style interactive computation and client-server architecture as two distinctive properties of notebook platforms. We have developed FLINC keeping these two properties as invariant.
There are several notebook extensions that improve the reproducibility of notebooks during interactive development. Nodebook [24] is a plugin fo r Jupyter that checkpoints note book state in between cells to fo rce in-order cell evaluation; Datafl ow notebooks [25] extend Jupyter with immutable identifi ers fo r cells and the capability to reference the results of a cell by its identifi er. Both of these are specialized notebook clients that aim to impose a strict order of notebook execution and capture their provenance. This order is important during repeated interactive development. Use of FLINC is post interactive development fo r collaborative analytics.
The issue of reproducing notebooks in different environ ments was already recognized by [9]. [26] addresses this problem by context-aware migration of a notebook cell fo r execution on another platform. This is achieved through a JupyterLab extension which analyzes the execution of each cell and uses a hand-crafted knowledge base to decide the environment in which to perform computation. FLINC fo cuses on the reproducibility of the entire notebook with minimal user intervention.
Several methods describe the process and specifi cations to capture programs executions and convert them into self contained environments. They include methods such as PRUNE [27] and TOSCA [28] which require users to explic itly defi ne all the code, data, and dependencies with their sys tem and users often need to learn new standards and languages to use them. In our work, we use application virtualization which is a generic approach to build container-like packages without modifying applications, and predominantly uses the ptrace system call to automatically create a container-like package [3], [29]. Some prominent tools that use AV are Sciunit [4], [30], Reprozip [31], and Care [32].As this paper shows, AV must be extended to apply to notebook platforms. Further as we show in this paper, fo r notebooks, the redirection model must also be extended when repeating within notebook platforms due to the client-server architecture. The export method is similar to the copying of dependencies used in [33], [34], but we make it further fl exible by bypassing calls to fi les that are not within the container.
Notebooks are increasingly becoming popular in scien tific computing, and adopted for analysis, modeling, and visualization tasks. Reproducing notebooks is critical as target environment continues to evolve, especially in collaborative analytics. In this paper, we have highlighted that notebook fi les do not transport their underlying environments despite being easy to share. To address this limitation, we have presented FLINC a system that supports interactive and fl exible reproducibility of notebooks. FLINC adapts and extends application virtualization (AV), an already popular method for addressing computational reproducibility, to note books. FLINC monitors notebook execution and captures them to create isolated notebook containers. It extends AV to accept new network connections from a notebook file and redirect them to the notebook container. We show how FLINC guarantees reproducibility despite new connections in target environments, and also exports notebook containers. Exper iments show that FLINC provides efficient reproducibility of notebooks and takes signifi cantly less time and space to execute and repeat notebook as compared to Docker containers for the same notebooks. In the future we plan to generalize FLINC to multiple OSes and make FLINC available for high performance computing workflows.
For efficiency, scientists often develop simulation models in C and Fortran.Authorized licensed use limited to: DePaul University. Downloaded on May
30,2023 at 13:45:44 UTC from IEEE Xplore. Restrictions apply.
Authorized licensed use limited to: DePaul University. Downloaded on May 30,2023 at 13:45:44 UTC from IEEE Xplore. Restrictions apply.