Scientific Computation

for Research and Teaching

with Jupyter

Michael Pilosov, University of Colorado Denver

Motivation and Qualifiers

  • Love applied math… Hate the learning curve
  • Want to make (computational) math accessible
  • Some familiarity with website design
  • Vague understanding of application architecture

Backstory

  • Wanted to embed interactive content into website
  • Difficulty with back-end, lack of understanding
  • Kept seeing some of the same words/phrases
    • Docker, Servers, Databases, Ports, Containers, Volumes, Mounting, Images, Spawning, etc.
  • Some experience with JupyterHub (barely).
    • Understood a server was involved (somehow)
    • User during SIAM G2S3 Summer School

Purpose of Talk

  • Will not explain exactly how this all works
  • Will explain Jupyter “ecosystem”
  • Focus on key design choices/features
  • Discuss implementation process, challenges
  • Demonstrate features, use-cases, future

Start at the Beginning Ending…

Overarching Goal: Ease of Use

  • Outline the “end-user” experience for
    • Students
    • Teachers
    • IT Admins (maybe)

The Process

  • Saw series of conference talks on YouTube
  • Spent ~3 weeks “playing” with the technology
    • Documented everything on website
  • Showed advisor, implemented it for a few professors
    • Two servers (2 cores, 36 threads/core, 500-1000GB RAM)
    • S19 is “trial period” to work out the problems
  • Now actively “maintaining” the servers

Student Experience

  • Get username/password from professor
  • Log in from ANY computer
    • Platform independent
  • “All” software is pre-installed
    • Additional packages can be installed by students
  • work/ folder allows data to persist
  • Computations are performed on Dept. servers
    • better battery life!
    • cheaper computers, laboratories

Teacher Experience

(TBD)

  • Depends on technical ability of professors
    • setup.sh script simplifies first-time deployment
  • Troubleshooting and Customization
    • professors seem to “prefer” outsourcing problems
    • UC Berkeley takes the opposite approach.
  • jupyterhub_config.py allows for tweaks
  • singleuser/Dockerfile defines environments

Potential Upside

  • After growing pains: can scale class sizes
  • Automatic-grading
  • Interactive Textbooks/Notebooks/Labs
  • Drop outdated technology contracts (MyMathLab)
  • Students using cutting-edge open-source software
    • can start coding “early”
    • looks great on resume
  • Professors/IT people can avoid cross-platform software support for computing courses

Features

  • Students are “isolated” in their environments
    • Restricted permissions
    • Harder for them to “break” things
  • Data and Application are divorced
    • “Light” server-load due to containerization
    • Backups are “easier”
  • Can scale with class-size

Demonstration

  • Show off the Hub

Questions?

Homepage