[Feature] If time-index is shorter than given time-series don't error (Time Windows)

[dylanjm]

Motivation

Currently, we raise a ValueError if the time-index doesn't match the time-series profiles given by the user. I think there needs to be some flexibility. I think we may have talked about this in a design meeting @caleb-sitton-inl and @GabrielSoto-INL about handling this different ways. We can use this issue to track windowing.

For example, today I was writing a dove script that loaded up a full 8760. I used that as my max_capacity_profiles and was initially dispatching on the full-year. Then I wanted to take a look at a 120 hour time window. I went and changed the time_index parameter on my system and got an error. It would be nice to quickly change time-horizon without having to filter my data down.

Design

I modified the verify_time_series method. Not sure if this is the best way to handle it, but it gets the job done:

diff --git a/src/dove/core/system.py b/src/dove/core/system.py
index b511ed5..59a9bb5 100644
--- a/src/dove/core/system.py
+++ b/src/dove/core/system.py
@@ -160,10 +160,13 @@ class System:
         # Check that time index length matches component capacity profiles
         for comp in self.components:
             if len(comp.max_capacity_profile) != len(self.time_index):
-                raise ValueError(
-                    f"Component '{comp.name}' has a capacity profile length "
-                    "that does not match the time index length!"
-                )
+                if len(comp.max_capacity_profile) > len(self.time_index):
+                    comp.max_capacity_profile = comp.max_capacity_profile[self.time_index]
+                else:
+                    raise ValueError(
+                        f"Component '{comp.name}' has a capacity profile length "
+                        "that does not match the time index length!"
+                    )

Impact

Quicker exploration of different dispatch windows.

[caleb-sitton-inl]

@dylanjm We had also discussed changing the default time_index for systems to be the same length as the time series inputs to the components (which currently must all be the same length). I believe the idea of having an optional time_index that specifies a range of timesteps over which to dispatch was also mentioned. I think most solutions would result in some functionality limitations, would force the user to be more explicit in their problem specification, or would limit our freedom to prevent unintended behavior. It seems convenient to package whatever additional time_index changes we do decide to make with the change discussed here. Would deciding on a broader vision for time_index be a good next step?

[dylanjm]

Here is my attempt to make pretty diagrams like @GabrielSoto-INL. Here is kind of what I am envisioning for handling time-series:

There are two ways to go about structuring time-series. If we just assume no window and rolling dispatching, then we can handle changing the window length and placement easily through the time-index parameter.