Closed jawache closed 3 years ago
Hevia
commented
3 years ago 100% agreed, Offsets are finicky to quantify and as a lot of recent news reports have shown, might not be offsetting anything at all. While I want to believe everyone is acting in good faith, offsets could also be used to allow companies to further emit carbon without slashing their direct co2 emissions.
rfsalomon
commented
3 years ago Agree on that. Offsetting is a remediation action that simply transfers the issue somewhere else. In this sense, Carbon offsetting should not be part of any standard per se although it is a natural result of how markets will deal with the published standards.
The goal of the standard should be laying out the recommendations for clean software development and not the rules for mitigating already existing code or infrastructure.
Henry-WattTime
commented
3 years ago I wrote up this prohibition as a pull request.
atg-abhishek
commented
3 years ago Incorporated in PR #14
mrchrisadams
commented
3 years ago Hey folks, can I check a consequence of this?
Let's say you're a hosting provider, and you publish information like the location based carbon intensity of electricity you use to power your infrastructure. Perhaps like Google do here:
https://github.com/GoogleCloudPlatform/region-carbon-info/blob/main/data/yearly/2019.csv
Or perhaps these folks who literally have their own dam powering their datacentre onsite, and use that as a basis for constant, very low carbon power: https://datacenterlight.ch/en-us/cms/hydropower/
My reading of this issue if you're going entirely on this number, and it is not tied to any PPA, REC or similar, than you end up with two main levers for reduction:
I want to check a few scenarios here for intensity, as the consumption one is relatively well understood.
Perhaps you have a battery onsite, that was charged when electricity is much lower carbon, and you're able to draw from that instead of the grid. Drawing from that would count.
Maaaybe, if your system supports it draw some of your power from storage, and some from the grid, so you're using a blend of both, so you have can spread the benefit over longer time period. It would be a bit more complicated to calculate, but not much.
You might use the more common move "the work through time and space" approach commonly discussed.
Can you let me know if this is indeed how you see it?
atg-abhishek
commented
3 years ago This is certainly interesting @mrchrisadams , do you have any changes you'd suggest we make to the language included in the spec now to address your point?
jawache
commented
3 years ago That is how at least I saw it @mrchrisadams . The lever we should avoid is "buying offsets" because then rather than reducing consumption or intensity, people will buy offsets. There are already plenty of incentives and measurement standards that encourage buying offsets, there are few incentives for reducing consumption/intensity.
This characteristic was inspired this is the definition of net-zero by the science base targets institute. They make a clear distinction between efforts that abate carbon emissions and efforts that neutralise carbon emissions and that to be "net-zero" your focus should be focussed on abatement and only using neutralization when you just can't abate anymore (is "abate" a verb?). So this spec I believe should be designed to drive behaviour changes around abatement.
Regarding the cases you describe, specifically, let's say a DC that is directly connected to a hydro dam if that's the case then you can argue that the carbon intensity of their electricity is 0g/kWh all the time and it gets factored in that way.
For onsite battery storage, I'm not so sure, it gets tricky. Maybe it's just a question of how do we calculate the intensity? What is allowed to be included in the calculation of local marginal carbon intensity at the grid level? Battery storage does I believe factor into that calculation, I assume the purchasing of RECs does not. @Henry-WattTime would be keen to hear your thoughts on this?
mrchrisadams
commented
3 years ago hi @atg-abhishek, @jawache
I'm pretty happy with this framing, and the spec of it already TBH, as the incentives it creates I think are still in the spirit of more sustainable software engineering. You are still rewarded for making software more efficient, and you are still rewarded for designing systems that integrate will into the underling grid.
For clarity, I read the incentives here as to either self consume with local storage, or re-assign work to the best resource able to service it, based on your application's temporal of spatial tolerances. In both cases I think it's reasonable for engineers and architects to design for this, and if you zoom out, I think this would likely have an effect on lowering the total system costs of the underlying energy system, and make it easier to integrate variable resources into the grid.
It's also largely in-line with the thinking I see from David Syke's energy onion, which I've found really helpful when thinking about the this myself:
If you want to broadly be compatible with the GHG guidelines for location based scope 2 emissions, then my understanding is that using something like local generation can count, as long as you have a sound basis for describing the emissions caused by using the power from a battery, or other form of energy storage.
In the hypothetical case of using a battery, I would expect to use the carbon intensity from the time you charged it up, and 'time-shift' that carbon intensity to the time of use.
A more concrete example
For simplicity, let's assume the carbon intensity of the power used to charge up a battery was low, because you're taking energy off the grid when it's cheap and green - maybe 100g CO2 per KWh.
If you ran an application for an hour from the battery, that would be the carbon intensity you use, instead of the carbon intensity of the grid.
If you used half from the battery, and half from the grid over two hours, you'd use the average of the two figures and so on, similar to if you had delegated half a workload to a region that had a cleaner grid than you were using right now.
Abishek, you had a specific question about the wording. You could make the argument that this suggests only two ways to affect the carbon intensity of the energy used by the compute:
Carbon aware software will optimize the timing and location of operation to minimize emissions associated with operation. This could consist of moving computation to regions with cleaner grid emissions or delaying jobs to cleaner periods (or a combination of both). Energy efficient software will also run on hardware that requires less energy to operate or the solution can be re-architected to take advantage of different configurations that scale better in terms of efficiency. All combined, these effects should be reflected in the total operational emissions.
I'm happy to make separate issue with some tweaked language to make this more explicit, as I think this discussion isn't re-opening the issue of not using offsets so much as expanding the ways you might influence the carbon intensity of a system.
I'll wait for hearing from Henry, as I think there's some other useful language the Watttime have used before in this domain.
Henry-WattTime
commented
3 years ago Hello All,
Very complex discussion here, apologies for the delay in jumping in. Some preliminary thoughts below. I'd also be delighted to discuss this in more depth during our regular call.
I would still be inclined to exclude energy purchases from the calculation as these purchases are not caused by electricity consumption. For example, even though Google has procured renewable energy for many of its datacenter locations, scheduling a job in a particular location will increase demand on fossil generators there regardless of onsite solar (or vPPAs), because those resources cannot produce more because demand increases. The renewable generation is not relevant in these cases as it cannot adapt to changes in demand (unless are being curtailed).
Similarly, if you are operating a battery at a facility to reduce emissions, it should not be determined by on-site demand. The system level marginal emissions are more important, regardless of site demand. For example, the emissions caused by charging a battery are from the marginal resource that needed to ramp up to meet that additional demand. Conversely, when you discharge that battery, you are displacing a marginal resource, and that is the emissions benefit. In short, system emissions reductions are not the same as facility emissions reductions. Self consumption of solar may not be beneficial in some cases where grid emissions peak in the middle of the day. Exporting that solar, instead of charging a battery, would be more beneficial.
I don't see a reason to align with the GHG Scope 2 protocol, as that is a footprinting/accounting framework. I think we're aiming for a more consequential approach where we look at the change in emissions caused by an action or intervention (this is a good discussion: https://ghginstitute.org/2021/04/21/the-most-important-ghg-accounting-concept-you-may-not-have-heard-of-the-attributional-consequential-distinction/). Also, Scope 2 permits the use of RECs to offset electricity consumption which may not achieve real world emissions reductions. In my understanding, this standard is more focused on measuring the real-world emissions consequences of building and deploying software.
Is this helpful? I'd be very happy to discuss in more depth.
Thanks, Henry
On Sat, Jul 24, 2021 at 5:50 AM Chris Adams @.***> wrote:
hi @atg-abhishek https://github.com/atg-abhishek, @jawache https://github.com/jawache
I'm pretty happy with this framing, and the spec of it already TBH, as the incentives it creates I think are still in the spirit of more sustainable software engineering. You are still rewarded for making software more efficient, and you are still rewarded for designing systems that integrate will into the underling grid.
For clarity, I read the incentives here as to either self consume with local storage, or re-assign work to the best resource able to service it, based on your application's temporal of spatial tolerances. In both cases I think it's reasonable for engineers and architects to design for this, and if you zoom out, I think this would likely have an effect on lowering the total system costs of the underlying energy system, and make it easier to integrate variable resources into the grid.
It's also largely in-line with the thinking I see from David Syke's energy onion https://david-sykes.medium.com/the-energy-onion-a-simple-conceptual-model-for-a-smart-system-3c1f2c5cbd1a, which I've found really helpful when thinking about the this myself:
If you want to broadly be compatible with the GHG guidelines for location based scope 2 emissions, then my understanding is that using something like local generation can count, as long as you have a sound basis for describing the emissions caused by using the power from a battery, or other form of energy storage.
In the hypothetical case of using a battery, I would expect to use the carbon intensity from the time you charged it up, and 'time-shift' that carbon intensity to the time of use.
A more concrete example
For simplicity, let's assume the carbon intensity of the power used to charge up a battery was low, because you're taking energy off the grid when it's cheap and green - maybe 100g CO2 per KWh.
If you ran an application for an hour from the battery, that would be the carbon intensity you use, instead of the carbon intensity of the grid.
If you used half from the battery, and half from the grid over two hours, you'd use the average of the two figures and so on, similar to if you had delegated half a workload to a region that had a cleaner grid than you were using right now. Potential changes to the spec
Abishek, you had a specific question about the wording. You could make the argument that this suggests only two ways to affect the carbon intensity of the energy used by the compute:
Carbon aware software will optimize the timing and location of operation to minimize emissions associated with operation. This could consist of moving computation to regions with cleaner grid emissions or delaying jobs to cleaner periods (or a combination of both). Energy efficient software will also run on hardware that requires less energy to operate or the solution can be re-architected to take advantage of different configurations that scale better in terms of efficiency. All combined, these effects should be reflected in the total operational emissions.
I'm happy to make separate issue with some tweaked language to make this more explicit, as I think this discussion isn't re-opening the issue of not using offsets so much as expanding the ways you might influence the carbon intensity of a system.
I'll wait for hearing from Henry, as I think there's some other useful language the Watttime have used before in this domain.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Green-Software-Foundation/software_carbon_intensity/issues/7#issuecomment-886049282, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI2I5TI4XYHQ5S7PNZEJBS3TZKZLFANCNFSM5APVKKVQ .
-- Henry Richardson Analyst | WattTime.org 415.300.7475 | Oakland, CA https://www.facebook.com/wattTimeApp https://twitter.com/watttime https://www.linkedin.com/company/watttime
WalterRobin
commented
3 years ago Hi, To complement what Asim was saying at the very beginning here is a paper published recently in Nature that reminds us the assymetry between positive and negative emissions.
Hope it can provide scientific grounds to this spec.
Best, Gauthier
1g of carbon that is offset, is not equivalent to 1g of carbon that is not emitted.
If the focus of the standard is to drive behaviour change that reduces carbon emissions, that reduces the amount of carbon in our atmosphere, then allowing someone to improve their software carbon intensity number simply by purchasing an offset negates the goal.
The main challenge is that offsets are not the same, paying someone to plant a tree is not the same as paying someone to not cut down a tree which is not the same as direct air capture of carbon. However, for the purposes of offsetting emissions, they are often all treated the same and also treated the same as not emitting 1g of carbon in the first place.
The specification MUST not allow offsets to be used to neutralise the carbon emissions of the hardware the software uses.
If you are connected to a grid, renewables are an offset for electricity consumption. Not using 1kWh of electricity, is better than using 1kWh of electricity consumed from the grid and then offset with renewables. We need to measure the software energy consumption since that is the thing we want to reduce, not the software energy consumption offset with renewables.
So again, the specification MUST not allow renewable offsets (in the form of PPA, RECs etc..) to be used to neutralise the carbon emissions from the electricity the software uses.