Implement proposed reporting requirements from discussion 103

[Sealjay]

Implements proposed reporting requirements from #103.

[jawache]

Thanks @Sealjay great addition! I think some of this should be moved to an appendix and we have some issues to resolve but great work.

[Sealjay]

@jawache @SaraEmilyBergman - I think I've addressed many of the previous comments - let me know what you think, and I can make further updates prior to Thursday

[YaSuenag]

Should we include the time period to the SCI report?

IIUC the time period is significant parameter to calculate SCI. Methodology Summary says C is total amount of carbon the software is emitting over a time period. And also Marginal Carbon Intensity I in the report may be different from other periods.

[Sealjay]

@YaSuenag I'm torn. C is over a time period and then divided by the same number of R units in the same time period. So, theoretically, the time period shouldn't be relevant here? But at the same time, C over 1 second, is likely to be very different to C over 1 hour.

Interested in more thoughts!

Should we include the time period to the SCI report?

IIUC the time period is significant parameter to calculate SCI. Methodology Summary says C is total amount of carbon the software is emitting over a time period. And also Marginal Carbon Intensity I in the report may be different from other periods.

[YaSuenag]

C is over a time period and then divided by the same number of R units in the same time period. So, theoretically, the time period shouldn't be relevant here?

According to SCI spec, related formulas are defined as following:

• C = O + M = Total amount of carbon the software is emitting over a time period
• O = E * I = Operational emissions based on energy consumption (E) and location-based carbon intensity measurement (I)

I (Marginal Carbon Intensity) is involved to calculate C, so I think it is important to add time period into the report (YAML). I may be different. For example, I in daytime may be bigger than I in midnight.

[SaraEmilyBergman]

This is interesting! My two cents is that for CI (which is the only one they MUST report out of C and CI), then time does not matter (ref to what @Sealjay wrote above) and should not be required but can be provided. But if they chose to report C then I think it is reasonable to also require them to report the time period.

Summary:
Time MUST be reported if you report C and you MAY report time in all other cases.

Happy to hear what others think

[YaSuenag]

SCI spec says CI = C / R. As @Sealjay said, it is over a time period and then divided by the same number of R units in the same time period.

OTOH I think we may want to compare SCI with two region.

• Region A: SCI = 2.0 - daytime
• Region B: SCI = 0.5 - midnight

If we can see them, we may want to migrate our workload to Region B. It is worth to accurate SCI as timeseries data in this case. In addition, we might be able to know the relation between peak season of workload and carbon intensity. It might help to schedule our workloads in long term.

So I want to suggest to add startDateTime and duration (or endDateTime) to YAML.

Comments are welcome.

[atg-abhishek]

I like the phrasing that @SaraEmilyBergman has suggested and also agree with what @YaSuenag has proposed here

[YaSuenag]

We've made it a lot clearer that this all about calculating a C per R and it doesn't matter what method you use to calculate C, you might be looking at logs over 4 days of production running and divide by a number OR you might create a piece of code that models one R and execute it on your laptop and measure energy to model a C per R.

Thanks @jawache for the explanation! Ok, I agree with @SaraEmilyBergman .

So the concept of total time in the calculation of C doesn't matter. However, the granularity of time that you used does matter. Did you use hourly carbon intensity buckets, every 5 mins, daily, yearly averages.... We've not discussed it but I think it's reasonable to ask for the granularity of data to be disclosed, did you use hourly/daily/yearly time slices in the calculation?

I think it is reasonable to duration into the report as a mandatory field.

[Sealjay]

Agreed, this makes sense!

[Sealjay]

so, I can see differing views here - it started with adding a duration/granularity field, for the duration of the timeslice. e.g. hourly, monthly, etc. @SaraEmilyBergman @YaSuenag

however, on the slack, it looks like we might now be advocating for dropping any requirement / suggestion to report C @jawache @atg-abhishek

@SaraEmilyBergman

but C without a time, does that make any sense?

@jawache

For the reporting of C? No it doesn’t but I also think we should drop that requirement to report C. Esp since to calculate your SCI you will need to calculating it for all your sub components.
[..]
Therefore at the end of it, you don’t have a total C anyway since for the client you didn’t have to calculate it. And for the ones where you calculated C they were over different time periods so it doesn’t make sense to add them up to a total C.
Therefore reporting a total C doesn’t makes sense, I think we should drop the requirement to ask for it.

@jawache

Reporting of total carbon emissions altogether, I think with our updates since we wrote that it doesn’t make sense. I’ve got a few mins at the start of the call to take people through a worked example which i think will explain why.

I'll commit on this basis, and we can revert if there is not consensus.

[atg-abhishek]

Since this is a pretty substantial changes with a few pieces still in flux, let us have this as the first item of discussion in the WG call in a few hours. cc @seanmcilroy29

[atg-abhishek]

Deferred for discussion after alpha release

[atg-abhishek]

We might take one of the case studies and then demonstrate the reporting based on that.

[Sealjay]

@atg-abhishek @jawache - I've pulled in upstream changes; there's also a reporting discussion here:
#125
@navveenb has a similar ontology project, so a good time to discuss maybe

[Henry-WattTime]

Working group approved, create document to begin iterating on as a starting point.