SCI should be dimensionless and abstract

[ElmarBorgmeier]

Right now, the definition of SCI states that:

"E = Energy consumed by software in kWh"
"I = Carbon emitted per kWh of energy, gCO2/kWh"

So "E * I" is measured in gCO2. This in turn means that the SCI itself becomes a gCO2-value. Don't go there. It's the road to hell.

We had these discussion at Syngenio, when we designed our Green Software Expertyzer (https://www.greensoftwaredesign.com/expertyzer/). Lessons learned:

1. The difference between measurements and ratings/scores is: measurements have units, ratings don't. Assigning a unit turns the SCI from a rating into a measurement.
2. If the SCI is measured in gCO2, everyone will say: "Oh, but that value is wrong. You use the wrong calculations." And they will have a point, since the only way to have a correct calculation in terms of gCO2 is to factor in hardware-efficiency, PUE etc. But we explicitly want to EXCLUDE these factors.

The way to go is: Make SCI an abstract score. One that adequately rates the software's carbon intensity, but does not claim to actually measure anything.

[atg-abhishek]

Thank you for sharing this @ElmarBorgmeier, we'll be discussing this at the upcoming SWG meeting.

[will-iamalpine]

Glad to see this thread. I had the same question to raise at tomorrow's SWG meeting!

[Sealjay]

Interesting! I’ll be trying my best to join, but visiting a partner tomorrow.

A counterpoint - does it matter if the calculation of the gCO2 is inaccurate, if we err on the side of caution, so long as we are still able to generate a score to bias is to action?

Put it another way, I like the fact that we factor in both PUE (and in location based emissions, the embodied emissions), because it provides versatility.

By versatility, I mean I can calculate an SCI score for my infrastructure - allowing me to right size it, from VMs to containers, to serverless code.

On the other hand, if the software boundary is limited to the running application (and the report will tell us this), the SCI score will be more tightly scoped to the running software.

I’m not tightly wedded to this idea, but if we replace the current calculation with something more abstract, it would be useful to have a score with the same utility for application to software defined infrastructure.

[Henry-WattTime]

Working Group:
-Henry: thinks real world units are important, real world emission reduction when the score changes
-How do we change the current score (emissions per unit) to a unitless rating.
--Baseline for each software type?
-Should view it as a relative score
--can see the relative intensity of different choice
--Rating of software, make improvements, can see the score improve
--Totals comparison are not
-Reinforces use of specification/score as a tool to help developers/users identify strategies to decrease emissions of their software
--currently useful for identifying strategies
-Not useful for comparing different software between different organizations (and may not yet be intended to do that).
-Underlying mechanics are the same?
--But might be different implementations/boundaries (test might be different, different software stack, different definitions of boundary, different measurements of intensity). Underlying data may also be different
--Model/ideal implementation is comparable, but actual current data availability might not be in a place to support that
--Current implementation does allow comparison within one software

WG: Keep units, until it matures, not in a place to make it unitless yet.

[atg-abhishek]

Do we keep the discussion thread open to visit later after v1 then @Henry-WattTime ?

[Henry-WattTime]

I think that seems reasonable.