Open colesadam opened 8 months ago
jawache
commented
8 months ago Very interesting @colesadam actually scoring processes against a RAG or some other scorecard has come up in conversations many times so I'm sure plenty of people (including me) will be watching what happens here with anticipation!
russelltrow
commented
7 months ago Hi @colesadam please don't forget to register your project: https://hack.greensoftware.foundation/register/
This provides you direct access to the Impact Framework team for your questions and also benefits from our community partners (Microsoft & Electricity Maps).
You must register your project before you can submit your solution for judging.
colesadam
commented
7 months ago Hi @russelltrow , I believe we are already registered?
russelltrow
commented
7 months ago Hi @colesadam yes just found your registration. Sorry for the confusion :)
colesadam
commented
7 months ago update coming soon
Prize category
Beyond Carbon
Overview
We plan to create a YAML or possibly an exhaust plugin that produces a rating for processes or services running on known cloud VMs.
Inputs will be rated for SCI level, Software Water Intensity (we will need to build a plugin as per the first part of the discussion at https://github.com/Green-Software-Foundation/hack/discussions/82)) and total energy consumption.
Given a lack of independent criteria we will allow the user to set thresholds for RAG themselves with the intention of using that to show improvement or lowered performance over time.
As a stretch goal we may look at adding another plugin to assess SADPI, or Software Abiotic Depletion Potential Intensity based on Boazvista data.
Questions to be answered
No response
Have you got a project team yet?
Yes and we aren't recruiting
Project team
@paulonevrything @omotrium @openyast @colesadam @yohan-oc
Terms of Participation
Project Submission
Summary
We decided to create a plugin for a risk scorecard to rate the environmental impact of software based on the Software Carbon Intensity (CO2e/R) and Software Water Intensity (l/R) - this gives us a way to classify a functional unit (e.g. http request) in terms of its impact to the with regards to two environmental concerns.
To be able to calculate SWI we needed also created plugins for measuring the water consumed when cooling the software workload. We also have proposed that the water consumed during power generation should be added and identified datasets that could be used for estimation.
Problem
It is difficult for non-technical stakeholders or those who are not familiar with sustainability concepts to understand the numeric readings from the calculations such as the SCI. We believed that using a Red/Amber/Green rating (RAG) would provide a more obvious indicator of the impact that software under development will have in real life. We had seen that this system is currently used in areas such as assessing the sustainability of websites.
We also believe that stakeholders are more familiar with the concepts of global warming being a consequence of fossil fuel power generation which could be easily mentally linked to the electricity used by datacentres, whereas many would not be aware of the other large environmental impact caused by water use. It seemed that linking the two concepts in a similar way would help to raise awareness within stakeholders and development teams.
There is no current plugin designed to measure water use so we knew we would need to create one ourselves. Prompted by discussion in the GSF forum we set out to establish the logic behind a single software water intensity figure.
Application
We developed an app to measure data inputs and create a risk scorecard showing the RAG status of SCI and SWI.
The app has 4 plugins:
Water Power -- uses an electricity maps API to obtain the power generation for a location during a period. Using total energy and a dataset that maps energy for each generator to water use we derive the water used to generate the energy in the same period.
Water Cloud -- this multiplies energy by the default datacentre WUE figure of 1.8 l/kWh to get a total for water cooling for each process during the period.
SWI -- totals water(power) and water(cloud) and allocates to functional unit/time according to the function:
SWI = ((E*(I~1~+I~2~)) +M) per R
where E is the energy consumed by software, in kWh\ I1 is the water used for producing electricity, per kWh of energy in Litre/kWh (water-generation)\ I2 is the water used for cooling data centres, per kWh of energy in Litre/kWh (water-cloud)\ M is the water used during the creation and destruction of hardware that the software is running on (water-embodied)(Not yet implemented).\ R is the functional unit
Prize category
Beyond carbon
Judging criteria
Overall Impact
The main purpose of rating software using a simple traffic light system is to make it clearer to developers and stakeholders whether they are meeting appropriate standards. While using the SCI measurement is a good standard, the addition of an SWI measurement takes the assessment beyond carbon and broadens the understanding of sustainable software.
Educational Value
Most software teams and stakeholders will be able to make the connection between energy use and powerplants emitting CO2 but the link to water is less obvious. Equating the amount of water used by software processes to carbon provides a useful mental model and a link to real human problems.
Synthesizing
The plugins use a variety of data sources:
The electricity maps API is used to get a breakdown of energy produced per power source -- this is used to calculate water use due to power generation*. Data is not available for every country or zone and so we default to an average of 1l/kWh.
In the future we plan to incorporate water stress information coming from https://ourworldindata.org/water-use-stress to apply a coefficient to the SWI RAG rating.
References
Video
https://youtu.be/1oIL9X0m780
Artefacts
GitHub Repo - https://github.com/opencastsoftware/carbon-hack-2024
Usage
Read Me - https://github.com/opencastsoftware/carbon-hack-2024/blob/main/README.md
Process
At the start of the project none of the team had any hands-on experience with the Impact Framework so the first stage involved upskilling the development team to provide them with a foundation upon which the 4 plugins could be developed.
The next stage involved one of our data analysts carrying out extensive research on water consumption across datacentres. This allowed the data analyst to create a data model which expressed the relationship between energy consumption and water consumption. This model, when combined with other metrics allowed us to calculate a value for SWI.
The development team then took the data model and applied to across a series of 4 plugins as described in a previous section.
The team worked collaboratively with daily stand-ups and mob sessions to progress the development work and refine the data model.
Inspiration
The team identified a gap in the capability of the Impact Framework.
Currently the framework allows energy consumption to be evaluated but lacks the ability for users to determine the impact of water consumption during software development.
A component to show water consumption and its impact on software development would enhance the case for the adoption of sustainable practices.
By incorporating a region-based water stress coefficient into the SWI RAG threshold calculation, the "if risk scorecard" plugin can provide context-aware guidance to users.
This approach acknowledges the varying levels of water stress in different regions and encourages users to prioritise water conservation in areas with higher water stress.
Opencast has made a commitment to adopting sustainable practices. The enhancement of the Impact Framework is an example of how Opencast seeks to promote sustainability through the provision of toolsets that provide visibility of the impact of software development on the environment.
Challenges
As part of our assessment we wanted to add a beyond carbon measurement and chose Software Water Intensity modelled partly on SCI.
We used a default value for WUE (water usage effectiveness) of 1.8l/kWh averaged across all datacentres. This value includes renewables as they too consume water.
We were able to add a dataset of water usage per kWh produced for different types of generation (e.g. coal, nuclear, hydro) and used the Electricity Maps API to derive a breakdown of grid usage in the period being measured.\ The SWI model does not include a measure for embodied water; this could be added in future.
The biggest issue, which this plugin does not address, is assigning initial threshold values for ratings as data is either not available or context specific.
We propose these thresholds could be set at default values, adjusted over time based on empirical evidence.
Accomplishments
None of the team had used the Impact Framework and we welcomed the opportunity to progress our understanding in an immersive environment.
It was clear the development of reliable data models was crucial to our ability to design impactful plugins.
We spent a significant amount of time carrying out research and data analysis to derive a data model and data set that reflects water consumption within datacentres.
The establishment of a measurable relationship between energy consumption and water consumption during the software development lifecycle was an important breakthrough that enabled the development of the plugins.
Overcoming the challenge of translating theoretical data models into a working solution that enhances the Impact Framework and allows users to visualise the impact of software applications on water consumption was a major achievement for us.
We feel this addition to the framework will serve to enhance the case for the adoption of sustainable practices.
Learnings
Although all team members had taken the GSF/LF green software course, none had any practical experience with SCI or the Impact Framework and this hackathon has helped them gain real practical experience of the concepts and product. As one of our team members said -- "I've started thinking about carbon every time I write code."
Because the team had chosen a beyond carbon target we ended up thinking about broader sustainability topics such as the impact of excessive water use on different countries around the world. Addressing the use of water during power generation pointed out some of the complexities of attempting to make sustainable choices -- for instance all forms of power generations use some water, so no matter how low carbon the grid you can only reduce water consumption by reducing demand.
Finally, we learned the importance of good data -- much of it is still to be made available.
What's next?
Our solution represents one way of implementing a scoring mechanism for the impact framework. The RAG plugin could be extended or modularised to produce scores for other types of sustainability targets. It could also become more of an exhaust plugin, producing data that can be directly consumed by 3^rd^ party dashboard or visualisation tools.
The problem of setting appropriate rating thresholds for what could be a wide variety of loads and architectures seems difficult to solve -- we have sidestepped this by allowing user input that could be refined. It's possible that data produced by IF could end up being analysed to produce a more dynamic and realistic mechanism for deciding what is a sustainable score, or alternatively future designers could decide to code to sustainability NFRs, e.g.,no user request should ever create more than 1g of CO2eq or consume more than 5ml of water.
Finally, we would like to progress with our SWI plugins to include embedded water use -- both in the creation of datacentres and even the power generators themselves as only through thorough measurement can the true impact of software be highlighted.