Explanation of the carbon reduction goal in context of excluding infrastructure

[davidmytton]

The goals of the SCI:

The Software Carbon Intensity (SCI) Specification defines a methodology for calculating the rate of carbon emissions for a software system.
...
The purpose of the SCI is to encourage actions that reduce the carbon emissions of software.
...
The purpose of the SCI is to encourage actions that reduce carbon emissions of software in a way that create reductions at a system-wide level rather than just at a local level.
...
By far the more preferable goal is never to have emitted the carbon in the first place.

seem at odds with the exclusion of infrastructure-based methods:

Infrastructure measures include any infrastructure that integrates renewables via a direct wire connection, such as a data center with solar panels on the roof and on-site battery storage

Ignoring embodied emissions as one of the variables, the carbon emissions from software are from generation of the energy consumed by the software. If you know that your infrastructure is powered by renewables 24/7, why is that excluded?

Excluding market-based methods and where the infrastructure is connected to a grid with a mix of sources makes sense (you would use the grid intensity factors), but if the infrastructure uses direct, local PPAs and/or directly connected renewables, would that not be a reduction in carbon?

Perhaps I have misunderstood this, so I'd be interested to read an explanation of this exclusion (in the spec, or discussed in this thread).

[mrchrisadams]

Hi @davidmytton , this conversation might be of interest here - I asked similar questions in #7 :

#7

I came away with this understanding of the decision - that it's trying to avoid a "local maximum" effect:
https://twitter.com/mrchrisadams/status/1456036196275085318

David Roberts has a useful multi-post series explaining the trade-offs with the different ways of accounting for reduced emissions through directly connected infra , with interviews from the energy managers at a bunch of larger tech firms. I found it pretty helpful to in the context of this question:
https://www.volts.wtf/p/is-247-carbon-free-energy-the-right

[davidmytton]

Thanks, I didn't see #7 when I was searching, although it is marked as closed anyway 😅

This statement in #7 by @jawache is too simplistic:

If you are connected to a grid, renewables are an offset for electricity consumption.

Renewables are not an offset. The REC attached to the renewable might be seen as an offset if it is unbundled. The complicating factor is whether the REC is attached to the same grid the generation source is attached to. But even that is not the full picture because it depends on the location. For example, in the UK, from the grid perspective solar is seen as a reduction in local demand, not as an increase in supply of renewables.

The issues around accounting and tradeoffs are very relevant on a systems level when we have higher rates of renewables, but we're not there yet. This is on the path to full decarbonisation.

So this is why I don't think the exclusion of all infrastructure measures aligns with the SCI goal. It seems like this point needs more nuance and detail, otherwise it ignores real reductions in carbon intensity and the investments into these types of energy projects.

[jawache]

I agree this is a point we need to elaborate on more in the spec @davidmytton, sounds like you are comfortable and understand why the SCI doesn't include RECs, it's just why not include the infrastructure measures? There is a more nuanced argument that @Henry-WattTime and @buchananwp can elaborate, but from my understanding this is more about looking at the problem on the system level (I'm hoping this discussion might result in a paragraph we can include in the spec :) )

[davidmytton]

Right. If the relevant infrastructure measures are excluded, there needs to be some explanation of why a service that is deployed into a data center that runs directly off 24/7 clean energy would get the same score as one powered entirely by coal (to take two extremes). There would be no incentive for the customer to pick the former because it would not be represented in the score. That doesn't make sense to me.

[jawache]

As a counterpoint, imagine you have two applications one that is incredibly energy inefficient and one that has been invested in to make it incredibly energy efficient. If both of them were run on a 100% REC matched DC, or if they ran on a DC that is 100% direct wire connection to say a hydro dam, then they would have the same score. Where is the incentive to make changes to your software to reduce your energy consumption?

[davidmytton]

Agreed that would be a counter example, but only if the goals of the spec were to improve energy efficiency. The current spec says the goal is carbon emissions:

The Software Carbon Intensity (SCI) Specification defines a methodology for calculating the rate of carbon emissions for a software system.
...
The purpose of the SCI is to encourage actions that reduce the carbon emissions of software.

Energy efficiency is different, and seems to be a component of the current spec (improving energy efficiency is one way to reduce carbon emissions), but it's not the goal. I'm fully in favor of considering energy efficiency, but that's not what the spec says right now :)

[jawache]

I feel we are on the same page but I'm a little lost in your conclusion, using less energy means fewer carbon emissions, so one leads to the other, is that how you see it?

The goal of the spec is to encourage one or more of these actions to be taken. When evaluating the spec and the changes to it, the question we ask ourselves on every change to the spec is will that change encourage more of those actions to be taken?

There is a more nuanced story regarding infrastructure measures which we should definitely elaborate on, but this is why generally neutralisations of any form, energy or carbon, are not included in the spec.

[davidmytton]

The goal of the spec is to reduce carbon. One of the ways to do that is to improve energy efficiency because reduced energy consumption will usually mean reduced carbon emissions. But not always. If the energy being generated is already zero carbon, there is no further carbon to be reduced.

Another way to reduce carbon is to switch the infrastructure to zero carbon sources of energy. I don't understand why that is excluded (as currently written). It seems like a valid way to achieve the end goal of reducing carbon (assuming what we discussed above regarding RECs, directly connected, etc etc).

[Henry-WattTime]

Hello All,

Market instruments (like RECs, GOs, PPAs, offsets, etc) are not an intrinsic characteristic of the software that can be improved by the developer. They are all mechanisms for reducing emissions after consumption has been established. In my understanding, this spec is focused on how to improve software itself, to avoid the creation of emission in the first place.

We're looking at the impacts at the system level, not at the individual organizations emissions.

Furthermore, 24/7 strategies are measuring MWhs, not emissions, encountering the same issue as measuring efficiency, not emissions. To get even deeper, we're focused on making this a consequential standard. Most standards are attributional, like the GHG Protocol and 24/7, which may not measure actual emissions reductions. This paper discusses that in some depth: https://www.watttime.org/news/white-paper-to-drive-more-authentic-impact-faster-look-at-the-consequences-of-your-choices-and-actions/

This is a topic of some depth, should we setup a special meeting (or reserve one of the standards WG calls) for a deep dive on this topic? Who should be in attendance? @davidmytton @jawache @dschien Others? Looking forward to discussion this in more detail.

Thanks,
Henry

[atg-abhishek]

Yes, we can make this the top item for discussion in the upcoming WG meeting since this is a very important thing that we need to figure out and have clear communication on. The broader group will definitely benefit from having an in-depth understanding of all sides to the discussion.

[davidmytton]

I understand the systems level goal but it seems to create strange effects when you exclude infrastructure methods of reducing the carbon impact of the software which actually serve to prevent the carbon reduction e.g. the same score outcome of two identical software deployments in two different facilities, one on clean energy and the other not. This seems to come about because the scoring is not just looking at what the software developer can improve - it covers all the supporting infrastructure (rightly so).

I'd be happy to discuss further in a meeting. I'm not currently a member of the WG/Foundation though; I'm attempting to join but there is some difficulty with the lack of a route for individuals.

[will-iamalpine]

Given that the* "purpose of the SCI is to encourage actions that reduce carbon emissions of software in a way that create reductions at a system-wide level rather than just at a local level." *we should consider adding "*this spec is focused on how to avoid the creation of emission by improving software*" *Market instruments* *: *I agree with Henry, and propose weaving his comment into the spec *"Market instruments (like RECs, GOs, PPAs, offsets, etc) are not an intrinsic characteristic of the software that can be improved by the developer. They are all mechanisms for reducing emissions after consumption has been established."* What I don't have a clear answer for myself, which ties into David's point, is why infrastructure measures should be excluded. If we are running software that is entirely powered by renewables by a direct wire connection, we have therefore avoided the creation of emissions in the first place. *Infrastructure: "**Infrastructure measures include any infrastructure that integrates renewables via a direct wire connection, such as a data center with solar panels on the roof and on-site battery storage. This is conceptually closer to a Microgrid, where there is a higher % of renewable energy usage than the local grid carbon intensity."* - Infrastructure measures may prevents a basis for comparison between two SCI scores - Collection of infrastructure data is hard - the system must be stranded, and not integrated into the grid - If this renewable energy were taken and put directly into the grid, it MAY impact the system carbon intensity, which is potentially desirable - PUE and other factors are __really__ hard to get, and may overcomplicate the process. Best, Will

…

On Mon, Nov 22, 2021 at 7:37 PM Abhishek Gupta ***@***.***> wrote: Yes, we can make this the top item for discussion in the upcoming WG meeting since this is a very important thing that we need to figure out and have clear communication on. The broader group will definitely benefit from having an in-depth understanding of all sides to the discussion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#207 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEFHESPDIES5FDAPVH6BA3UNKEWTANCNFSM5IMZPULA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[Henry-WattTime]

I think direct wire is an odd situation. For example, if you put solar panels on your building/data center, that means you are no longer pulling electricity from the grid when those panels are producing. You are still interconnected with the grid and if you increase computation, then you will just pull more electricity from the grid, the solar won't produce more energy to meet that demand. Conversely, if for some reason all the load in the data center went away, then the solar panels would still be producing power and feeding it back into the grid. In short, direct wire renewables produce power irrespective of what is going on in the data center. Only if the renewables are connect by a direct wire and there is no grid connection would we use a non-grid emissions factor. Does this make sense?

[davidmytton]

The direct wire situation may currently be unusual, but there are more and more large scale projects where renewables are deployed locally to the DC alongside storage. This means the DC load can be covered most of the time. If the goal of the spec is to reduce carbon, ignoring the use of this clean energy is strange (or needs to be explained better).

[jawache]

Thank you for this conversation @davidmytton , it's really useful to understand how people see the spec, and so we can learn how better articulate some of the positions.

The purpose of the SCI is to encourage actions that reduce the carbon emissions of software.

I suspect one issue is we need to clarify what we mean by reduction, and make it clear that our position is that neutralisation is not equal to reduction. Or perhaps use the term abatement like the SBTI uses in their net-zero definition? Our goal is abatement, reduction in gross emissions, not reduction in net emissions (gross emissions minus neutralisations).

One of the core characteristics of the spec everyone agreed to at the start was that if you make changes to your software to make it more energy efficient, the SCI score has to go down, see this. If neutralisations were included in the spec and you were running on a 100% carbon neutral and renewables matched DC, then if you make your application more energy efficient, your score would not change. It would break a fundamental characteristic and purpose of the SCI which is to encourage investment into changing software so it emits less carbon in the first place. This is why all neutralisations including RECs cannot be included, it would break the core characteristic.

The other point of the spec I think we need to explain better is our systems impact view. The best way to have a systems impact is to respond to signals at the system level, not at the local level. 24/7 matching is a great example of something that does not take a systems impact view, i.e. everyone running 24/7 locally at their DC, does not result in a grid that is running 24/7 and in fact can have worse outcomes. The "no infrastructure" argument falls into the systems impact view, we don't include local infrastructure because all that matters is what's happening at the system level.

I like your suggestion @buchananwp. If you are an off-grid DC, directly 100% powered by say solar on the roof, 100% of the electrons flowing in were zero carbon. Then the "systems impact" is localised to your DC, the system/local level marginal carbon intensity would be 0g/kWh and you would be able to use that in the SCI. However I don't know of any DC that would be built like that? Being on a grid and having multiple sources of energy in case one fails is a strong benefit for DC's. If you're on-grid, then your system is the grid, and we take the marginal carbon intensity of the grid since acting on that information results in the best outcome overall. i.e. Maybe we need to define what the boundary of the "system" is in "system impact"?

[davidmytton]

Thanks for the detailed explanation @jawache - I'm definitely in agreement with overall purpose. Hopefully my comments are useful from the perspective of just reading the spec and not (so far) having been involved with all the discussions. I still have some questions though:

1. I agree that neutralisation is not equal to reduction. This is the classic debate around offsets, and it seems appropriate to ensure that RECs and financial PPAs are considered as neutralisation mechanisms. My concern is that defining all infrastructure mechanisms as neutralisations misses the fact that adding new carbon free generation to the grid is not a neutralisation, it's a reduction. If an infrastructure operator buys a direct PPA with additionality so that it deploys (somewhere) new carbon free energy to the grid, the grid carbon intensity falls (subject to balancing fluctuations). Is the idea that this will be captured within the grid carbon intensity factors rather than being allowed to be part of the SCI score for that specific software?
2. How does that change when considering 24/7 hourly carbon free energy purchases that come from a locally deployed carbon free source? Using CFE % on an hourly basis allows you to distinguish between local clean sources of energy and when you have to draw power from the wider grid, where the general mix carbon factors apply. Is that ratio captured in the spec and if it is excluded, why?
3. I agree that improving the software energy efficiency should reduce the SCI score, but that is not always compatible with the goal as currently written in the spec. The current goal focuses on carbon. Fast-forward to a future where everything in the assessment system boundary is connected to a grid that runs on 100% clean energy, improving the energy efficiency of the software has no impact on carbon, because the carbon footprint is already zero. Software does not emit carbon. The generation of the energy used to run the software emits carbon. Is the goal to reduce energy consumption or carbon impact?

[will-iamalpine]

David, I agree that we need to explan it better. We're not ignoring the use of clean energy: it's rolled into the systems view of the grid-based marginal carbon intensity score. Borrowing from how Henry framed it, I am wondering if we could disambiguate infrastructure measures to the following: *Off-Grid: *Infrastructure measures when the system is NOT grid-integrated (such as an off-grid scenario) MUST use an appropriate marginal carbon intensity value for the system. *(this covers the off-grid solar/battery-powered use-case, and accounts for this balance of system). * *Interconnected:* when the system is interconnected to the local grid (such as solar panels on a datacenter roof) MUST use the location-based marginal carbon intensity of the grid that powers it, due to the balance of the system. *(You are still interconnected with the grid and if you increase computation, then you will just pull more electricity from the grid, the renewable energy infrastructure won't produce more energy to meet that demand.) * There's a lot of room to improve the wording, but does this help clarify a bit more? Best, Will

…

On Tue, Nov 23, 2021 at 8:32 AM David Mytton ***@***.***> wrote: The direct wire situation may currently be unusual, but there are more and more large scale projects where renewables are deployed locally to the DC alongside storage. This means the DC load can be covered most of the time. If the goal of the spec is to reduce carbon, ignoring the use of this clean energy is strange (or needs to be explained better). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#207 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEFHETBRVBMBJJZHNAQWWTUNM7SVANCNFSM5IMZPULA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[davidmytton]

Thanks, I think that covers the off grid case (uncommon, but growing). However, the interconnected option doesn't cover the case of locally deployed carbon free energy which is used on a 24/7 hourly matching basis. In that case you'd use the marginal carbon intensity for the national grid during the time when the local sources didn't match. See my question 2 in the comment thread above.

[Henry-WattTime]

Hello David. I've put some more thought into this. Take for example two datacenters located in a grid region where one data center has a contract (through some market instrument) with a renewable energy project (non-dispatchable). That data center ‘claims’ to be running on clean energy. From a physical (non accounting/claims) standpoint, they are consuming the same electricity because they are interconnected to the same grid. Assuming the data centers have identical equipment, increasing load at either data center increases emissions in the world (consequential) equally because even if you put the load in the datacenter with the renewable contract, that renewable energy project cannot ramp up to produce more electricity because demand increased. Irrespective of which datacenter has the additional load, some fossil fuel generator in that grid region will have to ramp up to meet the additional demand. (This also applies to on-site renewables for a grid connected datacenter. If demand increases at that datacenter, the renewable project cannot increase output to meet that demand and a grid resource must ramp up) Does this begin to answer your second question? Always happy to discuss further.

[davidmytton]

That makes sense in a simplistic scenario. There's a lot of nuance to how deployments actually work in real life, e.g. in the case of a microgrid with sufficient clean energy supply to cover maximum demand. In that case, the interconnect (if it exists) may only be required for short periods.

[Henry-WattTime]

Working Group:
-We need to more clearly explain our position
-Pickup next week (2021/12/9)

[Henry-WattTime]

Landed on reporting system level impacts
which may exclude "market instruments"
"market instruments are not intrinsic characteristics of the software that can be improved by the developer"
All mechanisms for offsetting impact after consumption has been established

Turn into PR
Can do blog post/wiki as needed? - strongly recommended by writers

Grid connected onsite renewables/Rooftop solar? - excluded from calculation due to system thinking
If you were to install solar on DC, could not attribute solar production to particular code, would be feeding into larger system/grid
That solar would produce energy regardless of the demand/software running in DC.
The renewables improvements do decrease emissions in the system, and that effect can be measured, but not linked to the software

Blog:
-Systems thinking/consequential
Ex:
-off grid
-interconnected data center
-market instruments
-Carbon is still being emitted, score does not allow you to "buy your way" to a better score
-rooftop solar/onsite renewables and how to treat
-Solar/onsite renewables is still reducing system emissions, separate action reflected in the grid emissions

Marginal software carbon intensity?
Fixed capacity of solar, that is the total amount you have, but if you run additional code there is no more solar to serve that, must be drawn from grid. Impossible to track.

Pull in David Mytton?

[atg-abhishek]

@Henry-WattTime will create a PR based on the discussion with @buchananwp

[mrchrisadams]

Would you folks let me know if you discussed the case of dispatchable power like on-site batteries and hydrogen?

There's much more control over their output than variable generation from wind and solar, and while this isn't captured in the SCI standard, we know that they're being used integrate DCs better with the grid already.

If as a developer, I'm able to make a decision to make use of this local resource, as an alternative to needing to think about distributing geographically, I can totally see myself doing so when deciding what trade-offs I make designing a system. I've outlined a model I've used here to make this a tad clearer.

https://docs.google.com/presentation/d/1pEWcnYnu7wYul2sUMZvyi8NolpUncLAy3iAsUOK2urA/edit#slide=id.p

Consider the case of building a caching layer in software. I might think about caching locally to reduce expensive computation, and spending money and time to implement a caching layer in a datacentre. This would be valid, and in scope for the SCI.

I might do the same to implement code against a GPU for processing an expensive job to save on energy and therefore carbon.

It's not a huge jump to make the same decision to spend money and dev time to implement code to consume energy from a low carbon buffer of dispatchable stored energy, physically local to my instance, before would fall back to distributing the same work to a geographically distant instance in a greener region, or temporally distant instance in the same region.

We know these are:

• dispatchable
• still on an aggressive downward trend in price, just like the cost per unit of compute that GPUs has been
• in some cases not that much more complicated to install in a DC than a rack full of GPUs

I'm aware of the system vs local trade-offs, and I can follow some of the reasoning, but I can also see how as a developer, if I'm already at the point where I'm buying cache-as-a service, and GPU_as_a_service from a cloud provider, I might choose to buy local-battery-as-a-service in a few years and integrate there.

[davidmytton]

I'll be interested to see the PR for this. I'm keen to discuss my open questions if that is of interest.

market instruments are not intrinsic characteristics of the software that can be improved by the developer

At the moment this statement still doesn't make sense to me given the system boundary for the current SCI version which includes all the supporting infrastructure.

[Henry-WattTime]

@mrchrisadams I think dispatchable assets create a very interesting case. From an emissions reduction standpoint, those dispatchable assets should be controlled completely independently of the datacenter they might be located at and in response to a grid emissions signal. Just like any flexibility in the software, the energy storage should be charged when the grid is cleanest and discharged when the grid is dirtiest. This has nothing to do with how much compute load/electricity consumption there may be in the data center at that moment. Does this make sense? I'd be happy to discuss in much more depth if helpful.

[will-iamalpine]

Henry, well said! Would a term like 'marginal demand' help in this explanation ^^^? Best, Will

…

On Thu, Jan 6, 2022 at 9:32 AM Henry-WattTime ***@***.***> wrote: Hello David. I've put some more thought into this. Take for example two datacenters located in a grid region where one data center has a contract (through some market instrument) with a renewable energy project (non-dispatchable). That data center ‘claims’ to be running on clean energy. From a physical (non accounting/claims) standpoint, they are consuming the same electricity because they are interconnected to the same grid. Assuming the data centers have identical equipment, increasing load at either data center increases emissions in the world (consequential) equally because even if you put the load in the datacenter with the renewable contract, that renewable energy project cannot ramp up to produce more electricity because demand increased. Irrespective of which datacenter has the additional load, some fossil fuel generator in that grid region will have to ramp up to meet the additional demand. (This also applies to on-site renewables for a grid connected datacenter. If demand increases at that datacenter, the renewable project cannot increase output to meet that demand and a grid resource must ramp up) Does this begin to answer your second question? Always happy to discuss further. — Reply to this email directly, view it on GitHub <#207 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEFHEUCLIW7XGV5FJ5WW53UUVHSZANCNFSM5IMZPULA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: <Green-Software-Foundation/software_carbon_intensity/repo-discussions/207/comments/1917197 @github.com>

[will-iamalpine]

David, does what you're saying mean that the software boundary would change over time (e.g. microgrid that only periodically needs to interconnect with the grid)? In that case, it seems that we would need to compute a series of SCI scores with different boundaries for each of these scenarios. Best, Will

…

On Thu, Jan 6, 2022 at 1:01 PM David Mytton ***@***.***> wrote: That makes sense in a simplistic scenario. There's a lot of nuance to how deployments actually work in real life, e.g. in the case of a microgrid with sufficient clean energy supply to cover maximum demand. In that case, the interconnect (if it exists) may only be required for short periods. — Reply to this email directly, view it on GitHub <#207 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEFHETBIHKFLQACTYRFPETUUWABRANCNFSM5IMZPULA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: <Green-Software-Foundation/software_carbon_intensity/repo-discussions/207/comments/1918089 @github.com>

[davidmytton]

I don't think the system boundary would change, at least not in relation to the components described here. Rather, the value for Location-Based Marginal Carbon Intensity would change for the period that the microgrid is running isolated.

[will-iamalpine]

That makes sense! So we would be modifying the location-based emissions profile, essentially parsing it into several sub-series. Any chance you’d be interested in characterizing this concept mathematically, e.g. integration for these periods to help others visualize the discussion?

On Thu, Jan 6, 2022 at 1:42 PM David Mytton ***@***.***> wrote: I don't think the system boundary would change, at least not in relation to the components described here <https://github.com/Green-Software-Foundation/software_carbon_intensity/blob/8056e43a9355bf7fd36a35c8718aa0438c05ab65/Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md#software-boundary>. Rather, the value for Location-Based Marginal Carbon Intensity would change for the period that the microgrid is running isolated. — Reply to this email directly, view it on GitHub <#207 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEFHETJ3SG4AJUMCD7XYWDUUWEZVANCNFSM5IMZPULA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: <Green-Software-Foundation/software_carbon_intensity/repo-discussions/207/comments/1918246 @github.com>

-- Best, Will

[davidmytton]

I will have to leave the maths to someone more experienced I'm afraid. I would assume that it would need more time granularity to represent the varying emissions factors at each point throughout the day. The more granular it gets, the more accurate it will be in capturing the true emissions factor, but the more challenging it is to get the data. Annual emissions factors are easy to find, hourly is more challenging. I believe Watttime have an API for this, though.