This looks like a great way to translate from rainflow cycles to full equivalent cycles. Should the function in estimateCycleDamage() use the same formulation?

In lib_battery_dispatch_automatic_fom.cpp L344, the comment before calculating m_cycleCost says "Calculate assuming maximum depth of discharge (most conservative assumption)", which sounds like it is assuming an FEC count rather than rainflow. It is also more conservative.

The current estimated cycle cost is a function of the average qNeg per rainflow cycle, changing that to per FEC should increase the cost. For instance, 10% degradation over 50 rainflow cycles is smaller than 10% degradation over 10 FECs. So if we take the average per FEC instead, the cycle cost estimate will be larger.

If the three algorithms (automatic BTM, FOM and PV Smoothing though with a quick search, I don't actually see it being used after it's calculated) that use estimateCycleCost tend to go for a 80% "full" cycle per day, then the two values will be pretty similar.

I don't see a reason to switch, but curious about your perspective from how the dispatch algorithms use that value.

I see your point that the cycle cost function should correlate to how the algorithms are actually charging/discharging. Here's a quick summary:

FOM economic dispatch will attempt to charge and discharge at full power (L267), so the assumed DOD would depend on the duration of the battery. In this sense, it might be over-counting the cost of cycling, since the cycle penalty is applied per-timestep rather than per cycle (it also appears to be applied to both charging and discharging - see L192 - 236).

BTM price singals dispatch definitely uses the rainflow assumption - it will explicitly modify the cycle cost value by a rainflow-like metric during dispatch planning (L603).

PV smoothing does not consider the cost of cycling. It's dispatch decisions are based on current and forecast power, no units of $ are ever presented.

So that seems match the existing convention of using rainflow cycles for the cycle number in the cost function, and it shouldn't be changed. That said, I think that comment (L344) is misleading, since DOD isn't an input parameter. The cycle-life algorithm uses average DOD, and it looks like both the NMC and LMO/LTO should work out to an average as well.