Document how parameter sets will hang-off hygeo objects about hygeo

[dblodgett-usgs]

That's it.

[dblodgett-usgs]

There are basically three ways that a set of catchment parameters can be associated to a catchment.

1. associate directly to a catchment-area id
2. associate to an inflow nexus and outflow nexus
3. associate to a set of inflow nexuses and set of outflow nexuses.

The first and second are worth pursuing near term. The third is an interesting concept but might be more complexity than its worth.

For flowpaths, hydrodynamic models will either be catchment oriented or need a nexus-based coupling.

1. associate directly to a flowpath id
2. associate to one or more hydrologic locations that realize nexuses.

[dblodgett-usgs]

Looking at the GIUH Parameters we have so far, we have:

Which is keyed off NHDPlusV2 catchment ID.

I think what we want is a json structure like:

{
  "model-id": {
    "catchment": "cat-id",
    "type": "giuh",
    "CDF": {
      "CumulativeFreq": [1, 2, 3],
      "Time": [1, 2, 3]
    },
    "minHydro": {
      "Runoff": [1, 2, 3],
      "Time": [1, 2, 3]
    },
    "hr_Hydro": {
      "Runoff": [1, 2, 3],
      "Time": [1, 2, 3]
    }
  }
}

or:

{
  "model-id": {
    "inflow-nexus": "nex-id",
    "outflow-nexus": "nex-id",
    "type": "giuh",
    "CDF": {
      "CumulativeFreq": [1, 2, 3],
      "Time": [1, 2, 3]
    },
    "minHydro": {
      "Runoff": [1, 2, 3],
      "Time": [1, 2, 3]
    },
    "hr_Hydro": {
      "Runoff": [1, 2, 3],
      "Time": [1, 2, 3]
    }
  }
}

The first implies an inflow and outflow nexus, so really the second is all-encompassing.

[hellkite500]

Would something like this be what you are looking for?
https://github.com/NOAA-OWP/ngen/blob/master/data/example_realization_config.json

[christophertubbs]

Just as a heads up: the config is going to change just a bit in order in incorporate stuff like the giuh parameters within the model definition; it just makes it easier to pass as one big chunk rather than having to isolate "Ok, I have the basic model parameters and the forcing config, now to generate a giuh config and pass that in as well".

TL;DR: the giuh object is going to float up under "tshirt" in the config, rather than being on the same level.

[dblodgett-usgs]

Definitions

model domain: A subset of the reference domain.

• Specified as a catchment aggregate using an inflow nexus and outflow nexus.
• A model domain uses a consistent catchment area formulation for all contained catchments.
• A model domain is a catchment network with internal i/o hydrologic locations that link to reference domain i/o hydrologic locations.

reference domain: A continental-scale hydrofabric

• A common hydrography catchment / nexus network for i/o locations and forcing / coupling interface standardization.

catchment: see HY_Features

catchment aggregate: see HY_Features

• In this context, an aggregate of reference domain catchments

inflow nexus: see HY_Features

outflow nexus: see HY_Features

catchment network: see HY_Features

hydrologic location: see HY_Features

Model Domain Parameters

For a given model domain, a parameter configuration file declares an inflow nexus, outflow nexus, default parameters and formulation.

For the model domain, mappings from model i/o hydrologic locations to reference domain i/o hydrologic locations.

For the model domain, a list of catchments area parameter objects corresponding to the model domain formulation must be included. The parameter objects can be empty if default parameters are to be used. A catchment ID is required for all catchments in the model domain.

[dblodgett-usgs]

After discussion today, this basic layout for parameters seemed sensible. Will work this up over in the ngen repo and propose some follow on work in Trello.