You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a number of places ngen.calcan fail that are out of ngen.cal's control. Many of these issues are known just ngen.cal can't resolve the issue and continue with execution. ngen.cal doesn't report many of these issues and instead its often up the person conducting the evaluation to either debug the issue or reach out to one of the ngen.cal maintainers to find a resolution.
At a high level a calibration exercise looks like: ngen.cal runs ngen in a subprocess, evaluates its output (really t-route's output) vs. observations, adjusts parameters based on the evaluation score, writes a new ngenrealization config, and re-starts the process. The configuration, data, and software you likely would need for a calibration exercise are:
data
atmospheric forcing files (csv or netcdf)
hydrofabric (gpkg or geojson)
possibly usgs nudging files (netcdf)
software
ngen
t-route
python environment(s)
Exercise relevant bmi shared libraries or bmi python modules
possiblybmi module specific init_config file's dependent files (e.g. init_config file links to another file on disk)
There are many axes for things to go wrong. Some examples are, relative paths in realization config, setting output_root in realization config, or misconfiguring t-route's output to name a few. An ngen.cal plugin could cause ngen.cal to fail and provide helpful information to alleviate common pain points and provide a pathway for improving user interaction with the software.
The text was updated successfully, but these errors were encountered:
from __future__ importannotationsimporttypingfromngen.calimporthookimplfromhypy.nexusimportNexusimportpandasaspdiftyping.TYPE_CHECKING:
fromdatetimeimportdatetimefromngen.cal.metaimportJobMetaclassSaveOutput:
def__init__(self) ->None:
self.sim: pd.Series|None=Noneself.obs: pd.Series|None=Noneself.first_iteration: bool=True@hookimpl(wrapper=True)defngen_cal_model_observations(
self,
nexus: Nexus,
start_time: datetime,
end_time: datetime,
simulation_interval: pd.Timedelta,
) ->typing.Generator[None, pd.Series, pd.Series]:
# In short, all registered `ngen_cal_model_observations` hooks run# before `yield` and the results are sent as the result to `yield`# NOTE: DO NOT MODIFY `obs`obs=yieldifself.first_iterationandobsisNone:
self.first_iteration=FalsereturnNoneassertisinstance(obs, pd.Series), f"expected pd.Series, got {type(obs)!r}"self.obs=obsreturnobs@hookimpl(wrapper=True)defngen_cal_model_output(
self, id: str|None
) ->typing.Generator[None, pd.Series, pd.Series]:
# In short, all registered `ngen_cal_model_output` hooks run# before `yield` and the results are sent as the result to `yield`# NOTE: DO NOT MODIFY `sim`sim=yieldassertisinstance(sim, pd.Series), f"expected pd.Series, got {type(sim)!r}"self.sim=simreturnsim@hookimpldefngen_cal_model_iteration_finish(self, iteration: int, info: JobMeta) ->None:
ifself.simisNone:
returnNoneassert (
self.simisnotNone
), "make sure `ngen_cal_model_output` was called"assertself.obsisnotNone, "make sure `ngen_cal_model_observations` was called"# index: hourly datetime# columns: `obs_flow` and `sim_flow`; units m^3/sdf=pd.merge(self.sim, self.obs, left_index=True, right_index=True)
df.reset_index(names="time", inplace=True)
df.to_parquet(f"sim_obs_{iteration}.parquet")
There are a number of places
ngen.cal
can fail that are out ofngen.cal
's control. Many of these issues are known justngen.cal
can't resolve the issue and continue with execution.ngen.cal
doesn't report many of these issues and instead its often up the person conducting the evaluation to either debug the issue or reach out to one of thengen.cal
maintainers to find a resolution.At a high level a calibration exercise looks like:
ngen.cal
runsngen
in a subprocess, evaluates its output (reallyt-route
's output) vs. observations, adjusts parameters based on the evaluation score, writes a newngen
realization
config, and re-starts the process. The configuration, data, and software you likely would need for a calibration exercise are:data
csv
ornetcdf
)gpkg
orgeojson
)netcdf
)software
ngen
t-route
python
environment(s)bmi
shared libraries orbmi
python modulesconfiguration
ngen
realization
config (json
)t-route
config (yaml
)ngen.cal
config (yaml
)bmi
module specific (and likely catchment specific)init_config
files (any format)bmi
module specificinit_config
file's dependent files (e.g.init_config
file links to another file on disk)There are many axes for things to go wrong. Some examples are, relative paths in
realization
config, settingoutput_root
inrealization
config, or misconfiguringt-route
's output to name a few. Anngen.cal
plugin could causengen.cal
to fail and provide helpful information to alleviate common pain points and provide a pathway for improving user interaction with the software.The text was updated successfully, but these errors were encountered: