Notebook environments

With Jupyter notebook environment definitions for Python and R, you can select the hardware and software configuration of the runtime environments for notebooks that you run in the notebook editor.

All notebook environments consume capacity unit hours (CUHs), which is the period of time the runtime is active, multiplied by the size of its hardware configuration. The CUHs are tracked.

Default Jupyter notebook environment definitions

Watson Studio offers default Jupyter notebook environment definitions that you can use to quickly get started with Python or R in notebooks, without having to create your own environment definitions. The default environment definitions are listed on the project’s Environments page.

Name Hardware configuration
Default Python 3.7 XXS 1 vCPU and 4 GB RAM
Default Python 3.7 XS 2 vCPU and 8 GB RAM
Default Python 3.7 S 4 vCPU and 16 GB RAM
Default Python 3.7 XS + DO * 2 vCPU and 8 GB RAM
Default Python 3.6 XS 2 vCPU and 8 GB RAM
Default Python 3.6 S 4 vCPU and 16 GB RAM
Default Python 3.6 XS + DO * 2 vCPU and 8 GB RAM
Default R 3.6 S 4 vCPU and 16 GB RAM

* Select this environment definition to include the CPLEX and the DOcplex libraries to model and solve decision optimization problems that exceed the complexity that is supported by the Community Edition of the libraries in the other default Python environments.

File system in Jupyter notebook environments

If you are working with large data sets, you should store the data sets in smaller chunks in the IBM Cloud Object Storage associated with your project and process the data in chunks in the notebook. Alternatively, you should run the notebook in a Spark environment.

Be aware that the file system of each runtime is non-persistent and cannot be shared across environments. To persist files in Watson Studio, you should use IBM Cloud Object Storage. The easiest way to use IBM Cloud Object Storage in notebooks in projects is to leverage the project-lib package for Python or the project-lib package for R.

Runtime scope

Environment runtimes are always scoped to an environment definition and a user within a project.

For example, if you associate each of your notebooks with its own environment, each notebook will get its own runtime. However, if you open a notebook in an environment, which you also selected for another notebook and that notebook has an active runtime, both notebook kernels will be active in the same runtime. In this case, both notebooks will use the compute and data resources available in the runtime that they share.

If you want to avoid sharing runtimes but want to use the same environment definition for multiple notebooks in a project, you should create multiple custom environment definitions with the same specifications and associate each notebook with its own definition.

If different users in a project work with the same environment, each user will get a separate runtime.

If you select to run a version of a notebook as a scheduled job, each scheduled job will always start in a dedicated runtime. The runtime is stopped when the job finishes.

Next steps