View Source

Draft for review. This page is under review before the Operational Readiness Review. Panels marked as open questions are still waiting for an answer. Send corrections to the Research Platform team.

Read time: 8 minutes. This page walks through one working day, in order. Prefer a tool-by-tool list? Read the tool reference instead. The team will decide which of the two pages to publish, or publish both.

Before you start

You need one of these, and a project:

a NASA identity, or
a STAR ID.

See How to get access.

Step 1 — Log in

Open rp.sciencecloud.nasa.gov in your browser.
Sign in. You are sent to the Science Cloud login service (STAR).
You land on the launch screen.

There is nothing to install.

Step 2 — Choose your machine, then start

The launch screen asks two things.

How big a machine? From a small 4 GB workspace, up to a 64 GB machine with 8 CPUs, or a GPU machine. (A GPU is a chip that is fast for AI and image work.)

Which software set? A ready-made science stack, or your project's own image. (An image is a packaged set of software.)

Example. You plan to open one dataset and draw a few charts. Take the small workspace. You can stop it later and start a bigger one — your files stay.

Press start. Your workspace opens in a minute or two.

Step 3 — Find your way around JupyterLab

You are now in JupyterLab. The important parts:

Part of the screen	What it is for
Left sidebar — file browser	Your files
Left sidebar — other icons	The platform tools: usage, data browser, AI tools, background jobs
Launcher (the big tile page)	Start a notebook, a terminal, or a collaboration session
Main area	Your open notebooks

Step 4 — Know where to put your files, and what survives a restart

This is the most important thing to learn on day one. Some places keep your files. Some do not.

Place	Path	Who sees it	Survives a restart?
Your home folder	`~`, which is `/home/<your name>` — for example `/home/ramon.linan`	Only you	✅ Yes
Your own EFS folder	`/efs/<your username>` — the full email form, for example `/efs/ramon.linan@navteca.com`	Only you	✅ Yes
A project folder on EFS	`/efs/<project>` — one for every project you belong to	Everyone in that project	✅ Yes
Object storage — your own space	`s3://<bucket>/home/<your username>`	Only you	✅ Yes
Object storage — project space	`s3://<bucket>/<project>` — the project you picked at launch	Your project	✅ Yes
Anywhere else in the machine	`/tmp`, system folders, software you install outside your home folder	—	❌ No. Lost.

The rule: keep your work in ~, in /efs/…, or in object storage. Everything else disappears when your workspace restarts.

How big is your home folder? It starts at 10 GB. It can be made larger — ask the platform team for the size you need. Keep it sensible: a very large home volume makes your workspace slower to start. Large data belongs in /efs/<project> or in object storage.

Two things worth knowing:

EFS shows you every project you belong to. Open /efs/ and you see a folder for each one. You cannot open other people's folders — the permissions stop you.
The file browser and the terminal show the same files, laid out differently. The left-hand file browser and the command line have the same permissions. Do not worry if the two views look different.

Which one should I use?

Your file	Put it here
My notebooks and scripts	Home folder, `~`
Data or a result my team needs	The project folder, `/efs/<project>`
A very large dataset	Object storage
A scratch file I do not care about	Anywhere. It will be lost.

Step 5 — Do the science

Open the Launcher and start a notebook. Write code in a cell. Press Shift+Enter to run it. The result appears under the cell.

This part is normal Jupyter. If you have used Jupyter anywhere else, you already know it.

Step 5b — Make your own kernel from a conda environment

