-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sam 1869 battery adjust losses #1241
Conversation
…attery_adjust_losses
…attery_adjust_losses
…attery_adjust_losses
…ed up to cmod battery
…attery_adjust_losses
…onvention (PV only applies to PV when AC connected
…eption (still doesn't relay losses properly
…ill has a problem with a giant resistor that doesn't exist
…vailability losses
shared/lib_battery_dispatch.cpp
Outdated
@@ -394,17 +399,22 @@ bool dispatch_t::restrict_power(double& I) | |||
} | |||
else | |||
{ | |||
if (std::abs(powerBattery) > m_batteryPower->powerBatteryDischargeMaxDC * (1 + low_tolerance)) | |||
double max_discharge_dc = (1 - m_batteryPower->adjustLosses) * m_batteryPower->powerBatteryDischargeMaxDC; | |||
double max_discharge_ac = (1 - m_batteryPower->adjustLosses) * m_batteryPower->powerBatteryDischargeMaxAC; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sprinkling (1 - m_batteryPower->adjustLosses)
around everywhere seems like a potentially leaky way to handle this loss adjustment. I think this final post-loss max value should be concretely defined somewhere, and then used where appropriate...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call - making those variables private revealed several locations I'd missed. Addressed in latest push.
… in each individual location
…attery_adjust_losses
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm getting a simulation error now with hourly simulations when the time series battery availability losses are in Hourly mode. This is for both PV-Battery and PVWatts-Battery configurations.
exec fail(battery): failed to setup battery adjustment factors: Time series availability losses must have the same time step as the simulation time step unless losses are daily, weekly, monthly, annual, or single value.
Simulation pvsamv1 failed :exec fail(battery): failed to setup battery adjustment factors: Time series availability losses must have the same time step as the simulation time step unless losses are daily, weekly, monthly, annual, or single value.
monthly_grid_to_batt not assigned
Simulation singleowner failed :monthly_grid_to_batt not assigned
Ugh, thanks for catching that. Fortunately it was an easy fix! |
Hourly time series losses are working now for PV-Battery (I tested FOM and BTM), but I'm still getting the simulation error for PVWatts-Battery. |
Thanks for your patience while testing this. This should be fixed - it required changes to both ssc and SAM (lk to pass the right analysis period). |
PVWatts-Battery is working correctly now. Thanks for the fixes! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!!
Add adjust/availability losses to batteries.
These losses affect both power and capacity, such that when a loss kicks in the battery has x% of each at that time. We assume that the cells have to be discharged to work on them safely, so x% is removed from state of charge and needs to be returned once the loss is over.
Note that this can lead to SOC less than the minimum SOC on the dispatch page. For example, a battery with a 10% minimum SOC and a 50% availability loss could go down to 5%.
Pairs with SAM pull request: NREL/SAM#1902
Closes NREL/SAM#1869