Most software that runs on university clusters is written by the people doing the science. A survey of UK researchers found that 92% use research software, 69% say their research would not be practical without it, and 56% develop their own. Of those who write code, 21% had no training in software development at all.
A computational chemist, a population modeller or a particle physicist is paid to produce results, not tidy code. Scripts are written under deadline, extended by the next student, and run until the paper is out. Efficiency, error handling and testing come a long way down the list, and the code is often treated as disposable even when it is reused for years.
On a laptop, slow code wastes an afternoon. On a high-performance computing (HPC) cluster it wastes energy, and it wastes a resource that other researchers are queuing for.
Two failure patterns are common. Jobs fail part-way through, because of an unhandled edge case, a memory limit or a bad input, and have to be fixed and resubmitted. Other jobs never finish cleanly: they loop, stall or run far past their useful point until they hit a wall-clock limit or an operator kills them.
The scale of this is measurable. A study of SURF Lisa, a Dutch national cluster used by universities, found that although most submitted jobs completed, about half of the cluster's energy was spent on jobs that ended unsuccessfully: failures, timeouts, out-of-memory errors or node faults. Not all of that is waste, since a timed-out job may have saved useful output, but the authors see "huge potential for energy savings", for example "by analyzing jobs more intensively before submission".
The authors of the Green Algorithms framework make a related point: computations are rarely performed only once, and limiting the number of times a power-hungry algorithm is run "is perhaps the easiest way to reduce carbon footprint". A job that fails and is resubmitted three times has, in effect, run four times.
Inefficient jobs that do complete carry a quieter cost. They run longer than they need to, so each result takes more energy, and the queue behind them moves more slowly. On a shared facility, throughput and energy are the same problem.
National facilities already measure this. ARCHER2, the UK national supercomputing service, draws about 2.8 MW under load, 85% of it in its 5,860 compute nodes, and its Slurm scheduler records the energy each job consumed, so a user can look it up after the run. Operators have also pulled the levers they control. In December 2022 ARCHER2 capped the default CPU frequency at 2.0 GHz: three of four benchmarks ran 1–5% slower and used 13–20% less energy.
ARCHER2 runs on certified renewable electricity, so its documentation reports zero operational emissions, but it still attributes the embodied carbon of its hardware to every unit of compute used. A node-hour spent on a failed job carries that carbon whatever the electricity supply. With the hardware and configuration levers largely pulled, the code is what remains.
Universities have responded by employing research software engineers (RSEs), specialists who sit between researchers and the machine and improve code before it goes into production. The same community builds shared tools: the Climate-Aware Task Scheduler, which times cluster jobs for lower-carbon electricity, came out of a Software Sustainability Institute workshop.
Expert review works. The EU's Performance Optimisation and Productivity Centre of Excellence assesses parallel codes from academia and industry. For RoSSBi-3D, an astrophysics code for simulating protoplanetary discs, its audit was the first time any performance tool had been run on the code. It found thousands of tiny messages between processes and too little parallelism; once these were fixed, the code ran 4.9 times faster on 576 processes.
It does not scale easily. There are far fewer RSEs than research groups, each review takes time, and an RSE's attention usually goes to the largest or most visible projects. The long tail of scripts written by individual students and postdocs, which is where many failed and wasteful jobs come from, rarely gets looked at.
A data centre's power usage effectiveness (PUE) is its total energy divided by the energy used by the computing equipment. Energy spent on computation ends up as heat, and cooling that heat is most of the overhead. So a kilowatt-hour saved at the server also removes some cooling load.
Take a modern, liquid-cooled facility with a PUE of 1.1. About 91% of its energy goes to compute (1 ÷ 1.1) and about 9% to overhead. If around four-fifths of that overhead is cooling, cooling is roughly 7% of the site's energy. Now cut the energy of the jobs by 20%:
In other words, every 100 kWh taken out of the computation saves around 108 kWh at the meter. The multiplier grows with PUE. Uptime Institute's survey data shows the industry average PUE has sat between 1.55 and 1.59 since around 2020. At a PUE of 1.58, if the overhead falls in proportion to the load, 100 kWh saved at the servers is 158 kWh saved at the meter. In practice part of the overhead is fixed, so these figures are an upper bound on the cooling effect, but the direction is clear: the less efficient the building, the more a software saving is worth.
As for the size of the software saving, the literature on refactoring for energy reports 10–30% from ordinary code improvement, before any energy-specific optimisation. That range comes from general software, not HPC codes specifically, and GreenCode has not yet published measured results for research software.
The hardware side of HPC has been optimised for years; the Green500 has ranked supercomputers by energy efficiency since 2007. The software that runs on them has had far less systematic attention.
One approach GreenCode is exploring is to check and improve code before it reaches the scheduler: a gate at which a job's code is analysed for likely failures and obvious inefficiencies, energy is estimated, and a reviewed, improved version is offered back to the researcher. Correctness comes first, because an optimisation that changes the science is worse than none, so the scientist stays in charge of what is accepted. Tools such as the Green Algorithms calculator already let researchers estimate a job's footprint, and workflow managers are starting to report it per task, as the nf-co2footprint plugin does for Nextflow pipelines. The step GreenCode is working on is to go from estimate to change. The project's wider aims for research computing are set out on the improved scientific computation page.
Research communities tend to be siloed by discipline, but their code is not. Chemists, physicists, biologists, engineers and social scientists all write nested loops over large arrays, read and write files inefficiently, and allocate memory they never release. A pattern found and fixed in one discipline's code is often present in another's. An automated pipeline that learns from each fix can carry that knowledge across fields in a way that individual RSEs, working project by project, find hard to do.
The research community is already moving. In the UK, the Net Zero Digital Research Infrastructure scoping project set out more than 180 recommendations for reaching net zero by 2040, including a body of green software engineering expertise with "training, developing tools, metrics, expert assessment, and standards to transform current approaches to writing code". The GREENER principles set out how computational science can become environmentally sustainable, from governance and estimation to education, and the Green DiSC certification gives research groups and computing teams a practical route to follow. Improving the code itself, before it runs, is a natural complement. More background is on our climate case and further resources pages, and the project's plans for scientific and HPC computing are on the future of GreenCode.
If you run a research computing service or write code for one and would like to explore this with us, please get in touch.
