This kind of functionality will be required for encapsulation of models that implement some set of pre-existing hydrofabric catchments. In this case, where a model implements a collection of hydrofabric catchments, we can refer to the model as a catchmentNetwork.
In this case, we may have I/O locations either for model output such as streamflow predictions or for model input for interbasin transfers or data assimilation.
To account for this, any model could include a list of pre-existing nexuses that it can provide output to or expects to receive input from.
As a near-term test-case, we could run an NHDPlusV2 discretization of the Sugar Creek domain as a single model. The obvious candidate for this would be WRF-Hydro-NWM. Another potential would be to use the T-Shirt model at the NHDPlusV2 discretization reporting flow to a the refactored discretization.
I open this issue to provoke discussion as much as anything. Not sure we actually want to tackle this now.
This kind of functionality will be required for encapsulation of models that implement some set of pre-existing hydrofabric catchments. In this case, where a model implements a collection of hydrofabric catchments, we can refer to the model as a catchmentNetwork.
In this case, we may have I/O locations either for model output such as streamflow predictions or for model input for interbasin transfers or data assimilation.
To account for this, any model could include a list of pre-existing nexuses that it can provide output to or expects to receive input from.
As a near-term test-case, we could run an NHDPlusV2 discretization of the Sugar Creek domain as a single model. The obvious candidate for this would be WRF-Hydro-NWM. Another potential would be to use the T-Shirt model at the NHDPlusV2 discretization reporting flow to a the refactored discretization.
I open this issue to provoke discussion as much as anything. Not sure we actually want to tackle this now.