# An Alternative to Cells for Selective Execution
of Data Science Pipelines

Lars Reimann  Institute of Computer Science III
University of Bonn, Germany
Email<EMAIL_ADDRESS>Günter Kniesel-Wünsche  Institute of Computer
Science III
University of Bonn, Germany
Email<EMAIL_ADDRESS>
###### Abstract

Data Scientists often use notebooks to develop Data Science (DS) pipelines,
particularly since they allow to selectively execute parts of the pipeline.
However, notebooks for DS have many well-known flaws. We focus on the
following ones in this paper: (1) Notebooks can become littered with code
cells that are not part of the main DS pipeline but exist solely to make
decisions (e.g. listing the columns of a tabular dataset). (2) While users are
allowed to execute cells in any order, not every ordering is correct, because
a cell can depend on declarations from other cells. (3) After making changes
to a cell, this cell and all cells that depend on changed declarations must be
rerun. (4) Changes to external values necessitate partial re-execution of the
notebook. (5) Since cells are the smallest unit of execution, code that is
unaffected by changes, can inadvertently be re-executed.

To solve these issues, we propose to replace cells as the basis for the
selective execution of DS pipelines. Instead, we suggest populating a context-
menu for variables with actions fitting their type (like listing columns if
the variable is a tabular dataset). These actions are executed based on a
data-flow analysis to ensure dependencies between variables are respected and
results are updated properly after changes. Our solution separates pipeline
code from decision making code and automates dependency management, thus
reducing clutter and the risk of making errors.

###### Index Terms:

Notebook, Usability, Data Science, Machine Learning

††publicationid: pubid:
Accepted at the 45th Int. Conf on Software Engineering, NIER Track
ICSE-NIER’23, May 14–20, 2023, Melbourne, Australia
©2023 IEEE

##  I Introduction

Notebooks allow users to write code in cells that can be executed
independently, in any order. Execution results, such as visualizations, are
commonly shown close to the code cells that produced them. Code cells can be
interspersed with text cells, to offer explanations or document decisions,
which follows the paradigm of literate programming [1]. Overall, this makes
notebooks well suited for the explorative development process of Data Science
(DS) pipelines [2]. Here, developers often write small pieces of code, run
them, and use the results to change existing code or decide what to implement
next.

Various flavors of notebooks exist, with Jupyter Notebook [3] being most
popular according to the 2021 Kaggle Survey on DS [4]. Jupyter Notebook
requires language-specific kernels to execute code and to power IDE features
like auto-completion, but is otherwise language-agnostic. Since Jupyter
Notebook is a web application, it can run locally or be hosted as a service,
like Google Colaboratory [5], Kaggle [6], or Amazon SageMaker [7]. Some
integrated development environments (IDEs) like PyCharm [8] or Visual Studio
Code [9] incorporate Jupyter Notebook. JupyterLab [10] is eventually meant to
replace the default Jupyter Notebook GUI. The issues we discuss in this paper
are independent from a specific notebook variant, however, since they stem
from the core concept of notebooks: Cells.

