How is "battery number of cycles" computed?

Hi everyone,

I was wondering how is the "battery number of cycles" computed in practice?
According to the documentation, it is : "The running count of how many charge/discharge cycles have elapsed.", which seems relatively logical.

However, when looking at the time series, its seems that sometimes the cycle number is increase by steps of 3 (see figure attached) although only one charging/discharging cycle appears on the battery SoC. Note that I have 15-min resolution power profiles.

Did I miss something or is there an issue somewhere?

Thank you for your support!

Best,
Nelson

Hi Paul, 

Thank you for this detailed feedback.

I now realize that I didn't get the principle of rainflow counting quite well. After some more reading (such as that  one ), things got much clearer.

However by looking more closely at this example, I've noticed a strange behavior of the battery power profile which seems to affect energy and efficiency data. Your feedback might be really helpful on this point as well.

In this example, a system with a PV production (15-min), a load consumption (15-min) and a 100kWh battery is modeled. The dispatch controller of the battery is an "automated grid power target" fixed at 0kW (ie. the battery is used for self-consumption increase). The battery is allowed to charge from the PV only and no ancillary equipment losses were configured.

The figure below illustrates the different power flows (grid, battery, load and PV) as well as the battery state of charge. A zoom was made on a series of 4 consecutive days without PV overproduction. In can be observe here that the battery correctly stay discharge at its minimum allowed SoC (10%). However, the battery power (in orange) in non-null (~1.27kW).


If we now look at the battery annual energy charged/discharged, we can observe a huge discrepancy between the charge and discharge energy (~7000kWh). This is certainly linked to the constant discharge power observed above.


The same observation can be made on the monthly data, where the energy to load from battery is much higher than the one to battery from PV.


Finally, it seems to affect the conversion and roundtrip efficiency too. Indeed, they seem to saturate at 100% since the energy delivered by the battery is much higher than the supplied.


As asked, you I've attached the .sam file of the project. If you need any additional information, please let me know.
Thanks for the support.

Best,
Nelson

Hi Paul,

Once again, thank you for this great support.
Indeed, this issue seems to be fixed in in SAM Beta 2020.1.17. The data I get with this version are relevant.

Best,
Nelson

Hi Paul,

For the sake of completeness and to inform other user, it may be important to notice that this issue on SAM 2018.11.11 impacts the electricity bill and thus distorts the financial assessment of a system with a battery!

Indeed, this offset observed on the battery impact the time series "Electricity to/from grid peak (year 1 hourly)(kW)" which is used for the utility bill calculation. Hopefully, this issue is solved in the SAM Beta 2020.1.17.

To illustrate my point, here is just an illustration of SAM 2018.11.11, with an empty battery and square pattern load profile. It can be seen that the "power" falsely delivered by the battery reduces the grid power.


Same illustration but now with SAM Beta 2020.1.17, where the battery correctly delivers no power and the grid power equals the load power.


Best,
Nelson