forcingkit
Spatiotemporal forcing for computational Earth-system models: selects, regrids and serves model-ready time series with provenance.
forcingkit sits between operational and archive data providers (NOAA HRRR, NECOFS, NOAA OFS, HYCOM, NDBC, CO-OPS) and model codes such as Oceananigans.jl. It delivers a model's parent ocean on true z levels (/api/v1/obc) and its HRRR surface atmosphere on a regular grid (/api/v1/atmosphere), plus station observations for validation, as schema-versioned Zarr stores that record their sources.
forcingkit was named ecodata-cache until 2026-10-05; GitHub redirects the old repository URLs. The Python package is forcingkit (was ecodata_cache), and environment variables use the FORCINGKIT_ prefix; the old names are still read, with a warning, until the next release. Documentation: https://forcingkit.docs.lhzn.io, including the routes removed on the same date.
Goals
The primary goal of forcingkit is to provide clean, standardized ocean and atmospheric forcing boundaries for high-fidelity coastal hydrodynamic models. We achieve this by:
- Operating as an invisible, self-managing proxy service that orchestrates downloading and caching of remote data.
- Stripping away the quirks of individual forecasting nodes by harmonizing temporal alignment, grid structures, and variable naming conventions.
- Generating deterministic cache hashes to ensure simulation runs are 100% physically reproducible over time.
Features
- Decoupled System Architecture: The microservice guarantees reproducible datasets by deterministic hashing, providing standardized local representations of external APIs.
- Continuous Coupled Hindcasts: Support for 45-to-60-day continuous hindcasts by dynamically stitching historical and operational HYCOM experiments.
- Temporal Alignment: Automated CF-compliant hourly interpolation across heterogeneous upstream timestamps and grid frequencies.
Current Coverage
- Oceanic Forcing: NYOFS, NECOFS, DBOFS, HYCOM (Operational & Historical).
- Atmospheric Forcing: HRRR (3 km, hourly, 2014-07-30 to present), regridded to 0.03 degrees.
Roadmap
- Enhanced IOOS Coverage: Expanding our data fetchers to support more regional nodes across the West Coast (WCOFS) and Gulf of Mexico (NGOFS2).
- Improved Caching Policies: Implementing dynamic cache invalidation based on NOAA operational forecast updates to ensure realtime predictions stay synchronized.
- Variable Expansions: Providing native spatiotemporal transformations for wave spectra and biogeochemical tracers.
Architecture overview
The service exposes HTTP APIs (via FastAPI/Uvicorn) which:
- Deterministically hash bounding boxes and time windows to generate an automated local Zarr cache (
~/.cache/forcingkit). - Dispatch fetch operations via tiered fallback chains for high-availability. (e.g. DBOFS or NYOFS -> NECOFS -> HYCOM for the parent ocean).
- Standardize dimensions, bounds, floating-point precision, and timezone offsets, providing a direct ingestion path for downstream coupled engines.
Setup
uv sync
pre-commit install
# Development (single worker, run from the repository root):
uv run uvicorn service.forcingkit_serve.main:app --port 9598
# Service launcher (supports --host/--port/--workers/--reload):
uv run python service/run_server.py --host 0.0.0.0 --port 9598 --workers 4
Docker Environment
The Dockerfile defaults to ubuntu:24.04, which is multi-arch. This service is
CPU-only, so the default works unchanged on x86_64 and on arm64 edge hardware;
BASE_IMAGE exists for cases that need a different base.
# x86_64 and arm64 alike (default)
docker build -t forcingkit .
docker run --rm -p 9598:9598 forcingkit
On NVIDIA Jetson under JetPack 7 (L4T R39, Ubuntu 24.04), keep the default base.
An earlier revision of this file recommended
--build-arg BASE_IMAGE=nvcr.io/nvidia/l4t-base:r36.2.0; that was wrong on two
counts. The l4t-* image family was never published beyond r36.4.0
(JetPack 6.1), so there is no R39 equivalent to move to, and this service needs
no CUDA in the image regardless. Where a CUDA base genuinely is required, the
JetPack 7 path is the unified nvcr.io/nvidia/cuda:<ver>-*-ubuntu24.04 images,
which carry real arm64 manifests, combined with CDI device injection
(--device nvidia.com/gpu=all). Note that --gpus all is rejected on Tegra.
Licensing
This project is licensed under the Apache 2.0 License.
Metadata
Release files for forcingkit 0.1.0.post1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| forcingkit-0.1.0.post1.tar.gz | 1.1 MB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| forcingkit-0.1.0.post1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 1.2 MB
Release files / forcingkit-0.1.0.post1.tar.gz
| Download URL | forcingkit-0.1.0.post1.tar.gz |
|---|---|
| Size | 1.1 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
f68be7421b0d1aff68be138b0ad289e9542f4361f6698b89f9fdec609d31fd44
|
|
BLAKE2b-256 checksum How to use checksums |
053d8ebba7e5afee30c2b71a879d9d50638d03faad25465dc1810082e28b42c6
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 5, 2026.
Transparency logRelease files / forcingkit-0.1.0.post1-py3-none-any.whl
| Download URL | forcingkit-0.1.0.post1-py3-none-any.whl |
|---|---|
| Size | 74.7 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
19c24cfc62e3fde3aa0e5df760d08c52a0d4b60bc17757a4acb01ab294a7e27a
|
|
BLAKE2b-256 checksum How to use checksums |
4e6772edd01a6cade26137f7ec21bc63d1ab377a9e840e56065be5a25cf49f7c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 5, 2026.
Transparency log