Fig. 1 shows an example of the typical cell structure of a notebook for
DS111Based on a popular notebook from Kaggle
(https://www.kaggle.com/code/startupsci/titanic-data-science-solutions). using
Python as the programming language. Text cells (blue) and code cells (white)
alternate. The code cells (1) read a CSV file containing the training data,
(2) view the dataset to gain a general understanding and to know which
attributes it has, (3) separate feature vector and target, (4) configure a
model (support vector machine for classification), and train it222The fit
method in this example is supposed to return a new trained model rather than
mutate the untrained model stored in svc.. For the sake of brevity, we omit
result cells.

Figure 1: Example for a typical cell structure of a DS notebook with text
cells (blue) and code cells (white). Result cells are omitted.

Based on Fig. 1 we can illustrate the problems we want to discuss in this
paper:

  1. 1.

Actual pipeline code (Cells 1, 3, 4) is mixed with value inspection code (Cell
2). The value inspection code exists solely to write more pipeline code (here
Cell 3, which needs the name of the target column). Keeping value inspection
cells in the notebook afterwards increases clutter [11, 12] and negatively
impacts performance, since they might get re-executed unnecessarily.

  2. 2.

Users can execute cells in any order. This manipulates the internal state of
the notebook (e.g. contained variables and their assigned values), which is
maintained throughout the entire session. However, not all orderings are
correct [13, 11, 14, 15, 16, 17, 18]: For example, executing Cell 3 first on a
blank state is erroneous, since this cell depends on train_df, which is
computed in Cell 1.

  3. 3.

Code changes partially invalidate the internal notebook state and results
cells [13, 11, 14, 15, 16, 17, 18]. Say, after executing the entire notebook
from Fig. 1, we add more data preparation steps to Cell 3, before assigning
X_train and y_train. Now, the values of X_train and y_train in the internal
notebook state are outdated, so Cell 3 must be rerun. However, trained_svc,
which depends on these values, is also outdated, so Cell 4 must be rerun, too.
In large notebooks, keeping track of all cells that must be rerun gets
complicated, leading to developers frequently rerunning the entire notebook to
be safe [16], wasting computing and development time.

  4. 4.

Even without code changes, notebook state can become stale: For example, the
dataset we read from disk in Cell 1 might change. Like in Problem 3, the
notebook needs to be partially re-executed to account for such an event.

  5. 5.

Since cells are the smallest unit of execution, even code that is unaffected
by changes is re-executed. In the example from Problem 3, we rerun Cell 4
completely, although the value of svc is still valid. Calling the SVC
constructor is fast, but for the same reason long-running data preparation or
model training operations might be rerun unnecessarily, drastically slowing
the feedback loop. This leads to an “expand then reduce” pattern [11], where
developers first write small code cells, which can be executed independently,
to iterate quickly and later combine them into bigger cells. This defeats the
purpose of cells as a means to group logically related code together.

##  II State of the Art

A natural solution to ensure code gets executed in the correct order (Problem
2) and gets re-executed after changes (Problem 3) is to derive dependencies
between cells using data-flow analysis and run a cell only after all cells it
depends on: Dataflow notebooks [19] assign a unique identifier to cells, which
stays the same even as the code in the cell changes. These IDs are used to
describe the dependencies between cells. When a cell gets executed, the system
ensures that all upstream dependencies are available already. Nodebook [20]
keeps track of inputs and outputs of cells. Inputs are determined by parsing
the code in the cell, while outputs are discovered by comparing the internal
state of the notebook after the cell was run to the state before. [14]
describes how data-flow analysis can be used to create a polished version of a
notebook that only contains the code needed to produce the results that the
user selected. NBSAFETY [17] uses data-flow analysis to detect unsafe
interactions with the cells in a notebook and offer resolution advisories. To
achieve this, NBSAFETY uses a mix of dynamic and static analysis. ReSplit [21]
analyzes definition-usage chains between cells and within the same cell and
then suggests an alternative mapping of code to cells to ensure that tightly
coupled code resides in the same cell.

However, none of the existing approaches solve Problems 1, 4, and 5: They do
not handle changes to values outside the notebook (Problem 4), use complete
cells as the smallest unit of execution thus failing to avoid re-execution of
parts unaffected by changes (Problem 5), and do not even try to address the
tangling of pipeline and value inspection code (Problem 1).

##  III Research Questions

This brings us to the following research questions:

  * •

RQ 1: How can we separate pipeline code and value inspection code?

  * •

RQ 2: How can we ensure changes to external values trigger re-execution of
code that depends on them?

  * •

RQ 3: How can we avoid unnecessarily executing code?

RQ 1 aims to reduce clutter, RQ 2 is about correctness and RQ 3 addresses
performance.

##  IV Approach Overview

To solve these issues, we propose to keep cells only as a means to connect
code to related results and instructional or documenting text, but abandon
them as the basis for the selective execution of DS pipelines. Instead, we
suggest to

  1. 1.

address RQ 1 by introducing different roles for code cells (Sec. V), or by
statically typing variables and letting the development environment
dynamically populate a context-menu for variables with actions that can be run
on a variable of the respective type (Sec. VI),

  2. 2.

address RQ 2 and RQ 3 by using static code analysis to derive a correct and
minimal _execution plan_ for a selected action (Sec. VII).

An execution plan is correct, if it contains all operations that must be
executed and guarantees that each operation is executed only when all its
input values are up-to-date, including external values (RQ 2). It is minimal
(RQ 3), if it contains no operations that would only affect already up-to-date
values or would compute values that are not accessed by other operations in
the graph.

##  V Tags for Code Cells

For teaching materials [22] or documentation, keeping value inspection cells
in the notebook can be helpful, to outline each step of the development
process of a DS pipeline, including decision-making [11]. However, value
inspection code is then scattered across the entire notebook, creating
clutter, and re-executed each time the notebook is run, wasting time.

To separate pipeline code and value inspection code (RQ 1) in this case, we
suggest to tag code cells by their purpose, as “pipeline” or “inspection”.
Fig. 2 shows this for the start of the notebook from Fig. 1 with pipeline
cells (white) and inspection cells (yellow). With a filter, a user can then
narrow down the cells and show, say, just the pipeline cells. Only cells that
are currently shown are executed. Text cells can be tagged and filtered in the
same way.

Figure 2: Distinguishing pipeline code cells (white), and value inspection
code cells (yellow) at the start of the notebook from Fig. 1.

##  VI Context-Sensitive Inspection of Values

Outside of educational notebooks, value inspections cells are often executed
only once, to decide what to do next. For example, after running Cell 2 in
Fig. 1 we know that the target attribute is called “Survived” and can use this
knowledge to write Cell 3. Leaving Cell 2 in the notebook has little
documentation value, since we already manifested the extracted information in
Cell 3.

In contexts where inspection cells have no documentation effect, we suggest to
avoid writing them in the first place, by additionally offering inspection
actions in a context-menu for variables (Fig. 3). This way, notebooks can only
contain pipeline code if desired, completely eliminating the tangling with
inspection code (RQ 1).

To know which actions can be triggered on a variable, we need to know its
type. Ideally, the type should be known statically, so we do not need to run
code to determine which actions can be triggered on a variable. Moreover, the
type should be inferred, so users can concentrate on writing their pipeline
code as they are used to.

When a user selects an action, code that implements the action is executed in
the background (see Sec. VII for details). Results of value inspection actions
can be closed after inspection or kept outside the main flow of the notebook
entirely in separate tabs, windows, or Sticky Cells [23] that float on top of
the notebook and maintain their position even when the notebook is scrolled.
Fig. 4 shows a mockup of the potential output for the “Show dataset” action
from Fig. 3. The data is displayed in an interactive table that the user can
filter (funnel icon) or sort (arrow icons). Additional actions can be
triggered directly from this view, without the need to go back to the context
menu, e.g. for generating a histogram of a column (chart icons).

##  VII Minimal Execution

### Data-flow

As described in Sec. VI, we want to trigger context-sensitive actions on
_variables_ without executing unnecessary code (RQ 3). For example, if the
user selects the “Show dataset” action on the variable X_train from Fig. 1, it
is a waste of time to execute the entire Cell 3, since the value of y_train is
never used. This requires a fine-grained data-flow graph that focuses on
individual operations rather than cells. Fig. 5 shows the data-flow graph for
the example notebook from Fig. 1. From this graph we can derive that we only
need to evaluate the calls of read_csv and drop to compute X_train, leading to
the simple execution plan in Fig. 6

Figure 3:  Replacing value inspection cells by type-specific inspection
actions in the context-menu of variables.  Figure 4: Mockup for the
interactive output of the “Show dataset” action. Users can filter the table
(funnel icon), sort it by a column (arrow icons), generate histograms (chart
icons), or trigger other inspection and analysis actions from this view
without having to write any code. Figure 5: Data-flow graph for pipeline code
from Fig. 1. Rounded boxes represent operations and edges represent data-flow.
Each edge is labelled by the name of the variable through which the respective
data flows. Figure 6: Execution plan to view the X_train dataset. The numbers
in the boxes indicate the implicit order of the operations.

### Purity

We can derive an execution plan for the entire notebook up to the fit call,
based on the data-flow graph from Fig. 5. The graph tells us that we need to
run the entire notebook, since fit depends on all other operations. However,
we can further optimize, if we know which operations are pure. A pure
operations has no side effects and its outputs only depend on its parameters
captured in the data-flow graph. Impure operations may read or modify external
state (files), or global state (global variables or object attributes). Any
pure operation can be executed _in parallel_ to any other _independent_
operation (that is, an operation on a different path of the dataflow graph).
In contrast, independent impure operations must be executed according to their
textual order. For this, additional edges that reflect the textual order are
added between independent impure operations, yielding the complete execution
plan. In our example, all operations are pure, except read_csv, which reads a
file from disk and is impure because the file contents might change although
the value of the read operation’s path parameter stays the same. Adding purity
information (green background) and impurity information (red background) leads
to the extended data-flow graph shown in Fig. 7. From it we can deduce that
the calls to read_csv and SVC can be run in parallel, as well as the calls to
drop and keep. If the calls to drop and keep where impure and the call to drop
occurred textually before the one to keep, an additional edge would point in
Fig. 7 from drop to keep.

Figure 7: Extended data-flow graph for initial run of the notebook. Numbers
indicate sequential execution, letters indicate potential parallelism.

### Execution

The extended dataflow graph serves as an execution plan for computing the
value of some variable x, when the user triggers an action (Sec. VI) on x:

  1. 1.

Build the dataflow graph.

  2. 2.

Extend it by purity information for operations.

  3. 3.

Extend it by textual order edges between independent impure operations.

  4. 4.

Eliminate operations that have no path to x.

  5. 5.

Start executing (in any order or in parallel) nodes that have no incoming
edges. After execution, delete the respective node and its outgoing edges.

  6. 6.

Repeat from Step 5, until the graph is empty, at which point the value of x is
available.

The first two steps ensure correctness. The first ensures that data
dependencies are respected. The second preserves the order of impure
operations. The third step removes all operations that have no effect on the
value we want to compute, a first contribution towards minimality (RQ 3).

### Re-Execution

Let us now assume the initial execution plan from Fig. 7 has been run, so the
internal notebook state contains the current values of all variables. Let us
further assume that the user has subsequently edited the call of the drop
operation, to remove additional attributes from the feature vector after
inspecting X_train. Now, if the user requests the system to update the state
of the notebook, we want to ensure that all code that is affected by the
change gets rerun, without re-executing code unnecessarily (RQ 3). As with any
rerun, we also need to take into account potential changes to external state,
which can affect impure operations (RQ 2).

Figure 8: Re-execution plan with question marks indicating potentially stale
values and red numbered labels indicating re-execution order of operations.

Fig. 8 illustrates the affected part of the notebook, after editing the drop
call. The changed operation is marked by a red border. Potentially stale
variables are indicated by yellow question marks:

  * •

X_train, the output of the edited drop call,

  * •

train_df, the output of the impure operation read_csv – because the data-flow
graph does not show the hidden dependencies of impure operations, we must
always assume that something might have changed,

  * •

y_train, the output of the call to keep that depends on the potentially stale
value train_df.

All potentially stale values are indicated by a question mark in Fig. 8. The
call to SVC is unaffected by the change and its output is still up-to-date.
Therefore they are not included in the re-execution plan.

The red labels in Fig. 8 reflect the assumption that we must always rerun
edited operations, impure operations, and pure operations with at least one
potentially stale argument. Potentially stale arguments must be recomputed
before they are used, which leads to the shown ordering.

A possibly more efficient approach is illustrated in Fig. 9. The yellow
question marks on the calls to keep and fit indicate that these operations do
not necessarily need re-execution, if recomputing their _potentially_ stale
arguments produces the same values as before. For this non-staleness check, we
can store the previous value and compare it to the new one. If it didn’t
change, we mark the argument as up-to-date. If all inputs of a pure operation
are up-to-date, we do not need to re-run it and can mark its output as up-to-
date. In the plan from Fig. 9 the operations drop and keep can be run in
parallel after read_csv. If the dataset returned by read_csv is unchanged, we
can skip the call to keep and can mark y_train as up-to-date.

Figure 9: Re-execution plan with dynamic non-staleness checks. The question
marks on an operation indicate that it is executed only if the dynamic non-
staleness check fails for one of its potentially stale input values.

This approach can eliminate expensive re-executions at the cost of remembering
previous values and comparing them to new ones. For large datasets or models,
such comparisons can be costly, too. Thus, the efficiency of the approach
critically depends on the trade-off between re-execution time and comparison
time. Even expensive comparisons might pay off, because they can eliminate re-
execution of many downstream pure operations, including the followup checking
of each of their results.

In this regard, an impure operation like read_csv is a particularly worthwhile
target for optimization: (1) It usually occurs right at the start of a
pipeline, so many other operations depend on it and must be repeated if
read_csv yields new results. (2) The returned data is large, so an equality
check is extremely expensive.

We can fortunately avoid executing file operations subject to a simple check
and the storing of minimal extra information: The time of the last
modification of each accessed file. If we call read_csv with the same path
argument and the respective file has still the same last modified time, the
operation returns the same result. We can, therefore, treat the last modified
time internally as an extra, hidden argument, and the modified read_csv
operation as pure. This principle can be generalized to other cases, e.g. a
random number generator that has a fixed seed is no source of impurity
anymore. This way, some often occurring cases of impurity can be eliminated,
accounting for noticeable re-execution speedups. It allows us to treat all
operations shown in Fig. 1 as pure.

##  VIII Technical Challenges and Solutions

The concept of notebooks builds on simple language-specific kernels. Our
proposal requires additional kernel features, namely static typing for the
context menu (Sec. VI), data-flow analysis to derive a correct but minimal
execution plan (Sec. VII), and purity inference as a basis for exploiting
parallelism. Implementing our proposal for arbitrary languages, would require
significant additional work from kernel developers. For some languages, it
would even be impossible to implement our extensions fully. Python, for
instance, allows dynamically importing modules via
importlib.import_module(name) [24]. Reading the module name from an encrypted
file would prevent static analysis of the module.

Instead of building on an existing language, we developed Safe-DS [25], a
domain specific language for implementing DS pipelines. Safe-DS can integrate
existing Python libraries via a simple stub language in a statically type-safe
way. This lets the compiler infer the type information that we need to provide
context-specific actions on variables. The design of Safe-DS as a language for
creating pipelines rather than implementing the algorithms used in the
pipeline makes data-flow analysis easy, due to the lack of loops, recursion,
and conditionals, which guarantees an acyclic data-flow graph. Safe-DS
additionally offers annotations to mark operations as pure, empowering the
compiler to prune the execution plan even in cases where purity cannot be
inferred. Lastly, Safe-DS has a standard library that prefers pure operations.

##  IX Limitations

Generalizing our approach to notebooks written in arbitrary languages can by
tricky. It depends on the quality of static analysis for types, data-flow and
purity available for the respective language. If at least data-flow analysis
works, one can alternatively annotate libraries with types and purity
information manually. But for non-trivial libraries, this may quickly exceed
available time. However, one can use a combined approach that performs a
static analysis and then lets developers review and complement its results by
annotating library elements with non-inferrable type or purity information
[26]. Such combined tools limit the amount of manual annotation, thus making
it possible to exploit the full potential of our approach in spite of the
limits of static analysis.

##  X Future Plans

### Prototype

We currently extend Safe-DS333https://github.com/Safe-DS/DSL by the discussed
computation of execution graphs based on data-flow analysis and purity
information. An experimental IDE for Safe-DS is already available as an
extension for Visual Studio
Code444https://marketplace.visualstudio.com/items?itemName=safe-ds.safe-ds.
After evolving Safe-DS, we will extend its IDE by the proposed, type-based
context menu for inspection of variables, including presentation of tabular
datasets (Fig. 4), to eliminate inspection code from the pipeline.

### Usability study

Once the prototype is complete, it will be compared quantitatively and
qualitatively to Jupyter Notebook. We will measure effects on code
comprehension (by separating value inspection and pipeline code), correctness
(by enforcing execution of code in the right order and re-execution of changed
code), and performance (by avoiding re-execution of unchanged code).

### Purity Inference for Python

Moreover, we plan to add purity inference (pure, impure, unknown) to the API-
Editor [26], use it to provide the unknown information, and let purity
information be reflected in the Safe-DS stubs that it creates. We will also
use its ability to automatically create wrappers that implement a uniform DS
API on the basis of existing Python libraries.

##  XI Conclusions

In this paper, we presented an alternative to cells as a basis to selectively
execute parts of a DS pipeline. We use static code analysis to derive a fine-
grained data-flow graph that focuses on individual operations rather than
cells (Sec. VII). From this, we derive an execution plan that is correct
(contains all operations and runs them in a valid order) and minimal (does not
contain unnecessary operations). Information about the purity of operations is
used to parallelize the execution plan, improving performance.

We completely eliminate the need for users to _write_ value inspection code,
by providing context-menu actions on variables to inspect their values (Sec.
VI). In an educational context, where value inspection steps must be contained
explicitly in the notebook, we propose to tag respective cells, so that they
can be eliminated when running a pipeline (Sec. V).

Overall, we expect that our approach will significantly speed up DS pipeline
development, by (1) avoiding bugs resulting from access to stale notebook
state, (2) rerunning only the code that must be rerun to update stale state,
and (3) eliminating the need to write and understand inspection code. We will
verify this claim in a usability study once the prototype for Safe-DS is
complete.

## Acknowledgments

This work was partially funded by the Federal Ministry of Education and
Research (BMBF), Germany under the Simple-ML project (grant 01IS18054). We
thank the reviewers for their numerous constructive comments and suggestions.

## References

  * [1] D. E. Knuth, “Literate Programming,” _The Computer Journal_ , vol. 27, no. 2, pp. 97–111, Jan. 1984.
  * [2] S. Biswas, M. Wardat, and H. Rajan, “The art and practice of data science pipelines: A comprehensive study of data science pipelines in theory, in-the-small, and in-the-large,” in _Proceedings of the 44th International Conference on Software Engineering_ , ser. ICSE ’22. New York, NY, USA: Association for Computing Machinery, May 2022, pp. 2091–2103.
  * [3] T. Kluyver, B. Ragan-Kelley, F. Pérez, B. Granger, M. Bussonnier, J. Frederic, K. Kelley, J. Hamrick, J. Grout, S. Corlay, P. Ivanov, D. Avila, S. Abdalla, C. Willing, and J. development team, “Jupyter notebooks — a publishing format for reproducible computational workflows,” in _Positioning and Power in Academic Publishing: Players, Agents and Agendas_ , F. Loizides and B. Scmidt, Eds. IOS Press, 2016, pp. 87–90. [Online]. Available: https://eprints.soton.ac.uk/403913/
  * [4] Kaggle. 2021 Kaggle Machine Learning & Data Science Survey. [Online]. Available: https://kaggle.com/competitions/kaggle-survey-2021
  * [5] Google. Google Colaboratory. [Online]. Available: https://colab.research.google.com/
  * [6] Kaggle. Notebooks Documentation. [Online]. Available: https://www.kaggle.com/docs/notebooks
  * [7] Amazon. Use Amazon SageMaker Notebook Instances - Amazon SageMaker. [Online]. Available: https://docs.aws.amazon.com/sagemaker/latest/dg/nbi.html
  * [8] Jetbrains. Jupyter notebook support — PyCharm. [Online]. Available: https://www.jetbrains.com/help/pycharm/jupyter-notebook-support.html
  * [9] T. Kabir. Notebooks, Visual Studio Code style. [Online]. Available: https://code.visualstudio.com/blogs/2021/11/08/custom-notebooks
  * [10] B. E. Granger, J. Grout, and B. Lp. JupyterLab: Building Blocks for Interactive Computing. [Online]. Available: http://archive.ipython.org/media/SciPy2016JupyterLab.pdf
  * [11] M. B. Kery, M. Radensky, M. Arya, B. E. John, and B. A. Myers, “The Story in the Notebook: Exploratory Data Science using a Literate Programming Tool,” in _Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems_ , ser. CHI ’18. New York, NY, USA: Association for Computing Machinery, Apr. 2018, pp. 1–11.
  * [12] A. Rule, A. Tabard, and J. D. Hollan, “Exploration and Explanation in Computational Notebooks,” in _Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems_ , ser. CHI ’18. New York, NY, USA: Association for Computing Machinery, Apr. 2018, pp. 1–12.
  * [13] J. Grus. I Don’t Like Notebooks. [Online]. Available: https://docs.google.com/presentation/d/1n2RlMdmv1p25Xy5thJUhkKGvjtV-dkAIsUXP-AL4ffI
  * [14] A. Head, F. Hohman, T. Barik, S. M. Drucker, and R. DeLine, “Managing Messes in Computational Notebooks,” in _Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems_ , ser. CHI ’19. New York, NY, USA: Association for Computing Machinery, May 2019, pp. 1–12.
  * [15] J. F. Pimentel, L. Murta, V. Braganholo, and J. Freire, “A Large-Scale Study About Quality and Reproducibility of Jupyter Notebooks,” in _2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR)_ , May 2019, pp. 507–517.
  * [16] S. Chattopadhyay, I. Prasad, A. Z. Henley, A. Sarma, and T. Barik, “What’s Wrong with Computational Notebooks? Pain Points, Needs, and Design Opportunities,” in _Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems_ , ser. CHI ’20. New York, NY, USA: Association for Computing Machinery, Apr. 2020, pp. 1–12.
  * [17] S. Macke, H. Gong, D. J.-L. Lee, A. Head, D. Xin, and A. Parameswaran, “Fine-grained lineage for safer notebook interactions,” _Proceedings of the VLDB Endowment_ , vol. 14, no. 6, pp. 1093–1101, Feb. 2021.
  * [18] J. F. Pimentel, L. Murta, V. Braganholo, and J. Freire, “Understanding and improving the quality and reproducibility of Jupyter notebooks,” _Empirical Software Engineering_ , vol. 26, no. 4, p. 65, May 2021.
  * [19] D. Koop and J. Patel, “Dataflow notebooks: Encoding and tracking dependencies of cells,” in _9th USENIX Workshop on the Theory and Practice of Provenance (TaPP 2017)_. Seattle, WA: USENIX Association, Jun. 2017. [Online]. Available: https://www.usenix.org/conference/tapp17/workshop-program/presentation/koop
  * [20] Nodebook — Stitch Fix Technology – Multithreaded. [Online]. Available: https://multithreaded.stitchfix.com/blog/2017/07/26/nodebook/
  * [21] S. Titov, Y. Golubev, and T. Bryksin, “ReSplit: Improving the Structure of Jupyter Notebooks by Re-Splitting Their Cells,” in _2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER)_ , Mar. 2022, pp. 492–496.
  * [22] R. DePratti, “Jupyter notebooks versus a textbook in a big data course,” _Journal of Computing Sciences in Colleges_ , vol. 35, no. 8, pp. 208–220, Apr. 2020.
  * [23] Z. J. Wang, K. Dai, and W. K. Edwards, “StickyLand: Breaking the Linear Presentation of Computational Notebooks,” in _Extended Abstracts of the 2022 CHI Conference on Human Factors in Computing Systems_ , ser. CHI EA ’22. New York, NY, USA: Association for Computing Machinery, Apr. 2022, pp. 1–7.
  * [24] Python developers. 5. The import system. [Online]. Available: https://docs.python.org/3/reference/import.html
  * [25] L. Reimann and G. Kniesel-Wünsche, “Safe-DS: A Domain Specific Language to Make Data Science Safe,” in _2023 IEEE/ACM 45th International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER)_ , May 2023\.
  * [26] ——, “Improving the Learnability of Machine Learning APIs by Semi-Automated API Wrapping,” in _2022 IEEE/ACM 44th International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER)_ , May 2022, pp. 46–50.


# Nonlinear stationary differential equations with fractional order
$1<\alpha<2$ on metric star graphs

K.K.Sabirov  Institute of Mathematics named after V.I.Romanovsky of the
Academy of Sciences of the Republic of Uzbekistan, University street 9,
Tashkent, 100174, Uzbekistan

###### Abstract

In this paper we consider nonlinear stationary fractional-in-space
differential equations with order $1<\alpha<2$ on the metric star graph with
three finite bonds. At the branched point of the star graph we put the weight
continuity and the generalized Kirchhoff rule. It is found the exact solutions
of nonlinear stationary fractional equations on the star graph. These can be
extended to the star graphs with any number of bonds.

##  I Introduction

In the past few decades of years it has attracted much attentions to the
fractional differential equations due to applications in numerous seemingly
diverse and widespread fields of science and engineering Hilfer -Umarov . It
is in constant development, which is fed by ideas and results of various
directions in mathematics. One of these directions is nonlinear ordinary and
partial differential equations considered on the branched structures so-called
metric graphs.

The application of differential equations on metric graphs in quantum theory
is described in detail in the works Smilansky -Exner . In Zarif , conservation
laws, such as energy and norm were studied for deriving boundary conditions at
the vertices of metric graphs and traveling soliton solution was considered.
Static soliton solutions of stationary nonlinear Schrödinger equations with
the boundary condition at the vertices of metric graphs were studied in the
Refs. Adami2011 -Karim . Static nonlinear waves in networks described by a
nonlinear Schrödinger equation with point-like nonlinearities on metric graphs
were studied, explicit solutions fulﬁlling vertex boundary conditions were
obtained and spontaneous symmetry breaking caused by bifurcations was found in
the Ref. Karim2022 .

