1.4 Computing Environments

🖥️ Lecture slides — Session 02 (Fri Oct 2)

We will discuss how to work with various environments.

Local environment¶

To work locally using Python and Jupyter notebooks.

We recommend Visual Studio Code for editing code and notebooks, running them, and interacting with GitHub. It is how we wrote this book, and it is where most agentic AI assistants live (see 1.8).

Either through your OS or from VS Code, open a terminal. The terminal passes commands to the computer through a shell; BASH (Bourne Again SHell) is the most common implementation. Good tutorials for getting started are in the Software Carpentries lessons.

Get to know your hardware. Find out what CPU, GPU, and memory your machine has. htop monitors resources in real time; install it locally (e.g., brew install htop on macOS).

CPUs, GPUs, and other accelerators¶

Machine learning workloads parallelize. CPUs (Central Processing Units) are sufficient for most classic ML: they are the default hardware of every computer and handle the I/O of large data sets well. CPUs typically have between 8 and 96 cores.

Deep learning — both training models and running inference with trained ones — is enabled by the much wider parallelism of accelerators:

• NVIDIA GPUs remain the default. The CUDA programming model (2007) made general computation on GPUs practical, and PyTorch targets it first. GPUs have thousands of cores (roughly 5,000-20,000).
• Apple silicon Macs have an integrated GPU that PyTorch uses through the MPS (Metal Performance Shaders) backend: device = "mps". It is plenty for the models in this course, so a recent MacBook is a legitimate deep learning machine for class-scale problems.
• TPUs (Tensor Processing Units) are Google’s accelerators, available on Google Cloud and in Colab.

To watch how an NVIDIA GPU is being used:

watch nvidia-smi

Renting GPUs costs real money. As of 2026, on-demand cloud pricing runs from well under a dollar per hour for a modest GPU to several dollars per hour for a current data-center GPU, and spot/preemptible instances are cheaper but can be interrupted. Two habits follow: measure and report your compute time (the final project requires it), and size the hardware to the problem — most course projects train in minutes on a laptop or a free Colab GPU, and buying a bigger GPU is not a substitute for a better-posed problem.

Individual CPUs compose a node. Multiple nodes compose a cluster. Clusters can be local (if you are lucky!) and most often remote. Typical tiers: your research group’s machine, the institutional cluster (e.g., Hyak at UW), a national HPC center (e.g., TACC), or a cloud provider (AWS, Azure, GCP). In cloud computing, a node is an instance.

HPC¶

HPC (High Performance Computing) refers to a system of tightly connected nodes for large-scale jobs. The Software Carpentries have tutorials on using clusters: see the Introduction to HPC lessons. These architectures enable “vertical scaling”: bigger CPU, memory, or I/O per job.

HPC systems have 1) a compute cluster, 2) a scratch file system (temporary), and 3) a home file system. Code lives in home, big data on scratch, and jobs run on the compute cluster through a scheduler queue. It is typical to run big jobs on hundreds to thousands of nodes.

Institutions may have their own HPC systems. At UW, the system is called Hyak.

National HPC resources require an allocation request, typically through NSF ACCESS or TACC. ACCESS has an entry-level tier suitable for course projects and exploratory research.

One typically 1) chooses the HPC resource, then 2) moves the data there for the computing workflow.

Cloud¶

Cloud computing refers to a system of loosely connected nodes. There are many cloud providers, with three at the top: Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.

Cloud centers are distributed around the world to enable fast global access; the centers are called regions.

Storing and moving data is usually the most expensive part of cloud geoscience. One typically finds 1) where the data is archived, then 2) chooses the cloud provider and the region where that data lives, so compute runs next to the data.

Watch an eScience tutorial on getting started on AWS: Getting started on AWS (video).

Free and low-cost notebooks¶

• Google Colab gives anyone with a Google account a hosted notebook with a free tier that includes limited GPU or TPU time; paid tiers add faster hardware and longer sessions. Colab is the quickest way to try a GPU in this course. Example notebook:
• GitHub Codespaces launches a VS Code environment in the cloud directly from a repository, with a monthly free quota for personal accounts. Because it starts from your repo and its environment files, it is a good test of whether your project is actually reproducible.

Open data on the clouds¶

The major clouds host large open geoscience archives, and it is worth knowing where the data lives even if you compute elsewhere:

• The AWS Open Data registry hosts many geoscience archives on S3, free to access. Examples usable in this book:
  • Southern California Seismic Network waveforms. Here.
  • Distributed Acoustic Sensing (DAS) PoroTomo experiment. Here.
  • OpenEEW: low-cost seismometers in populated areas. Here.
• The Microsoft Planetary Computer catalogs petabytes of environmental data on Azure (catalog, e.g. Landsat). The data and STAC API are openly accessible; compute alongside it runs on your own Azure resources.
• Source Cooperative is a repository for cloud-hosted open geospatial data, run by the Radiant Earth non-profit (it succeeds the retired Radiant MLHub).
• Hugging Face datasets hosts a growing number of ML-ready Earth science data sets and benchmark collections, downloadable with the datasets library.

Access models change; check each provider’s current terms rather than assuming a free tier.