Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port functionality for reading observations from local files #111

Closed
hellkite500 opened this issue Mar 20, 2024 · 2 comments
Closed

Port functionality for reading observations from local files #111

hellkite500 opened this issue Mar 20, 2024 · 2 comments
Assignees

Comments

@hellkite500
Copy link
Member

hellkite500 commented Mar 20, 2024

Similar to #130, apply an observation hook to allow changing the default (hook implemented with eval nexus NWIS feature data loading) behavior which allows reading obs from local files.

Consider how to support plugins and provide user configurability for "supported plugins" and externally provided/registered plugins.

@aaraney
Copy link
Member

aaraney commented Aug 5, 2024

A few designs and design considerations:

For observation plugins to provide an appropriate time series for evaluation, we likely will need to provide the following as parameters:

  • point of interest id - I go back on forth if this should just be a simple str or a complex object. At this point, i've convinced myself that a str is the right way to go. I see avenues for exposing plugins that enable modifying the crosswalk that could support this in the future.
  • start and end time
  • interval between simulation values (e.g. 15 min)
    • Getting a bit into the weeds here, but we could also consider a simulation time scale and scale function for non-instantaneous variables (e.g. min-hourly temperature; time scale=1hr, scale function = min). I don't think we need this now, just want to design so this is a natural future addition.
  • simulated value unit; I think we are already taking a transitive dependency on pint through hydrotools, so we could use pint or something else. In any case, we should use a unit naming standard (e.g. udunits) to discourage passing around for example, Q.

Aside, calibrating non-streamflow values is not out of the question. Whatever interface we decide on should support that use case IMO.

def ngen_cal_model_observations(
    id: str | None,
    start_time: datetime,
    end_time: datetime,
    simulation_interval: pd.Timedelta,
) -> Series:

@aaraney
Copy link
Member

aaraney commented Aug 21, 2024

Now that #155 has been merged, while we don't directly implement this feature, there is nothing stopping someone from writing a plugin to do this. This was not explicitly added as a feature that we will maintain b.c. workflows could vary drastically. It feels like the perfect fit for a plugin.

@aaraney aaraney closed this as completed Aug 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants