Closed xaviernogueira closed 1 year ago
@xaviernogueira, this seems like a reasonable approach. Thanks for detailing the background and proposing a good solution.
Final solution
Converting the static variables we need to update to state variables was somewhat problematic as then the program attempts to calculate the static variables using non-existent process functions. Instead there is now an optional updateable_static_variables
argument for Model.__init__
. Some other small changes make the described desired behavior possible, without updating the variable type as a whole to "state".
Result of a call about linking with
Clearwater-riverine
w/ @sjordan29 and @jrutyna 11/6/2023.Issue:
Clearwater-modules
alone may need to be updated between timesteps when linked with other models.xarray.Dataset
. That said, it makes it awkward to allow updates between timesteps, as it could result in time axes of different lengths IF we wanted to preserve some efficiency, or it forces us to give up on that efficiency entirely resulting in a significant memory penalty.Proposed Solution: Upon initialization of a module, we can add a new
__init__
argumentconvert_static_to_state
where names of static variables can optionally be provided via a list. Any static variable in the list will be re-registered as a state variable, therefore it will be given a time axis, and be allowed to update between timesteps. Doing it this way allows us to only convert the variables we need to interact with, preserving efficiency where we can.URGENT PRIORITY so Sarah and Jason can proceed.
Thoughts @aufdenkampe