In this paper we study two types of nonlinear fractional-in-space stationary
equations on the metric star graph with three finite bonds. In the section III
we give formulation of the problem described by nonlinear fractional
stationary differential equation with order $1<\alpha<2$ and we put the
boundary conditions as the weight continuity and the generalized Kirchhoff
rule at the branched vertex. In the section IV we obtain the static solution
on the metric star graph fulfilling after gluing boundary conditions at the
vertices. In the section V we consider another nonlinear stationary
fractional-in-space equation with order $1<\alpha<2$ on the star graph.

##  II Preliminaries

Definition 1: Let $\Omega=[a;b]$ be finite interval on real axis $R$. The
Riemann-Lioville fractional integrals denoted by $I_{a,x}^{\alpha}$ and
$I_{x,b}^{\alpha}$ of order $\alpha\in C\,(Re(\alpha)>0)$ are defined as

$\left(I_{a,x}^{\alpha}f\right)(x):=\frac{1}{\Gamma(\alpha)}\underset{a}{\overset{x}{\int}}\frac{f(t)dt}{(x-t)^{1-\alpha}},\,(x>a;\,Re(\alpha>0))$
(1)

and

$\left(I_{x,b}^{\alpha}f\right)(x):=\frac{1}{\Gamma(\alpha)}\underset{x}{\overset{b}{\int}}\frac{f(t)dt}{(t-x)^{1-\alpha}},\,(x<b;\,Re(\alpha>0))$
(2)

