Skip to main content

Run many `adaptive.Learner`s on many cores (>10k) using `mpi4py.futures`, `ipyparallel`, or `dask-mpi`.

Project description

PyPI Conda Downloads Build Status Documentation Status

Run many adaptive.Learners on many cores (>10k) using mpi4py.futures, ipyparallel, or dask.distributed.

What is this?

The Adaptive scheduler solves the following problem, you need to run more learners than you can run with a single runner and/or can use >1k cores.

ipyparallel and dask.distributed provide very powerful engines for interactive sessions. However, when you want to connect to >1k cores it starts to struggle. Besides that, on a shared cluster there is often the problem of starting an interactive session with ample space available.

Our approach is to schedule a different job for each adaptive.Learner. The creation and running of these jobs are managed by adaptive-scheduler. This means that your calculation will definitely run, even though the cluster might be fully occupied at the moment. Because of this approach, there is almost no limit to how many cores you want to use. You can either use 10 nodes for 1 job (learner) or 1 core for 1 job (learner) while scheduling hundreds of jobs.

Everything is written such that the computation is maximally local. This means that is one of the jobs crashes, there is no problem and it will automatically schedule a new one and continue the calculation where it left off (because of Adaptive’s periodic saving functionality). Even if the central “job manager” dies, the jobs will continue to run (although no new jobs will be scheduled.)

Design goals

  1. Needs to be able to run on efficiently >30k cores

  2. Works seamlessly with the Adaptive package

  3. Minimal load on the file system

  4. Removes all boilerplate of working with a scheduler

    1. writes job script

    2. (re)submits job scripts

  5. Handles random crashes (or node evictions) with minimal data loss

  6. Preserves Python kernel and variables inside a job (in contrast to submitting jobs for every parameter)

  7. Separates the simulation definition code from the code that runs the simulation

  8. Maximizes computation locality, jobs continue to run when the main process dies

How does it work?

You create a file where you define a bunch of learners and corresponding fnames such that they can be imported, like:

# learners_file.py
import adaptive
from functools import partial

def h(x, pow, a):
    return a * x**pow

combos = adaptive.utils.named_product(
    pow=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9],
    a=[0.1, 0.5],
)  # returns list of dicts, cartesian product of all values

learners = [adaptive.Learner1D(partial(h, **combo),
            bounds=(-1, 1)) for combo in combos]
fnames = [f"data/{combo}" for combo in combos]

Then you start a process that creates and submits as many job-scripts as there are learners. Like:

import adaptive_scheduler

def goal(learner):
    return learner.npoints > 200

scheduler = adaptive_scheduler.scheduler.SLURM(cores=10)  # every learner get this many cores

run_manager = adaptive_scheduler.server_support.RunManager(
    scheduler=scheduler,
    learners_file="learners_file.py",
    goal=goal,
    log_interval=30,  #  write info such as npoints, cpu_usage, time, etc. to the job log file
    save_interval=300,  # save the data every 300 seconds
)
run_manager.start()

That’s it! You can run run_manager.info() which will display an interactive ipywidget that shows the amount of running, pending, and finished jobs, buttons to cancel your job, and other useful information.

Widget demo

But how does really it work?

The ~adaptive_scheduler.server_support.RunManager basically does the following. So, you need to create a learners_file.py that defines N learners and fnames (like in the section above). Then a “job manager” writes and submits max(N, max_simultaneous_jobs) job scripts but doesn’t know which learner it is going to run! This is the responsibility of the “database manager”, which keeps a database of job_id <--> learner. The job script starts a Python file run_learner.py in which the learner is run.

In a Jupyter notebook we can start the “job manager” and the “database manager”, and create the run_learner.py like:

import adaptive_scheduler
from adaptive_scheduler import server_support
from learners_file import learners, fnames

# create a new database that keeps track of job <-> learner
db_fname = "running.json"
url = server_support.get_allowed_url()  # get a url where we can run the database_manager
database_manager = server_support.DatabaseManager(url, db_fname, fnames)
database_manager.start()

