Exact MultiMet HRES/GraphCast workflow for adding a new basin

[akshusuba]

We are evaluating the released OpenHydroNet FloodHub checkpoint on a new basin, USGS 11447650 (Sacramento River at Freeport), using the exact gs://caravan-multimet/v1.1 input semantics. The basin is not in the released MultiMet stores, so we are trying to determine whether a checkpoint-faithful extension is reproducible.

The paper and public Caravan notebook clearly document the processed products, UTC daily/lead conventions, and broad source characteristics. We could not find the generation/retrieval workflow or enough source-version detail to reproduce the HRES and GraphCast values exactly.

Could you share, or point us to, the following?

1. The pinned generation code/environment used for MultiMet v1.1, including polygon aggregation, missing-pixel handling, unit conversion, and daily lead aggregation.
2. For IFS HRES: the exact ECMWF archive/dataset, request fields (class, stream, type, expver, param, grid), issue-time/step selection, accumulation-reset handling, and source vintage.
3. For GraphCast: access to the exact HRES-initialized forecasts used in the release, or the yearly model checkpoints/configuration and preprocessing needed to regenerate them. The paper notes that this differs from the public ERA5-initialized GraphCast workflow and that each year's forecasts were generated using a GraphCast model trained only through that year.
4. Any hashes/manifests or control-basin fixtures that can establish equivalence to the released HRES and GraphCast Zarr stores.
5. If those artifacts cannot be released, would the maintainers be willing to run the original MultiMet aggregation pipeline for one supplied basin polygon and return the resulting series?

We do not want to substitute a different public GraphCast model or HRES archive and represent it as checkpoint-equivalent. We are happy to contribute a documented extension or validation fixture if there is an approved path.

[akshusuba]

One additional clarification about the scope of our request:

Our target evaluation period is 2024-01-01 through 2025-12-31. We recognize that the released MultiMet v1.1 GraphCast series ends on 2023-12-21 and HRES ends on 2024-09-30. Therefore, adding the Freeport basin to the existing spatial aggregation alone would not provide complete coverage for the experiment.

Could you also clarify:

1. Whether a MultiMet temporal refresh covering 2024–2025 is planned.
2. Whether USGS 11447650 must first be accepted as a formal Caravan community extension before it can be considered for MultiMet.
3. What canonical basin identifier and catchment definition should be used.

We currently have a full-resolution NLDI delineation, but treat it as provisional because Freeport is affected by reservoir regulation, diversions, the Yolo Bypass, and tidal conditions. We would not present that polygon as the authoritative hydrological domain without further review.

local_11447650 is only our internal experimental identifier; we would use whatever canonical identifier is assigned by Caravan/MultiMet.

[akshusuba]

Thank you for independently checking the paper, Zenodo records, and public notebooks. Your confirmation of the 00:00 issue time and six-hour-to-daily lead aggregation is especially helpful.
I agree that the remaining HRES request details, GraphCast checkpoint/configuration, and equivalence artifacts require guidance from @kratzert or @guyshalev. The checksum/control-fixture suggestion would provide a practical way to validate independent preprocessing if the full pipeline cannot be released.
I will continue treating the Freeport reconstruction as unverified and will not describe public substitutes as MultiMet-equivalent without that evidence. I can provide our provisional Freeport polygon and control-basin equivalence fixture if they would help evaluate an extension or validation path.

[kratzert]

I am on vacation for the next two weeks and won't have time for an in-depth answer. A few quick notes though:

• there are currently no updates in progress and I don't have the bandwidth to add new basins upon request. Eventually at some point in the future, we might do an update (or new release), but probably then switching to the data that we currently use at the flood forecasting team. Graphcast is rather oudated for example.
• Yes, we used GraphCast initialized with HRES, the very same data we use in the ooerational setting of Googles Flood Forecasting model. The raw data of that model is not released by GDM, IIRC, but we were allowed to release this derived product.
• For HRES, the data comes from the IFS control member. However, sonce ECMWF continuously updates their forecast archive by reforcasting Monday and Thursday also the the same calanendar days of the past 20 years, it will indeed be impossible to have the exact same forecast archive that we downloaded at some point. Since then, we simply extend this archive by adding the real time forecasts from the ensemble member.