Add a check to H2IntegrateModel to check timestep duration
We should have framework checks to ensure users don't get esoteric error messages when using models that might not support a given timestep.
Proposed solution
We could implement a check based on comparing the user-inputted technologies included in the plant_config.yaml against a list of known models that support given timesteps.
It could be as simple as must_be_hourly set to True or False for technologies, or something more complex that lists the available timesteps for a model.
I think it should be that latter one, in case we get models that work at e.g. 5, 15, 30 min intervals, and others that work just at 15, and 30, and we'd want a nice way to track what's supported across different models in a cohesive way.
We discussed having a list of models and their supported timesteps at the supported_models.py level.
That could be a great solution, though as I'm sitting here typing this, it seems that having this information live with the model definition itself, e.g. in the performance or cost classes themselves, might make more sense?
It could be an expected attribute on the classes.
Alternatives considered
Additional context
Add a check to H2IntegrateModel to check timestep duration
We should have framework checks to ensure users don't get esoteric error messages when using models that might not support a given timestep.
Proposed solution
We could implement a check based on comparing the user-inputted technologies included in the
plant_config.yamlagainst a list of known models that support given timesteps.It could be as simple as
must_be_hourlyset toTrueorFalsefor technologies, or something more complex that lists the available timesteps for a model.I think it should be that latter one, in case we get models that work at e.g. 5, 15, 30 min intervals, and others that work just at 15, and 30, and we'd want a nice way to track what's supported across different models in a cohesive way.
We discussed having a list of models and their supported timesteps at the
supported_models.pylevel.That could be a great solution, though as I'm sitting here typing this, it seems that having this information live with the model definition itself, e.g. in the performance or cost classes themselves, might make more sense?
It could be an expected attribute on the classes.
Alternatives considered
Additional context