# create a scheduler
scheduler = adaptive_scheduler.scheduler.PBS(
    cores=10,
    run_script="run_learner.py",
)

# create the Python script that runs a learner (run_learner.py)
server_support._make_default_run_script(
    url=url,
    learners_file="learners_file.py",
    save_interval=300,
    log_interval=30,
    goal=None,
    executor_type=scheduler.executor_type,
    run_script_fname=scheduler.run_script,
)

# create unique names for the jobs
n_jobs = len(learners)
job_names = [f"test-job-{i}" for i in range(n_jobs)]

job_manager = server_support.JobManager(
    job_names,
    database_manager,
    scheduler,
)
job_manager.start()

Then when the job have been running for a while you can check server_support.parse_log_files(job_names, database_manager, scheduler).

You don’t actually ever have to leave the Jupter notebook, take a look at the example notebook.

Jupyter notebook example

See example.ipynb.

Installation

WARNING: This is still the pre-alpha development stage.

Install the latest stable version from conda with (recommended)

conda install adaptive-scheduler

or from PyPI with

pip install adaptive_scheduler

or install master with

pip install -U https://github.com/basnijholt/adaptive-scheduler/archive/master.zip

or clone the repository and do a dev install (recommended for dev)

git clone git@github.com:basnijholt/adaptive-scheduler.git
cd adaptive-scheduler
pip install -e .

Development

In order to not pollute the history with the output of the notebooks, please setup the git filter by executing

python ipynb_filter.py

in the repository.

We also use pre-commit, so pip install pre_commit and run

pre-commit install

in the repository.

Limitations

Right now adaptive_scheduler is only working for SLURM and PBS, however only a class like adaptive_scheduler/scheduler.py would have to be implemented for another type of scheduler. Also there are no tests at all!

Project details


Release history Release notifications | RSS feed

This version

0.5.0

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

adaptive_scheduler-0.5.0.tar.gz (33.9 kB view details)

Uploaded Source

Built Distribution

adaptive_scheduler-0.5.0-py3-none-any.whl (34.0 kB view details)

Uploaded Python 3

File details

Details for the file adaptive_scheduler-0.5.0.tar.gz.

File metadata

  • Download URL: adaptive_scheduler-0.5.0.tar.gz
  • Upload date:
  • Size: 33.9 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/1.13.0 pkginfo/1.5.0.1 requests/2.22.0 setuptools/41.2.0 requests-toolbelt/0.9.1 tqdm/4.35.0 CPython/3.7.3

File hashes

Hashes for adaptive_scheduler-0.5.0.tar.gz
Algorithm Hash digest
SHA256 6ae43a7033ea84638ea7c9ba4a723f7572e6b205752eb5e32e8b96ff0dbc23cd
MD5 e6b4583a6534f78cb7bdadfa4f11dc99
BLAKE2b-256 6d167cce8b1dfe7c2c6180100f1e99bdbfb2f05235ea2b3f50aaeaf23a8ca48b

See more details on using hashes here.

File details

Details for the file adaptive_scheduler-0.5.0-py3-none-any.whl.

File metadata

  • Download URL: adaptive_scheduler-0.5.0-py3-none-any.whl
  • Upload date:
  • Size: 34.0 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/1.13.0 pkginfo/1.5.0.1 requests/2.22.0 setuptools/41.2.0 requests-toolbelt/0.9.1 tqdm/4.35.0 CPython/3.7.3

File hashes

Hashes for adaptive_scheduler-0.5.0-py3-none-any.whl
Algorithm Hash digest
SHA256 4ada96e7d489908940a36b0672020577e4b183e741b2e3f57d2ec764b73688b0
MD5 efbfb10dd4d953efb9d4f5b4fab7ae83
BLAKE2b-256 d43c074eab68facbcaf21c3988450d58783d7ebb66db70ef3ee31e80d772b184

See more details on using hashes here.

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page