Green-Software-Foundation / sci

A specification that describes how to calculate a carbon intensity for software applications.
Other
252 stars 51 forks source link

Avoid restricting the SCI by prescribing a specific metric. #353

Closed ciril-emaps closed 1 year ago

ciril-emaps commented 1 year ago

We are hereby submitting a formal proposal to amend the SCI standard.

From the evidence gathered, it seems like there is currently little consensus on which metric to use as a decision-making signal, as can be seen in these examples below (some of them are taken from this discussion in this forum):

Even though more evidence could be collected, the examples above highlight that mandating the use of a specific metric in the SCI seems to be an unnecessary restriction that might hinder the adoption of the SCI:

In the interest of a credible, robust and globally applicable SCI, we suggest making the SCI less restrictive, by not mandating marginal as the only decision-making signal. Instead, we suggest allowing multiple, equally relevant metrics in the SCI. Such a change facilitates the adoption of the SCI globally and provides companies with a more broadly applicable tool to decarbonise software.

We recognize the motivation of having a single signal in the standard, and would therefore like to express our intention in helping the group follow and stay aligned with the upcoming scientific consensus, with the ultimate goal to make the SCI more impact-driven and globally applicable.

Henry-WattTime commented 1 year ago

Hello @ciril-emaps I have some serious reservations about this proposal. Fundamentally, we are trying to create a specification that encourages action to reduce global emissions (what might be considered 'consequential', but used to inform action). This proposed PR does not maintain that intent.

I agree with Pieter Gagnon's letter that a short run marginal does not capture the full effect of load and renewable procurement activities. Pieter's letter calls for consideration of long run effects in decision making (a long run marginal signal), he does not advocate for any particular signal. We think that there could be many signals that might approximate that. I've tried to address this in PR #352 by making it clear that the marginal signal should include both short and long run effects.

I think there is consensus that a marginal emissions signal is the correct signal for making decisions to reduce emissions (Olivier's blog post agrees with this and correctly identifies that long run marginal is hard to identify and that average emissions in this context is just a proxy for long run marginal). Am I misunderstanding your point here? If not, a discussion of good signals for long run marginal might make sense in the guidance document.

Also, more granular data is not necessarily required for compliance with this standard. An organization can still make very informed siting decisions based on less granular data. For example, if an organization is making a decision on where to site computation load between Poland and France, annual data may be sufficient to make that decision, especially if load flexibility is not an option. Granular/hourly data alone should not be required if time-based load shifting decisions are being made. Global annual marginal emissions data (both operating and build margin) can be found from the UNFCCC, making this more accessible in a broader range of regions.

I don't particularly understand the bearing that other standards like the EU hydrogen standard has on this standard? I think this standard is attempting to measure something different and drive different action, especially because it includes market measures like renewable energy procurement, which the SCI explicitly excludes?

Does this make sense? Looking forward to discussing this in more depth.

ciril-emaps commented 1 year ago

Hi @Henry-WattTime

Many thanks for your comments. From what you wrote, I actually do not think that we are in disagreement here. This PR was indeed prepared with the intent of encouraging action to reduce global emissions. This is why we'd like the standard to allow the use of multiple metrics such as marginal, average, renewable potential profiles, as long as they, as you mentioned, serve as a proxy to quantifying long-run impact.

To elaborate, given what you wrote, we seem to be in agreement that currently, several proxies exist for long-term impact, including, but not limited to:

To make it absolutely clear, this PR is to enable the use of other proxies, alongside the (short-run) marginal metric, as long as they are indeed leading to long-term impact.

Offering further clarification, we showcased the example of the EU regulation to highlight that other parts of the world are following other signals than currently allowed in the SCI. This specific regulation is creating a legal requirement about siting and load-shifting of electrolyzers, much in the same way that the SCI is incentivising going with software.

Regarding temporal granularity, we did not realise the SCI was not intending to mandate hourly emission factors - we were confused by the mention of “regional, granular marginal emissions rate” line 99. I believe it would be beneficial to provide more clarity around that, but happy to remove this from our pull request if controversial.

Hope this clears up the misunderstanding and I am looking forward to our discussion in the WG.

atg-abhishek commented 1 year ago

Were there any actions to be taken on this PR @ciril-emaps based on the discussion in this week's SWG meeting? Thanks!

ciril-emaps commented 1 year ago

Hi @atg-abhishek, in the last session, we were busy with discussing the Huawei case study and this pull request, so we have not been able to discuss this pull request yet.

atg-abhishek commented 1 year ago

No worries, thanks for the update @ciril-emaps !

navveenb commented 1 year ago

One suggestion would be to list use cases where various signals apply. This would be helpful for partitioners to make decisions. In certain cases, this decision might even be abstracted through APIs- For instance -

  1. An application would like to calculate SCI daily end of the day, which signal should be used.
  2. An application would like to calculate SCI trends over the last 15 or 30 days.
  3. An application would like to schedule jobs in next 24-48 hrs and would like to run when carbon intensity is lowest.
  4. An application would like to calculate SCI every X minutes (near real-time) and make certain decisions based on utilization and carbon intensity
  5. An application would like to calculate SCI before and after deployment (i.e previous and new releases)
  6. The grid data is only available or reported every X intervals (i.e 6 months, yearly), which signal to use
atg-abhishek commented 1 year ago

Great suggestion @navveenb :)

Henry-WattTime commented 1 year ago

WG approved pull request #358 which addresses this.