You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
assertself.min_soc<=self.soc(), "Minimum SoC can not be smaller than the current SoC"
This is despite the initialization being valid, and the supplied values for capacity, charge level and min_soc being validated by me beforehand. I did not update min_soc during runtime. I suspected the error might be because of floating point loss, and by inserting some print statements before the assertion, I noticed it seems I was right:
The first time the battery is updated everything is fine, but the battery will be fully discharged. On the next call then, because of floating point imprecision, the charge level was set correctly, but the calculated soc is slightly below min_soc.
It's not a pressing issue for me, but in general, it surely would be nice if the simulation did not crash despite the user-provided parameters for the battery being valid.
One could use the built-in decimal module to perform exact arithmetic operations.
Alternatively, the assertion could be rewritten using math.isclose. That way floats will suffice - it might be worth thinking whether this is needed in any of the other comparisons in the update code.
The text was updated successfully, but these errors were encountered:
I assume the purpose of that assertion is to check against invalid changes made to min_soc during runtime / between updates? (The update method itself should always leave the battery in a valid state ☺️)
Another option then would be to remove the assertion from the update code, and transform min_soc into a property with a proper setter that performs this check and throws a ValueException if necessary. It would then also be clearer exactly when an invalid set to min_soc happened - not just when the next update step is performed.
Actually, I'd argue in favor of making min_soc a settable-property even if another solution is applied.
I was using randomly assigned values for initializing a
SimpleBattery
, and I noticed theupdate
method sporadically failed at this line:vessim/vessim/storage.py
Line 57 in e7fe48e
This is despite the initialization being valid, and the supplied values for capacity, charge level and min_soc being validated by me beforehand. I did not update min_soc during runtime. I suspected the error might be because of floating point loss, and by inserting some print statements before the assertion, I noticed it seems I was right:
The first time the battery is updated everything is fine, but the battery will be fully discharged. On the next call then, because of floating point imprecision, the charge level was set correctly, but the calculated soc is slightly below min_soc.
It's not a pressing issue for me, but in general, it surely would be nice if the simulation did not crash despite the user-provided parameters for the battery being valid.
decimal
module to perform exact arithmetic operations.math.isclose
. That way floats will suffice - it might be worth thinking whether this is needed in any of the other comparisons in theupdate
code.The text was updated successfully, but these errors were encountered: