add tolerance to grid charging check to allow for floating point issues#620
Conversation
|
Still failing for case 3 of attached file, hangs at 66.6% Case 3 of attached file - grid target 0 and time series critical load hangs as above image with these changes... |
| if (!m_BatteryPower->canGridCharge && P_battery_ac < -tolerance) { | ||
| if ((fabs(P_grid_ac - P_grid_to_load_ac) > tolerance) && (-P_grid_ac > P_grid_to_load_ac)) { | ||
| if ((fabs(P_grid_ac - P_grid_to_load_ac) > tolerance) && (-P_grid_ac > P_grid_to_load_ac + tolerance)) { | ||
| P_battery_ac = P_pv_ac - P_pv_to_grid_ac - P_pv_to_load_ac - P_system_loss_ac; |
There was a problem hiding this comment.
Fixes peak shaving stack overflow but not the grid target of zero with time series resilency calculations per case 3 in the attached sam project file in the comments
There was a problem hiding this comment.
Case three has different problems depending on which branch you're on. On connect_outage_vars... it gets into the stack overflow because the unmet critical load is drawn from the grid. On dispatch_for_grid_outage it fails because the resiliency runner isn't properly updating the battery power flow variables as it steps forward through the hypothetical outage.
I'm inclined to fix the problem on dispatch_for_grid_outage (since that branch has already fixed the first problem) but what do we do about #618 in that case?
A floating point error (~1e-15) was causing a stack overflow in the powerflow code. Add a tolerance to fix the issue.
Alternative fix would be to set gen to zero if it's smaller than some tolerance. I think "tolerance" in the powerflow code is too high for this approach, I'd want 1e-7 or smaller for this approach.
Test with
Test_Case.zip