mrchrisadams
commented
2 years ago I'm not going to go into the validity of using a 'per gigabyte' model for this issue compared to other options, nor the validity of the top down figures for total internet energy usage. The main aim of this issue is capturing the intent of the Sustainable Web Design model outlined above, in code, so it's easy to use and deploy in software. If you want to propose any changes to how you model emissions that are not described, or at least alluded to in the page linked in the issue please see issue #2 in this repo
At present, if you want to get a CO2 emissions figure for data transfer we have an API like so:
You instantiate the instance of the CO2 class:
const co2Converter = CO2()
And then you call a single function like so, passing in:
- a) bytes - the figure for data transfer in terms of bytes
- b) green/not green - boolean we use with when checking a domain against the green web foundation, to account for whether this is using green energy or not. We assume green here to mean energy that is matched on an annual basis from fossil free sources (i.e. by using a green tariff, buying REC's etc). If the energy is green, we use a different conversion factor than the usual which uses a global average.
From memory, the IEA figure is just for fuel - it's not a levelised figure that includes the embedded emissions in making the infrastructure as well. If it was a levelised figure, it would make sense to have non-zero figures for renewables too, as it takes energy to make solar panels, and the rest.
// define some constants that we expect to use in our examples
// 1024 bytes in a kilobyte
// 1024 kilobytes in a megabyte
// 1024 megabytes in a gigabyte
const GIGABYTE = 1024 * 1024 * 1024
// simulate getting a 'green' result when looking up a domain against the green web fdn dataset
const GREEN = true
// get back our CO2 figure
co2Amount = co2Converter.perByte(GIGABYTE, GREEN) This should return a figure for CO2 in grams - typically something between 150 and 500 grams per gigabyte transferred, depending on how dirty the grid is.
Adapting this API to the Sustainable Web model
The Sustainable Web model is conceptually similar to the 1 Byte model from the shift project.
We'd ideally be able to use it like so for simple cases:
// we don't have this handy object yet but it would be nice to have it, and not too complicated to implement
import { models } from '@tgwf/co2'
// we pass in the different model here, instead of defaulting to the 1 Byte model.
// Feel free to use a better name than SustainableWebDesign...
co2Converter = CO2({model: models.SustainableWebDesign})
)
const co2Amount = co2Converter.perByte(GIGABYTE, GREEN)This would return the a figure in grams using the different assumptions in the Sustainable Web Design model as compared to the 1 Byte model, but assuming you have original usage data in the form of structure data like HAR files, and counts for page loads, you should be able to re-run it with the new model for updated numbers.
Key differences for the simplest version of the sustainable web design model
For the purposes of making calculations, the key differences for the 1byte model as implemented in CO2.js here, and the SWD one as as follows:
Including device energy
The one byte model as implemented in CO2js does not account for device usage, nor embodied energy. The Sustainable Web Design does attempt to include them.
For every gigabyte of data transferred, it assumes 0.81 kilowatt hours, which can be divided across the following:
- Consumer device emissions 52%
- Network emissions 14%
- Data center emission 15%
- Production emission 19%
Accounting for caching
The sustainable web design model also tries to account for caching. Instead of assuming no caching, the SWD model assumes
- 75% of requests are uncached - use the full figure for data transfer
- 25% of requests ARE cached - use a much smaller figure here, and divide this figure by 50
If you prefer, you can express this accordingly:
E = (Data Transfer per Visit in GB x 0.81kWh/GB x 0.75) + (Data Transfer over the Wire (GB) x 0.81kWh/GB x 0.25 x 0.02)
Extending the Sustainable Web Design Model
This by itself ought to be compatible with the website carbon figures.
Spatial resolution
Carbon intensity varies by country. If we have country level figures, (or better yet, grid level figures within a country), it would be good to use that.,
If we pass the ISO country Alpha-2 country code in, we get back the annualised carbon intensity figure for the country.
const co2Amount = co2Converter.perByte(
GIGABYTE,
GREEN,
{deviceCountry: "FR" });If we have more than one grid region in use we follow the Electricity Map example of country code, plus grid identifier.
So AUS-QLD for the Queensland grid in Australia, AUS-SA for the state of South Australia in Australia, and so on.
It might look like this:
const co2Amount = co2Converter.perByte(
GIGABYTE,
GREEN,
{deviceCountry: "AUS-QLD" });Theoretically, because we have a country namespace, we could scale this further down to ever smaller grid regions, microgrids, or perhaps even datacentres or cloud provider regions, assuming they provide trustworthy data. This would provide scope to eventually move on from the pretty simplistic green/not green boolean approach to something richer.
But for now, we assume country level resolution, and at a stretch, grid level.
Accounting for production emissions
The sustainable web model includes production emissions. If you were to do use this, given the percentage of electronics manufactured in China you might use an emissions factor for the Chinese grid, rather than the grid the device is being used. If you're using an macbook charged in France, but made in China, using the French carbon intensity figure for production emissions would be misleading.
If you were to go further down this rabbit hole, you might use a weighted average to include the Taiwanese grid to capture the volume of chips made there, and that many of the energy intensive processes for fabricating chaps might happen there.
Temporal Resolution
In addition to geographic resolution, we'd want the option of providing support for temporal resolution, although doing this involves a few deliberate judgement calls.
The SWD model includes the impact of energy usage from the consumer device, and this represents around half the calculated emissions, so we have two decisions to take here.
If we decided that the datacentre carbon intensity energy was worth capturing
If we need to capture the datacentre intensity, we'd likely need an idea of both where the device accessing content is, AND where the origin server serving the content is.
They could both have different carbon intensities for the energy - think of the case where a user is on a device connecting during daytime from their point of view, to a server on the other side of earth where it's night time.
To capture both accurately, we would need the time in both places. You could do this with:
- two time/location pairs, or
- one time/location pair, and one location - you should be able to derive the time based on the timezone difference to figure out the time in the second location
This might look like so, if you wanted to get a number back:
const timeAndSpace = {
deviceCountry: "AUS-QLD", deviceTimestamp: "2021-12-13T16:40:27.614Z",
serverCountry: "FR"
}
const co2Amount = co2Converter.perByte(
GIGABYTE,
GREEN,
timeAndSpace
)If we decide it's less important
In the SWD model, the datacentre emissions make up 15% of the total figure. We might decide that the difference in carbon intensity between servers isn't large enough to matter, or it's not something we have meaningful control over.
This would simply things somewhat - depending on your goal, this might be a valid decision. This is something that isn't obvious from the page:
const timeAndSpaceOnlyForDevice = {
deviceCountry: "AUS-QLD", deviceTimestamp: "2021-12-13T16:40:27.614Z",
}
const co2Amount = co2Converter.perByte(
GIGABYTE,
GREEN,
timeAndSpaceOnlyForDevice
)Figuring out appropriate time resolution the carbon intensity 'bucket'
Once you have this information, because geographic carbon intensity needs to be tied to a time period, you'd likely try to fit this into the corresponding time bucket for a tracking grid intensity. In most places, these are 30 minute settlement periods, but higher resolution does exist in some parts of the world.
You'd likely need some indication on what the time resolution is from a provider, as this could lead to different numbers -
So far the co2Converter.perByte function onlys returns a numeric figure.
Changing this return type would likely break a bunch of APIs so it, might make sense to be able to query the kind of default time resolution returned instead.
// check what the time resolution is
co2Converter.defaultTimeResolution // i.e. 30minsAnother option would be to allow overriding this time resolution when calling the function. We'd likely need a set of symbols to capture the main time resolutions (i.e. 30mins, 15mins, 1yr, etc), that we could pass in.
const timeAndSpace = {
deviceCountry: "AUS-QLD", deviceTimestamp: "2021-12-13T16:40:27.614Z",
serverCountry: "FR",
timeResolution: "1yr"
}
const co2Amount = co2Converter.perByte(
GIGABYTE,
GREEN,
timeAndSpaceOnlyForDevice
)I think this, with a few hard coded constants, would capture most of the intent that I see in the model outlined at the link below.
https://sustainablewebdesign.org/calculating-digital-emissions/
drydenwilliams
This model is used in a number of places:
https://sustainablewebdesign.org/calculating-digital-emissions/
There's a bit more research needed for what I was referring to as the Green Byte Model in in #2, but it would be useful to have the different models in used available, so you can choose between:
Acceptance criteria
In all cases we'd want to be able to call
perbyteto return a single number for compatibility, and have a way to return an object with scope for more complex return info (so we can refer to specific parts of the SWD result breakdown or other info)