Battery segfault

[btdevine]

Describe the bug
When running the pvsamv1 module with a specific configuration of batteries, a segmentation fault occurs: 0x0000fffff488f64c in dispatch_automatic_front_of_meter_t::update_dispatch(unsigned long, unsigned long, unsigned long, unsigned long) () from /lib/libssc.so. This comes from dereferencing std::max_element on an empty revenueToPVChargeForecast on line 284 in shared/lib_battery_dispatch_automatic_fom.cpp. It appears that in our case, revenueToPVChargeForecast is actually always empty and pv_hours_on looks to be 0, but since the dereference only happens when pv_hours_on >= t_duration, we only see this segfault when t_duration == 0. The reason t_duration == 0 is because _Battery->energy_nominal() == 0, which is because capacity->qmax() == 0.

The solution to the immediate code-level problem is simple: just add the following not-empty check to the conditional: (!revenueToPVChargeForecast.empty() && pv_hours_on >= t_duration); I can open up a PR shortly with this fix. Whether it actually makes sense to have encountered this situation in the first place is something I'm less sure of.

To Reproduce
Run the attached file using PySAM 7.0.0.

battery-segfault-reproduction.zip

Expected behavior
Doesn't segfault of course, and any sanity checks on if those values (i.e. revenueToPVChargeForecast, pv_hours_on, and qmax being 0 even makes sense.

[brtietz]

@btdevine It looks like this is a case where the battery is aggressively cycled such that the capacity goes to 0. That's semi-realistic: certainly in the realm of possibility though I'd expect most asset owners would replace the battery before that happens. It's not necessarily appropriate here to throw, since prior simulation results could be valid; and it's not the dispatch code's job to flag and execute replacements. All of which is to say I think you've found and covered a reasonable edge case here.

[btdevine]

Awesome. Thanks for the input, it's appreciated as always.