Quickstart

Get SEALS running, then make it your own. This picks up where Installation leaves off — it assumes you have an activated environment with SEALS installed, either as the sealsmodel package from conda-forge or as a developer’s editable install from a clone. For what the model actually does, see Introduction.

1. Run it

Two run files ship with SEALS, in seals/seals/:

file what it runs
run_seals.py the standard pipeline: three scenarios, 2030 and 2050
run_seals_test.py the same pipeline pared down — baseline plus one BAU, one year, Rwanda

Start with the test. How you launch it depends on how you installed.

Installed from conda-forge. The run files live inside the installed package, and a run file is not launched from there: it is launched from a project folder of your own, which is also the folder your own work will grow in. Make one, with an input_template/ beside the run file:

mkdir -p ~/Files/seals/seals_first_run/input_template
cd ~/Files/seals/seals_first_run

Download standard_scenarios_test.csv into input_template/, and save this beside it as run_seals_test.py:

import hazelbean as hb
from seals.run_seals import run_project

if __name__ == '__main__':
    p = hb.ProjectFlow(project_name='seals_test', run_mode='check',
                       extra_dirs=['Files', 'seals', 'projects'])
    p.scenario_definitions_filename = 'standard_scenarios_test.csv'

    run_project(p)

The pipeline itself is imported from the package; extra_dirs tells ProjectFlow where to put the project directory, since there is no cloned repo for it to infer that from. Then:

conda activate <your_env>
python run_seals_test.py

Developer install. The clone already holds both files, so run the shipped one in place:

conda activate <your_env>
cd ~/Files/seals/seals/seals
python run_seals_test.py

Either way, required base data is downloaded at runtime from a public bucket; no credentials are needed for the default configuration.

2. Where the output goes

Not beside the run file, and never into a repo. ProjectFlow places the project directory under ~/Files/seals/projects/ — inferred from the clone’s location for the developer install, and named by extra_dirs for the conda-forge one:

~/Files/seals/projects/seals_test/
├── input/          your override copies only (the repo's input_template/ is read in place)
├── intermediate/   one folder per task
└── output/

Run the same command a second time and it finishes almost immediately — every task is behind an existence check, so completed work is skipped. That is the main thing ProjectFlow buys you: interrupt a long run, fix one input, re-run, and only what is missing recomputes.

3. Make it your own

Copy the run file into your own project repo as run_<project>.py and change the two lines in its __main__ block — that is the whole of the configuration. (If you installed from conda-forge, step 1 already put you in a project folder with exactly this shape.)

if __name__ == '__main__':
    p = hb.ProjectFlow(project_name='my_project', run_mode='check')
    p.scenario_definitions_filename = 'my_project_scenarios.csv'

    run_project(p)

run_mode controls how much prior work is reused: 'check' (the default) resumes in a stable project dir; 'full' timestamps a fresh one.

Put your scenarios CSV in an input_template/ directory beside the run file. It is tracked in git and ProjectFlow reads it there in place; a copy you place in the project’s untracked input/ shadows it. Make the project folder a git repository and ProjectFlow infers the project directory from it, so extra_dirs becomes optional. The columns are documented in Custom scenarios.

To run the same pipeline a second way — a smoke test, a different AOI — write a second run file that imports the first rather than copying it. run_seals_test.py is the worked example, and the pattern is explained in conventions.

Next