Sometimes the ready-made software set does not have the package versions you need. You can build your own environment and use it as a kernel. (A kernel is the entry in the notebook's "choose your language" menu. An environment is your own private set of packages.)

Build it in your home folder. That is what makes it survive a restart.

Open a terminal from the Launcher and run:

# 1. create the environment (mamba is the fast version of conda)
mamba create -n myscience python=3.12 ipykernel -y

# 2. turn it on
conda activate myscience

# 3. add the packages you need
mamba install -c conda-forge xarray netcdf4 -y

That is all. The kernel appears in JupyterLab by itself, because the platform watches your environments for you. Use Kernel → Change Kernel in your notebook and pick it.

Why this survives a restart. The platform is set up to keep your environments in ~/users_conda_envs, which is inside your home folder. So mamba create -n myscience writes to /home/<your name>/users_conda_envs/myscience, and it is still there tomorrow.

Two things to remember. 1. Always put ipykernel in the environment. Without it, there is no kernel to pick. 2. Use conda or mamba — both work. mamba is faster.

If the kernel does not appear, register it by hand: python -m ipykernel install --user --name myscience --display-name "My science env"

Step 6 — Get AI help while you work

The Notebook Intelligence tool puts an AI assistant in JupyterLab.

Example — explain code. You open a colleague's notebook and do not understand a cell. Select the cell, ask the assistant to explain it, and read the answer next to the code.

Example — write code. In an empty cell, describe what you want, such as "read this CSV and plot the monthly mean". The assistant writes the code. You check it and run it.

Example — fix an error. A cell fails. Ask the assistant what the error means. It suggests a fix in place.

You can also use your own model provider. See Notebook Intelligence and your LLMs.

Give the assistant new skills. The AgentRegistry panel in the left sidebar lists approved MCP servers — small services that teach the assistant a new trick, such as searching a data catalog. Press Add to NBI on one, and your assistant can use it. See the tool reference.

Step 7 — Browse and pull in data

The data browser (jupyterlab-bxplorer) opens cloud storage inside JupyterLab. No command line needed.

Example — your own data. Open the data browser, choose your project's bucket, walk down the folders, and download the file you want into your notebook folder.

Example — public data. Choose a public AWS science dataset, find the file you need, and pull it in — without leaving JupyterLab and without any keys.

Download only. The data browser brings files in. It does not upload or write back. To put data into object storage, use the command line or your own code.

Coming later: Google Cloud and Microsoft Azure storage.

Step 8 — Need more power? Two choices

Choice A — many machines at once (Dask)

Use this when one analysis is too slow or too big for your workspace. Dask spreads the work over many machines and brings the answer back.

Example. You must process a year of daily files. Alone, it takes hours. With a Dask cluster of 10 machines, it takes minutes.

Start a cluster from your notebook, run the work, then shut the cluster down. The cluster costs money while it is up.

Example notebook — to be linked. The platform team will publish a ready-made notebook that starts a Dask cluster, runs a job, and shuts the cluster down. The link goes here.

Choice B — send the job to the background (NBQueue)

Use this when a notebook takes a long time and you do not want to sit and watch it.

Example. A notebook needs 6 hours and 40 GB of memory. Send it to the background queue and pick a bigger machine for it. Your own workspace stays small and responsive. You can close the browser. The job keeps running.

You pick the notebook, pick the machine, and send it. Then check the status in the same panel. When it finishes, the finished notebook, with its output, is waiting for you.

Step 9 — Work with your team on the same file

If your project has collaboration turned on, your Launcher shows a tile named "Open <your project> Collaboration".

Example. Three of you must finish one notebook today. One person clicks the tile. Everyone else clicks the same tile and lands in the same session. You all edit the same notebook at once and see who is online. The files live in the shared project space.

Save the group's work in /efs/<your project>. Files left in the shared session's own home folder can only be reached from inside that session.

When the work is done, click the tile again to stop the session. It costs the project money while it runs.

Full detail: Working together on the same notebook.

Step 10 — Watch what you are spending

Open the usage panel (Resource Tracker) in the left sidebar. It shows:

This month — hours used, compute cost, and storage cost split by type.
Funding period to date — what you have used, what you were given, and what is left.
When the numbers were last updated.

Good to know. The numbers are taken when your workspace starts, and cost data is prepared once a day. So the panel does not tick up live. To refresh it, stop your workspace and start it again.

Step 11 — Stop when you finish

This is the step people forget, and it is the one that costs money.

Stop your notebook when you are done for the day.
Shut down any Dask cluster.
Stop the collaboration session when the group is finished.

Your files stay. Only the running machines stop. An idle session is closed automatically after about an hour, but do not rely on that — an open browser tab can keep it alive.

The one-minute version

Go to rp.sciencecloud.nasa.gov and log in.
Pick a machine size. Start it.
Keep files in ~, in /efs/<project>, or in object storage. Everything else is lost on restart.
Work in a notebook. Ask the AI assistant when you are stuck. Need your own packages? Build a conda environment in ~/envs and register it as a kernel.
Big job? Dask for parallel work, NBQueue for long background runs.
Same file as a colleague? Use the collaboration tile.
Check the usage panel.
Stop everything when you finish.

Where to get help

Email support@sciencecloud.nasa.gov, or use the Science Cloud Support Portal.