weather-model-data-fetching

# Weather Model Data Fetching

Overview

Fetch numerical weather prediction data without treating a multi-gigabyte GRIB2

file as one indivisible download. Prefer an existing project adapter or Herbie;

use direct object-store byte ranges only when the supported path cannot express

the request.

This skill covers transport, inventory selection, caching, and verification. It

does not interpret the forecast or decide whether a model is meteorologically

appropriate.

When to Use This Skill

- A task needs GFS, GEFS, HRRR, RAP, NAM, IFS, or similar model output.

- Data lives in a public AWS S3 bucket, NOMADS, or a public cloud mirror.

- The input is GRIB2 and only selected variables or levels are needed.

- A point, sounding, time series, map, or batch job needs a reliable fetch path.

- A download is missing, partial, unexpectedly large, slow, or hard to resume.

Do not activate this skill for ordinary weather-forecast questions that do not

require model files.

Define the Request First

Resolve these values before downloading:

- model and product;

- initialization cycle in UTC;

- forecast hour and therefore valid time (`valid = initialization + lead`);

- ensemble member when applicable;

- variables, vertical levels, and surface fields;

- point, region, or full-grid output;

- cache location and when the downloaded data may be deleted.

Confirm that the cycle is complete, the forecast hour exists for that cycle,

and the requested location is inside the model domain. A recent `404` often

means the cycle is not published yet; step back to a completed cycle instead of

retrying indefinitely.

Choose the Smallest Retrieval Route

1. Reuse the project's existing fetch/cache abstraction when it already handles

the model.

2. Use Herbie for a supported GRIB2 model. It discovers AWS, NOMADS, Google,

Azure, and other configured sources and understands their key layouts.

3. Use a provider-native point or Zarr endpoint when the task needs a tiny

spatial slice from many times or members.

4. Use direct S3 or HTTPS object access when the key is known and no suitable

adapter exists.

Do not recursively list a large public bucket to discover one run. Build the

documented prefix for the model, cycle, product, forecast hour, and member, then

probe that exact object and its inventory.

Use an explicit provider priority and record the provider that succeeded. A

fallback must refer to the same model run, product, member, and forecast hour;

never silently substitute a different forecast.

Subset GRIB2 by Inventory

GRIB2 files contain consecutive messages. A companion inventory such as

`.idx`, `.grib2.idx`, or `.grb2.inv` records each message's starting byte.

1. Fetch the small inventory first.

2. Inspect its actual rows before writing a regex.

3. Select exact variables, levels, and forecast-step records.

4. Set each selected message's end byte to one less than the next message's

start; request the final selected message through EOF when no end is known.

5. Coalesce adjacent selected messages into one range.

6. Issue one `Range: bytes=START-END` request per range. S3 does not support

multiple ranges in one `GetObject` request.

7. Require `206 Partial Content` and a matching `Content-Range`. If a server

answers `200`, do not append the whole object as though it were a fragment.

8. Pin the object's length and identity (`ETag` and/or `Last-Modified`) while

downloading. Discard fragments if the object changes.

9. Assemble into a temporary file, verify it with a GRIB decoder, then rename

atomically into the cache.

A GRIB message contains one field over its grid. Message-range subsetting saves

variables and levels, not geography. A point request still downloads the full

grid for every selected message unless the provider offers a point, regional,

Zarr, or other chunked endpoint.

Herbie Example

Use the current `search` argument; `searchString` is deprecated. Start from the

inventory, fail on an empty match, and keep