Input and output files for the GloBI project.
The simulations themselves can be run from run from globi. This repository is where their files live.
- Open
inputs/partners/and click the partner you want. - The top of that page tells you which version is current.
- Open that version's folder and download the files — either one at a time with the download button, or the whole folder as a zip from the matching release.
Every version folder is complete on its own. You never need to combine folders, and you never need to install anything.
One exception: the building footprint files (buildings.geojson) are not
stored here. They run to a gigabyte each, which would make this repository
painful to download. Each version records their exact size and fingerprint and
says where to find them, so results stay traceable. They live in
globi-partners-data/data/partners/<Partner>/.
Each partner's inputs are stored as numbered folders:
inputs/partners/Lisbon/
├── README.md <- version history, start here
├── CURRENT.yml <- says which version is current
├── versions.yml <- status of every version
├── v001/ <- frozen
└── v002/ <- frozen
Two rules make this trustworthy:
Published versions are never edited. If an input needs to change, that is a
new version. The old one stays exactly as it was, so results produced from it
remain reproducible. globi-data check will tell you if a published version has
been altered.
Every version says whether it can change results. A version is either
simulation-affecting (a component library, a weather file, a component map) or
metadata-only (a typo in a README). Only the first kind marks existing results
as needing a re-run — which is what keeps
outputs/STATUS.md meaningful instead of permanently red.
Simulation results are large — roughly 11 GB of parquet files — so they stay in S3. What is versioned here is the record of where they are and what produced them: the input version, the code commits, the simulation run identifier, and a fingerprint for every result file.
That record is what lets you ask "these numbers came from where?" and get a real
answer, and it is what
outputs/STATUS.md uses to flag results whose inputs have
since changed.
Browse them under outputs/runs/, or download the actual files:
globi-data outputs download Ahmedabad/tmy/BAU --dest ./results| Path | What it holds |
|---|---|
inputs/partners/<Partner>/vNNN/ | One frozen, self-contained input bundle |
outputs/runs/<Partner>/<weather>/<Scenario>/vNNN/ | Where one run's results live, plus full provenance |
outputs/batches/<Batch>/vNNN/ | Same, for run families too numerous to list individually (MA's census tracts) |
outputs/STATUS.md | Which results are still up to date |
published.yml | Ledger of frozen directories |
docs/ | Schema reference and how-to guides |
uv sync # or: uv sync --extra s3 for the S3 commandsOptionally, uv run globi-data init-hooks installs a pre-commit check that
refuses edits to published versions. It is not enabled by default.
To work with the sibling repo, point at it once:
export GLOBI_PARTNERS_ROOT=../globi-partners-dataglobi-data inputs list # what exists
globi-data inputs show Lisbon # files and fingerprints
globi-data inputs diff Lisbon v001 v002 # what changed between versions
globi-data status # which results are stale
globi-data check # everything CI runs
globi-data inputs new Lisbon \
--from ../globi-partners-data/data/partners/Lisbon \
--summary "Corrected envelope U-values"There is also a browser-based route for adding a version that needs no software installed — see docs/HOW-TO-ADD-A-VERSION.md.
- docs/HOW-TO-DOWNLOAD-INPUTS.md — no CLI needed
- docs/HOW-TO-ADD-A-VERSION.md — both routes
- docs/SCHEMA.md — every manifest field
- CONTRIBUTING.md — the rules that keep this trustworthy