Feature/gsye 891 - #1919
Conversation
…nimiseHeatpumpSwitchStrategy to be open for inheritance by the SorTES child
| CAPACITY_KWH = 25 | ||
| COP_HEAT_SOURCE = 1 | ||
| COP_CONDENSER = 1 | ||
| COP_EVAPORATOR = 1 # to be updated |
There was a problem hiding this comment.
We need to ask for this again
There was a problem hiding this comment.
Indeed this needs to be clarified
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #1919 +/- ##
==========================================
+ Coverage 71.12% 71.69% +0.57%
==========================================
Files 149 150 +1
Lines 14309 14644 +335
Branches 1892 1908 +16
==========================================
+ Hits 10177 10499 +322
- Misses 3593 3601 +8
- Partials 539 544 +5 🚀 New features to boost your workflow:
|
| self._average_trade_rate.get_value(time_slot) | ||
| < GlobalConfig.market_maker_rate[time_slot] |
There was a problem hiding this comment.
As we discussed also privately, this can be optimized to look at the future values, similar to this (pseydocode):
| self._average_trade_rate.get_value(time_slot) | |
| < GlobalConfig.market_maker_rate[time_slot] | |
| all(self._average_trade_rate.get_value(t) < GlobalConfig.market_maker_rate[t] for t in [ | |
| time_slot.add(interval * i) | |
| for i in range(0, time_horizon_mins / slot_length_mins) | |
| if time_slot.add(interval * i) <= interval + time_horizon_mins | |
| ]) |
…BEFORE_SWITCH_ALLOWED rule
…energy_affordable
| "COP", | ||
| "heat demand [kJ]", | ||
| "SOC", | ||
| "total_charged_energy_kWh", |
There was a problem hiding this comment.
No need for now since we do not have KPIs for this, but it would make sense to also separate the electricity consumption (traded energy) in 2 components: the electricity consumption of the condenser / evaporator, and the consumption required to produce the heat. Nothing to do of course, just for the sake of the argument.
There was a problem hiding this comment.
Good idea. Let me even do it now, because I foresee that we have to investigate the results a bit more (already saw some unusual numbers in the KELVIN results).
| self._get_tank_soc(time_slot) >= self.MAX_SOC_TOLERANCE | ||
| and self._current_state == HeatPumpChargingState.CHARGE |
There was a problem hiding this comment.
Ok, now I see in detail what you meant in our discussion. Essentially if the SOC has overshoot to a value greater than the MAX_SOC_TOLERANCE, and the state changed to DISCHARGE for some reason, then the state would not switch to MAINTAIN_SOC. For SorTES where we do not care about interrupting the charging / discharging state I think this is ok, however for FractLES I think that the former implementation is valid. The storage should not switch to MAINTAIN_SOC in this case, it should just discharge, unless I misunderstood something.
There was a problem hiding this comment.
I spend some time to remember why I added these changes here. Unfortunately, I am not sure, but I think we saw a case, when the status was changed to DISCHARGE before, but the SOC was still higher than the MAX value. This lead this section to change the status again to MAINTAIN_SOC and the storage was never discharged.
How about I move this implementation to SorTesTankMinimiseSwitchStrategy and leave the original implementation here for the fractLES?
| self._update_soc(time_slot, -discharge_energy_kWh) | ||
| self._state.update_total_charged_energy_kWh(-discharge_energy_kWh) | ||
|
|
||
| def _update_soc(self, time_slot: DateTime, heat_energy_kWh: float): |
There was a problem hiding this comment.
Nit, but if the heat_energy_kWh can be negative, please leave a comment to indicate so. Thanks!
…onality in the MinimizeSwitchStrategies
Reason for the proposed changes
Please describe what we want to achieve and why.
Proposed changes
INTEGRATION_TESTS_BRANCH=master
GSY_FRAMEWORK_BRANCH=master
SCM_ENGINE_BRANCH=master