Jupyter Workspace

"Jupyter Workspace" (also referred to simply as "Workspace" below) is an interactive programming environment provided by the HyperAI platform:

• Provides an interactive environment with JupyterLab as the entry point, with an easy-to-use interface suitable for various data science and machine learning tasks.
• Supports "restart" functionality, making it easy to restore previous work states without creating new execution instances, avoiding duplicate storage space issues.
• Automatically binds previous "working directory" content on each startup, while allowing adjustments to configurations such as "computing power," "runtime environment" (image), and data binding (input binding).

Basic Interface

Click "Open Jupyter Workspace" on the single execution page to enter the following interface:

The sidebar on the right displays basic information about the current execution, including system metrics, basic execution information (computing power type, runtime environment, running time), and settings interface. Through system metrics, you can understand whether the current execution is effectively utilizing the computing resources provided by the system. After the execution opens, the openbayes-intro.ipynb file will pop up by default, containing some basic introductions to the HyperAI Jupyter workspace.

Although the directory displayed at the top of the file navigation bar on the left side of the JupyterLab page is /home, it does not refer to the /home directory in the system, but rather the location relative to the root directory set by JupyterLab. HyperAI sets JupyterLab's working directory to /openbayes, so when JupyterLab displays the directory as /home, the actual corresponding system directory is /openbayes/home.

The left file navigation bar cannot display content from directories outside /openbayes. If you need to save files from other directories, please copy the content from other directories to the /openbayes/home directory through the JupyterLab Terminal command line.

Creating a Jupyter Workspace

The workflow for creating a workspace is as follows. When selecting "Access Method," choose "Jupyter Workspace":

:::note During the "Data Binding" phase when creating an execution, the workspace can perform data binding. See the documentation on "Data Binding". :::

After the execution starts, the interface looks like this:

Running Long-Duration Training

Machine learning, especially deep learning training tasks, typically require relatively long running times, but as an interactive programming environment, the workspace is not very suitable for this scenario.

Although programs executed in the workspace will continue running even after closing the webpage, running long-duration tasks in the workspace has the following two issues:

1. When a long-duration task is running, any network fluctuations will cause its log printing to be interrupted, making it impossible to view the current training progress
2. When a long-duration task executes in the Jupyter workspace, even if the task completes or encounters an error, the workspace will not close immediately, but billing continues, resulting in wasted computing resources

Therefore, if you need to execute long-duration training tasks, it is recommended to refer to the Combining Task and Jupyter Workspace section to use task for long-duration tasks. However, two corresponding solutions are still provided here:

Using Log Console to Find Lost Logs

Here is a simple code snippet that simulates a long-running task:

import time

for i in range(100000):
    print(i)
    time.sleep(1)

When executing this code in a .ipynb file, you will see the following log information:

This code block will continuously update the logs, but if we refresh the page and come back, we'll find that the logs are no longer updating. At this point, right-click on the code block and select "Show Log Console" to open the current Log Console interface.

Then select the Debug level logs to see the previous log progress:

Using log redirection to save logs to a file and using the tail command to view the latest log content

For long-running tasks executed through Terminal, you can redirect logs to a specific file and view the logs using the tail -f command:

# Redirect the output of python train.py to the train.log file
python train.py > train.log 2>&1 &

# View the contents of the train.log file using the tail -f command
tail -f train.log

Automatic shutdown of Jupyter workspace

Since the "workspace" starts billing once it's opened, to reduce waste of computing resources due to forgetting to close it, HyperAI has added an automatic shutdown setting for idle "workspaces" in containers by default.

In HyperAI, a "workspace" needs to meet two conditions to be considered idle:

1. The workspace page is closed
2. CPU usage continuously remains below 2%

In the "Settings" tab of the "Container", you can see "JupyterLab Idle Auto-shutdown Settings", where you can set how long the container will be automatically shut down after being in an idle state. The default duration is 30 minutes. When a container is identified as idle, the container creator will receive a notification (via SMS or email). If the container remains idle and reaches the maximum idle time set, it will be shut down. In this case, HyperAI will also send a container shutdown notification to the container creator. The notification method for container idle shutdown can be configured in gear#notification settings.

:::caution Note: Very Important! Whether the workspace page is closed is determined through the API provided by JupyterLab. We do not record users' editing content. If the workspace page is not closed, the backend will detect that the workspace is active. In this case, we consider the "workspace" to still be in use and will not trigger the idle shutdown mechanism.

Closing the workspace page will not interrupt programs that are already running. Therefore, if you need to execute long-running tasks in the workspace and want the program to trigger idle shutdown after completion, you can directly close the page.

Sometimes, even though the workspace is not closed, if the computer itself is locked or goes to sleep, HyperAI may also consider the container inactive. However, this situation depends on each person's computer settings. If you want to trigger idle shutdown to avoid wasting computing resources, it is still recommended to close the page. :::

When a container is automatically shut down due to idle duration, HyperAI will display "Timeout Shutdown" in the container status.

Restarting the Jupyter Kernel

Each time you open a .ipynb file in the Jupyter workspace, the system creates a corresponding background process called a kernel to execute the code submitted on the page. If you find that your .ipynb file is having issues executing commands, the simplest solution is to restart the corresponding kernel:

Restarting a Jupyter Workspace

After a workspace is shut down, it can be started again. Currently, workspaces support two startup modes: "Quick Start" and "Modify Configuration and Start".

Quick Start

Click "Start" on the page for quick startup. By default, it retains the "Data Binding", "Computing Power", and "Runtime Environment" (image) from the last execution, and automatically binds the data from the "Working Directory" of the last run.

Modify Configuration and Start

If you need to modify the configuration, click the arrow to the right of "Start":

After that, you can modify information such as computing power, runtime environment (image), and data binding according to the workflow.

High-Speed Cache Mechanism for Jupyter Workspaces

• The number of workspaces each user can create is unlimited, but the number of cacheable workspaces we provide for each user is limited
• When creating a workspace, it is cached by default. Cached workspaces will display an additional lightning bolt icon on the interface
• When the current user's high-speed cache limit is reached, old cached workspaces will be downgraded to regular workspaces. When cached workspaces are downgraded, priority is always given to deleting the one with the earliest last shutdown time (the oldest one)
• Cached workspaces have a maximum cache time after shutdown. After this time, even if no new workspace is created, they will be downgraded to regular workspaces
• Cached workspaces have no functional difference from regular workspaces, only a difference in startup speed

Creating a Snapshot for a Workspace

Creating a "Snapshot" saves the current workspace's "Working Directory" as a fixed version for future use:

After a snapshot is created, it requires a certain amount of copy time depending on the size of the "Working Directory". The larger the workspace's "Working Directory", the longer the copy time required.

Snapshots record the "Computing Power Type", "Data Binding", and "Image Type" used by the workspace. Through "Continue Execution", you can launch a new "Workspace" from this snapshot, which by default inherits the configurations recorded by the snapshot and copies the snapshot's "Working Directory" to the new workspace's /openbayes/home directory:

Points to note about snapshot mode:

• Users can only create snapshots when the workspace is in "Running" or "Shut Down" states
• The space occupied by snapshots incurs standard storage space fees with no additional charges. Deleting snapshots that are no longer used will free up the corresponding storage space
• When creating a snapshot, try to avoid performing file write/modify operations on a running workspace to prevent the generated snapshot from being inconsistent with expected content