search

NOAA-OWP / ngen

Next Generation Water Modeling Engine and Framework Prototype
Other
83 stars 62 forks source link

Implement a simulation clock type #858

Open program-- opened 1 month ago

program-- commented 1 month ago

Currently, across Data Providers and BMI instances, we're primarily using C time constructs.

Example https://github.com/NOAA-OWP/ngen/blob/9fc3182f908efbf58a88b019df516932f5e85ec2/include/forcing/DataProvider.hpp#L47-L54 https://github.com/NOAA-OWP/ngen/blob/9fc3182f908efbf58a88b019df516932f5e85ec2/include/simulation_time/Simulation_Time.hpp#L171-L173

However, in some recent changes, we've started using std::chrono types.

Example https://github.com/NOAA-OWP/ngen/blob/9fc3182f908efbf58a88b019df516932f5e85ec2/include/forcing/ForcingsEngineDataProvider.hpp#L208-L214

One of the current issues with std::chrono clock types is that they either represent Unix time or relative time (though not clearly), and we have a use-case for representing both. A potential solution for this is to define our own clock type^1, simulation_clock, as discussed here.

A benefit is that this would allow us to use std::chrono types while maintaining control of the simulation ticks however we see fit.

program-- commented 1 week ago

An attempt at fleshing out an interface similar to the discussed one in the above linked comment. However, unlike conventional chrono clocks, this implementation is a controlled clock, where simulation_clock::now() doesn't change unless simulation_clock::tick(...) is called.

https://github.com/program--/ngen/blob/8c21f8e3540942468b8126a01ce99da33c61e7fb/include/simulation_time/simulation_clock.hpp#L9-L123

PhilMiller commented 1 week ago

The implementation you've drafted looks pretty good to me. May as well post it in a PR, and we can potentially start using it in the Forcings Engine and Coastal Formulation code that we're writing fresh.