respectively, where $\Gamma(\alpha)$ is the Gamma function, integrals (1) and
(2) are called the left-sided and the right-sided fractional integrals.

Definition 2 The Riemann-Lioville derivatives denoted $D_{a,x}^{\alpha}y$ and
$D_{x,b}^{\alpha}y$ of order $\alpha\in{\bf C}$ $(Re(\alpha)\geq 0)$ are
defined by

$\left(D_{a,x}^{\alpha}y\right)(x):=\frac{1}{\Gamma(1-\alpha)}\left(\frac{d}{dx}\right)^{n}\underset{a}{\overset{x}{\int}}\frac{y(t)dt}{(x-t)^{\alpha-n+1}},\,(n=\left[Re(\alpha)\right]+1,\,x>a),$
(3)

and

$\left(D_{x,b}^{\alpha}y\right)(x):=\frac{1}{\Gamma(1-\alpha)}\left(-\frac{d}{dx}\right)^{n}\underset{x}{\overset{b}{\int}}\frac{y(t)dt}{(t-x)^{\alpha-n+1}},\,(n=\left[Re(\alpha)\right]+1,\,x<b),$
(4)

respectively, where $[Re(\alpha)]$ means integer part of $Re(\alpha)$. In
particular, $0<\alpha<1$, then

$\left(D_{a,x}^{\alpha}y\right)(x)=\frac{1}{\Gamma(1-\alpha)}\frac{d}{dx}\underset{a}{\overset{x}{\int}}\frac{y(t)dt}{(x-t)^{\alpha}},\,(x>a),$
(5)

and

$\left(D_{x,b}^{\alpha}y\right)(x)=-\frac{1}{\Gamma(1-\alpha)}\frac{d}{dx}\underset{x}{\overset{b}{\int}}\frac{y(t)dt}{(t-x)^{\alpha}},\,(x<b)$
(6)

##  III Formulation of the problem.

We consider the star graph $G$ with tree bonds $e_{j},\,j=1,2,3$, for which a
coordinate $x_{j}$ is assigned. Choosing the origin of coordinates at the
vertex, $L$, for bond $e_{j}$ we put $x_{j}\in[0;L_{j}]$. We use the shorthand
notation $y_{j}(x)$ for $y_{j}(x_{j})$ where $x$ is the coordinate on the bond
$j$ to which the component $y_{j}$ refers.

Figure 1: The metric star graph

We consider the following the nonlinear stationary differential equation with
fractional order $1<\alpha<2$ on the each bond

$\displaystyle\left(D_{0,x}^{\alpha}y_{j}\right)(x)=\lambda_{j}x^{\beta_{j}}\left[y_{j}(x)\right]^{m_{j}},\,0<x<L_{j},\,m_{j}\not=1,\,j=1,2,3$
(7)

with boundary conditions at the branched point

