as part of my master’s thesis i’m currently developing a model for the unit commitment of underground thermal energy storages. Since calculation time can be in issue, i want to implement the option to switch between different resolutions (e.g. 1hr and 3 hr timesteps). I used a variable tau representing the given resolution (1hr->tau=1, 3hr->tau=3) to adjust the input accordingly.
But when it comes to the different components, i can’t quite figure out if i need to adjust them or not. To be precise: Are the parameters concerning the loss-rate of generic storages defined as per-hour-values or per-timestep (for example every 3 hours)? And what about the minimal up- and downtimes of nonconvex flows? Is there a consistency about it throughout all parameters?
thanks in advance and kind regards
thanks for reaching out. Unluckily, it is not consistent, yet:
- For the generic storage, the losses are given per hour. (The documentation says “time unit” but the time unit is currently fixed to be hours.)
- For the minimal up- and downtimes, just the time steps are counted. It was implemented this way because it is hard to comprehend what happens if the time resolution and the given limit for up-/ or downtime cannot be aligned. (And it was not important enough to be address that difficulty.) If you explain a way to improve that, I’m pretty sure it will be implemented.
thanks for the quick response, that was exactly what i needed! I ealready assumed that the variables consider different time increments, but i wasn’t quite able to get the answer from the source code.
I think a quick fix to this would be a short information about the considered time increment in the description of the component? And maybe a short explanation about time management in the documentation.
I improved the documentation in oemof.solph.components.GenericStorage and in oemof.solph.options.NonConvex. Now, it should be clear that hours and time steps are used, respectively. For now, there will be no additional explanation about time at a central location, but I added the inconsistency to the topics of the next dev meeting.