$\displaystyle\lambda_{1}^{\frac{1}{m_{1}-1}}y_{1}(x)|_{x=L_{1}}=\lambda_{2}^{\frac{1}{m_{2}-1}}y_{2}(x)|_{x=L_{2}}=\lambda_{3}^{\frac{1}{m_{3}-1}}y_{3}(x)|_{x=L_{3}},$
(8)
$\displaystyle\lambda_{1}^{\frac{m_{1}}{m_{1}-1}}\left(D_{0,x}^{\alpha-1}y_{1}\right)(L_{1}-)=\lambda_{2}^{\frac{m_{2}}{m_{2}-1}}\left(D_{0,x}^{\alpha-1}y_{2}\right)(L_{2}-)+\lambda_{3}^{\frac{m_{3}}{m_{3}-1}}\left(D_{0,x}^{\alpha-1}y_{3}\right)(L_{3}-),$
(9)

and the end of bonds

$\displaystyle\left(I_{0,x}^{2-\alpha}y_{j}\right)(+0)=0,\,j=1,2,3,$ (10)

where $y_{j}(x)\in C_{\gamma_{j}^{*}-\alpha}[0,L_{j}]$ for
$0<\gamma_{j}^{*}-\alpha<1,\,\gamma_{j}^{*}=\frac{\beta_{j}+m_{j}\alpha}{1-m_{j}},\,\lambda\not=0$.

Theorem 1: The problem (7)-(10) has the exact solution.

##  IV Proof of the Theorem 1.

We look for a solution of equation (7) in the form

$\displaystyle y_{j}(x)=A_{j}x^{\gamma_{j}-1},\,j=1,2,3,$ (11)

where $A_{j}$ is constant. After directly putting (11) into (7) the exact
solution of equation (7) is the following

$\displaystyle
y_{j}(x)=\left[\frac{\Gamma\left(\frac{\beta_{j}+\alpha}{1-m_{j}}+1\right)}{\lambda\Gamma\left(\frac{\beta_{j}+m_{j}\alpha}{1-m_{j}}+1\right)}\right]^{\frac{1}{m_{j}-1}}x^{\frac{\beta_{j}+\alpha}{1-m_{j}}}.$
(12)

Fulfilling the vertex boundary conditions (8)-(9) we have the following system
of transcendental equations with respect to $\lambda_{j},\,j=1,2,3$

$\displaystyle\left[\frac{\Gamma\left(\frac{\beta_{1}+\alpha}{1-m_{1}}+1\right)}{\Gamma\left(\frac{\beta_{1}+m_{1}\alpha}{1-m_{1}}+1\right)}\right]^{\frac{1}{m_{1}-1}}L_{1}^{\frac{\beta_{1}+\alpha}{1-m_{1}}}=\left[\frac{\Gamma\left(\frac{\beta_{2}+\alpha}{1-m_{2}}+1\right)}{\Gamma\left(\frac{\beta_{2}+m_{2}\alpha}{1-m_{2}}+1\right)}\right]^{\frac{1}{m_{2}-1}}L_{2}^{\frac{\beta_{2}+\alpha}{1-m_{2}}}=\left[\frac{\Gamma\left(\frac{\beta_{3}+\alpha}{1-m_{3}}+1\right)}{\Gamma\left(\frac{\beta_{3}+m_{3}\alpha}{1-m_{3}}+1\right)}\right]^{\frac{1}{m_{3}-1}}L_{3}^{\frac{\beta_{3}+\alpha}{1-m_{3}}},$
(13)
$\displaystyle\frac{\lambda_{1}}{\left(\frac{\beta_{1}+m_{1}\alpha}{1-m_{1}}+1\right)}\left[\frac{\Gamma\left(\frac{\beta_{1}+\alpha}{1-m_{1}}+1\right)}{\Gamma\left(\frac{\beta_{1}+m_{1}\alpha}{1-m_{1}}+1\right)}\right]^{\frac{1}{m_{1}-1}+1}L_{1}^{\frac{\beta_{1}+\alpha}{1-m_{1}}+1}=\frac{\lambda_{2}}{\left(\frac{\beta_{2}+m_{2}\alpha}{1-m_{2}}+1\right)}\left[\frac{\Gamma\left(\frac{\beta_{2}+\alpha}{1-m_{2}}+1\right)}{\Gamma\left(\frac{\beta_{2}+m_{2}\alpha}{1-m_{2}}+1\right)}\right]^{\frac{1}{m_{2}-1}+1}L_{2}^{\frac{\beta_{2}+\alpha}{1-m_{2}}+1}+$
$\displaystyle\frac{\lambda_{3}}{\left(\frac{\beta_{3}+m_{3}\alpha}{1-m_{3}}+1\right)}\left[\frac{\Gamma\left(\frac{\beta_{3}+\alpha}{1-m_{3}}+1\right)}{\Gamma\left(\frac{\beta_{3}+m_{3}\alpha}{1-m_{3}}+1\right)}\right]^{\frac{1}{m_{3}-1}+1}L_{3}^{\frac{\beta_{3}+\alpha}{1-m_{3}}+1}.$
(14)

In the particular case when $m_{j}=m,\,\beta_{j}=\beta,\,L_{j}=L,\,j=1,2,3$,
we have $\lambda_{1}=\lambda_{2}+\lambda_{3}$, therefore the system of
transcendental equations (13)-(14) has a solution. Now it is clear that the
exact solution (12) fulfills not only the boundary conditions (10) and
satisfies the following conditions

$\displaystyle\left(D_{0,x}^{\alpha-1}y_{j}\right)(+0)=0,\,j=1,2,3.$ (15)

Therefore the considered problem has the exact solution in the form (12).
Theorem is proved.

##  V Another nonlinear stationary fractional equation on the star graph

We consider the following the nonlinear stationary differential equation with
fractional order $1<\alpha<2$ on the each bond

$\displaystyle\left(D_{0,x}^{\alpha}y_{j}\right)(x)=\lambda_{j}x^{\beta_{j}}\left[y_{j}(x)\right]^{m_{j}}+b_{j}x^{\nu_{j}},\,0<x<L_{j},\,m_{j}>0,\,m_{j}\not=1,\,j=1,2,3$
(16)

with weight continuity boundary condition (8) and (9) at the branched point
and the conditions (10) at the end of bonds, where $y_{j}(x)\in
C_{\gamma_{j}^{*}-\alpha}[0,L_{j}]$ for
$0<\gamma_{j}^{*}-\alpha<1,\,\gamma_{j}^{*}=\frac{\beta_{j}+m_{j}\alpha}{1-m_{j}},\,\lambda\not=0$.

We look for a solution of equation (7) in the form (11), where $A_{j}$ is
satisfied the following transcendental equation

$\displaystyle\Gamma\left(\frac{\beta_{j}+\alpha}{1-m_{j}}+1-\alpha\right)\left(\lambda_{j}A_{j}^{m_{j}}+b_{j}\right)-\Gamma\left(\frac{\beta_{j}+\alpha}{1-m_{j}}+1\right)A_{j}=0.$
(17)

We suppose that

$\displaystyle\nu_{j}=\frac{\beta_{j}+m_{j}\alpha}{1-m_{j}}.$ (18)

Then it is easily verified that the nonlinear equation (16) has the solution

$\displaystyle y_{j}(x)=A_{j}x^{\frac{\beta_{j}+\alpha}{1-m_{j}}}.$ (19)

So we have $\gamma_{j}=\frac{\beta_{j}+\alpha}{1-m_{j}}+1$. It is clear that
the exact solution (19) fulfills not only the boundary conditions (10) and
satisfies the conditions (15). After putting the solution (19) into the vertex
boundary conditions (8)-(9) we have the following system of transcendental
equations with respect to $\lambda_{j},\,j=1,2,3$

$\displaystyle\lambda_{1}^{\frac{1}{m_{1}-1}}A_{1}L_{1}^{\gamma_{1}-1}=\lambda_{2}^{\frac{1}{m_{2}-1}}A_{2}L_{2}^{\gamma_{2}-1}=\lambda_{3}^{\frac{1}{m_{3}-1}}A_{3}L_{3}^{\gamma_{3}-1},$
(20)
$\displaystyle\lambda_{1}^{\frac{m_{1}}{m_{1}-1}}A_{1}\frac{\Gamma(\gamma_{1})}{\Gamma(\gamma_{1}-\alpha)}L_{1}^{\gamma_{1}-\alpha-1}=\lambda_{2}^{\frac{m_{2}}{m_{2}-1}}A_{2}\frac{\Gamma(\gamma_{2})}{\Gamma(\gamma_{2}-\alpha)}L_{2}^{\gamma_{2}-\alpha-1}+\lambda_{3}^{\frac{m_{3}}{m_{3}-1}}A_{3}\frac{\Gamma(\gamma_{3})}{\Gamma(\gamma_{3}-\alpha)}L_{3}^{\gamma_{3}-\alpha-1}.$
(21)

In the particular case when $m_{j}=m,\,\gamma_{j}=\gamma,\,L_{j}=L,\,j=1,2,3$,
we have $\lambda_{1}=\lambda_{2}+\lambda_{3}$, therefore the system of
transcendental equations (20)-(21) has a solution.

Now we formulate the following theorem.

Theorem 2: The problem (16) with the boundary conditions (8)-(10) has the
exact solution in the form (11).

##  VI conclusions

We considered nonlinear stationary differential equations with fractional-in-
space order $1<\alpha<2$ on the metric star graph with three finite bonds in
this work. We put weight continuity and the generalized Kirchhoff rule at the
branched point of the star graph . First we look for the solution on the each
bond, after gluing conditions at the vertex and the ends of bonds the exact
solutions of nonlinear stationary fractional equations on the star graph were
found. These can be extended to the star graphs with any number of bonds.

## References

  * (1) R. Hilfer, Applications of fractional calculus in physics, Stuttgart, Germany, 2000.
  * (2) Anatoly A. Kilbas, Hari M. Srivastava, Juan J. Trujillo, Theory and applications of fractional differential equations, Amsterdam, the Netherlands, 2006.
  * (3) S. Umarov, Introduction to Fractional and Pseudo-Diﬀerential Equations with Singular Symbols, Springer, 2015.
  * (4) T. Kottos, U. Smilansky, Periodic Orbit Theory and Spectral Statistics for Quantum Graphs, Annals of Physics, 1999, 274, No. 1, P. 76–124.
  * (5) P. Exner, H. Kovarik, Quantum waveguides, Springer, 2015.
  * (6) Z. Sobirov, D. Matrasulov, K. Sabirov, S. Sawada, K. Nakamura, Integrable nonlinear Schrödinger equation on simple networks: Connection formula at vertices, Physical Review E, 2010, 81, 066602.
  * (7) R. Adami, C. Cacciapuoti, D. Finco, D. Noja, Fast solitons on star graphs, Reviews in Mathematical Physics, 2011, 23, No. 04, 409–451.
  * (8) R. Adami, C. Cacciapuoti, D. Finco, D. Noja, Stationary states of NLS on star graphs, EPL (Europhysics Letters), 2012, 100, No. 1, 19901.
  * (9) K.K. Sabirov, Z.A. Sobirov, D. Babajanov, D.U. Matrasulov, Stationary nonlinear Schrödinger equation on simplest graphs, Physics Letters A, 2013, 377, P. 860.
  * (10) D. Noja, Nonlinear Schrödinger equation on graphs: recent results and open problems, Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences, 2014, 372, 20130002.
  * (11) K. K. Sabirov, J. R. Yusupov, Kh. Sh. Matyokubov, H. Susanto, D. U. Matrasulov, Networks with point-like nonlinearities, Nanosystems: Physics, Chemistry, and Mathematics, 2022, 13, No. 1, 30–35.