1
Ichnos+: Estimating the Carbon Footprint of Scientific Workflows Using Fitted Power Models
arXiv:2607.10586v1 [cs.DC] 12 Jul 2026
Kathleen West∗ , Youssef Moawad∗ , Philipp Thamm† , Vasilis Bountris† , Giulio Attenni‡ , Magnus Reid∗ , Yehia Elkhatib∗ , Lauritz Thamsen∗ ∗ University of Glasgow, United Kingdom † Humboldt-Universität zu Berlin, Germany ‡ Sapienza University of Rome, Italy
Abstract—As data-intensive scientific workflows scale to facilitate the automation of analysis of increasing amounts of data, their resource-intensive and long-running execution incurs significant energy consumption and carbon emissions. Given the already significant and rising emissions from the ICT sector, it is crucial to quantify and understand the carbon footprint of scientific workflows. However, existing tooling is commonly not usable in shared, virtualized environments or resorts to power models that are based on only one or two generic data points. To address this gap, this paper presents Ichnos+, a novel system to quantify the environmental footprint of Nextflow scientific workflows. Ichnos+ enables post-hoc footprint estimation based on existing workflow traces, node-specific power models for the computational resources utilized, and carbon intensity data aligned with the execution time. We evaluate Ichnos+ against hardware-level energy measurements obtained using Intel RAPL, and the nf-core co2footprint plugin, which implements the Green Algorithms methodology. We find that Ichnos+ is capable of estimating workflow energy consumption with an estimation error of 10.8% across three compute clusters, significantly outperforming the nf-core plugin. We further show that Ichnos+ extends beyond operational carbon to estimate embodied emissions as well as water and land use. Finally, we demonstrate how Ichnos+ can be extended for another workflow system, Apache Airflow, maintaining a similarly high degree of estimation accuracy. Index Terms—scientific workflows, cluster computing, carbon footprint, energy estimation, sustainable computing
I. I NTRODUCTION Scientists in many fields, including genomics, materials science, and remote sensing, need to analyze increasing amounts of data [1]–[4]. Scientific workflow systems facilitate the automation of such analyzes, enabling scientists to compose pipelines out of black-box tasks with data dependencies between them. Because these workflows are often used to process large quantities of data, they tend to be resource-intensive and long-running, leading to significant energy consumption and, therefore, carbon emissions. Indeed, the growing popularity of big data applications has been identified as a driver of the increasing emissions of the ICT sector [5], [6]. Scientific workflow systems such as Nextflow [7] allow for the design, execution, and monitoring of workflows on heterogeneous clusters. While these systems usually generate detailed performance traces and logs for executed workflows, they do not produce a record of the energy consumed and carbon emitted or other connected environmental impacts.
Consequently, users must manually monitor power consumption with hardware/software power meters or, otherwise, use a methodology like Cloud Carbon Footprint(CCF)1 or Green Algorithms (GA) [8]. In practice, monitoring power consumption requires the user to obtain physical access to attach a power meter or sufficient privileges to enable a software-based tool like Intel’s Running Average Power Limit (RAPL) prior to executing a workflow. Without this step, power consumption can only be estimated based on coarse-grained utilization averages. This is possible using the CCF and GA methodologies, though at reduced accuracy. The GA methodology relies on vendor-specified Thermal Design Power (TDP) of assigned compute resources, a proprietary metric that does not reflect key processor settings, such as processor frequency, and does not indicate idle power consumption. Meanwhile, the CCF methodology builds a linear power model between the power consumption measured or estimated at 0% and 100%; however, the approach also only uses two data points and does not reflect CPU processor settings. In either case, to translate the energy consumed into carbon emitted, users need a measure of carbon intensity (CI), such as a yearly average or a more fine-grained metric. Generally, CI measures the amount of carbon (CO2 e) produced per kilowatt-hour (kW h) of electricity consumed, and varies across different locations, seasons, and times, depending on the sources generating electricity and the demand on the grid. To address these limitations, we developed Ichnos+, a trace-driven and resource-aware system for estimating the carbon footprint of Nextflow workflows. First, Ichnos+ takes as input the automatically generated workflow trace produced by Nextflow. The use of these traces ensures that users do not need to manually monitor power consumption, enabling the analysis of any previously executed Nextflow workflow. Next, Ichnos+ enables users to automatically fit a device-specific, upto-date linear power model for utilized compute resources to accurately reflect processor settings. Finally, Ichnos+ converts the estimated energy consumption to overall carbon emissions using high-resolution time-series CI data for each workflow task and only resorts to coarse-grained yearly averages where location-specific CI time series data is not available. Ichnos+ also reports estimated energy consumption and carbon emissions per workflow task, providing greater granularity than 1 https://www.cloudcarbonfootprint.org/docs/methodology/
For the purpose of open access, we have applied a Creative Commons Attribution (CC BY) license to this version of our paper.
2
existing methodologies, and allows users to identify which of their tasks have the largest footprint to address. Given that energy consumption and compute infrastructures have an additional impact on water consumption and land usage, as well as producing embodied carbon emissions, these factors must be considered when evaluating the environmental burden of scientific workflows. Therefore, Ichnos+ can be configured to provide estimates for workflow embodied carbon emissions, as well as water and land use. Building on previously presented preliminary results [9], this article contributes: • An extended design and implementation of Ichnos+ as open-source software2 featuring new functionality to estimate embodied carbon emissions, water and land use (§III) from workflow traces, energy mix data, and infrastructure metrics; 3 • An expanded evaluation , assessing the accuracy of the automated power models generated with Ichnos+ to estimate energy consumption, including a comparison of energy estimations with RAPL and the nf-co2footprint plugin as a baseline methodology using traces from six real-world Nextflow workflows (§IV-B – §IV-D), additionally showing the system’s capability to quantify environmental impacts, namely operational emissions (using both average and marginal CI), embodied emissions, land use, and water use (§IV-F); • A demonstration of system extensibility beyond Nextflow to the Apache Airflow workflow system, detailing the integration process and comparing energy consumption estimates against RAPL (§IV-E). II. BACKGROUND A. Scientific Workflows Scientific workflows automate data analysis processes that support a scientific objective. They are often defined in terms of their tasks and data dependencies, and are represented using directed acyclic graphs, or as pipelines. Figure 1 represents a scientific workflow with seven tasks (A–G) and the dependencies between them. The tasks that form a workflow are considered black-box processes, receiving input from one or more previous tasks, undergoing some processing, and producing output to send on to subsequent tasks. For example, Tasks B and C can only start after receiving input from Task A. As tasks are individual processes, both tasks B and C could run in parallel if there was sufficient capacity. 2 https://github.com/GlasgowC3lab/ichnos 3 https://github.com/GlasgowC3lab/ichnos-results-evaluation
B
D
B. Carbon Intensity Signals The carbon intensity (CI) of electricity measures carbon dioxide equivalent released per unit of energy produced. Generating energy from renewable energy sources such as wind or solar reduces CI. CI also typically decreases during periods of time when the demand on the grid is low. In this work, we use grams of carbon dioxide equivalent per kilowatthour (gCO2 e/kW h) to measure CI. CI can be quantified using two signals: average and marginal. Average reflects the overall grid emissions at the time when electricity is requested, factoring in each energy source’s relative share and emission rate. Marginal measures the emissions of the specific energy sources used to meet additional load at the time when electricity is requested. While marginal CI is in theory preferable for measuring the impact of demand shifting, average CI is more readily available and used for emissions accounting. Moreover, average and marginal CI are available at different levels of granularity, such as yearly averages, hourly values, and 5/15/30-minute values. Given that grid energy mixes are changing continuously, we recommend that users select the most granular time and location specific CI signal, whether that is average or marginal. In addition to using CI signals to quantify the operational carbon emissions, the embodied carbon emissions are also often significant and must, consequently, be understood as well. Embodied emissions refer to all emissions associated with the manufacturing and life-cycle of physical compute hardware, including end-of-life activities like device disposal. These emissions are typically estimated as part of a Life Cycle Assessment (LCA) [10], and measured in kgCO2 e. The embodied carbon emissions for a certain compute workload can be attributed by using the ratio of a workload’s runtime and the device’s expected lifetime, which we take to be 4 years for CPUs, as per the CCF methodology1 . However, LCA data on compute devices are not always available and the device’s expected lifetime can also only be estimated. C. Land Usage and Water Intensity Signals
G
A
Dedicated resource usage data could therefore be generated for each task, such as its runtime, status, and resource utilization on the compute resource it was executed on. Scientific Workflow Management Systems (SWMS), such as Nextflow and Pegasus, enable scientists to design, execute, and monitor workflows on heterogeneous infrastructure. A key feature of such platforms is the generation of performance traces at the individual task level. Similarly, general-purpose workflow systems, like Apache Airflow, operate pipelines formed of interdependent tasks, though not necessarily designed for scientific applications.
E C F
Fig. 1: Simple representation of a scientific workflow, composed of seven tasks (A–G).
In order to reflect the water and land usage of executing a workflow, we must consider both the water and land required to generate the electricity consumed by the workflow execution as well as the water and land needed by the data center where the workflow was executed. Over time, the electricity generated by a grid is produced by a changing mix of energy sources, all of which have different
3
energy water intensity factors (EWIF) and energy land usage intensity factors (ELIF). Each source can be retrieved from data on an electricity grid’s energy mix, allowing to factor in the relevant EWIF and ELIF factors for each source proportionally while computing the average water and land intensity factors over time, measured in liters of water per kilowatt-hour (l/kW h) and square meters per kilowatt-hour (m2 /kW h), respectively. Furthermore, the data center where workflows are executed exhibits its own water and land footprints [11]. The Water Usage Effectiveness (WUE) factor is defined as the ratio of the water consumed by the data center to its IT energy consumption, expressed in liters per kilowatt-hour (l/kW h). Similarly, the Land Usage Effectiveness (LUE) factor represents the ratio of total land occupied by the facility to its IT energy consumption, expressed in square meters per kilowatt-hour (m2 /kW h). III. S YSTEM D ESIGN We now discuss the requirements for the design of Ichnos+ and provide an overview of the estimator system’s design. A. Requirements We identify the following requirements from which we derive the design of Ichnos. a) Enable post-hoc estimation: Ichnos+ enables footprint estimation after workflows have been executed. This lets users analyze the carbon footprint of previous and new experiments, from executions that may have occurred on local devices, clusters, and cloud infrastructure. Given this, users may no longer have access to the infrastructure used to execute workflows, whether the devices were replaced, or only temporarily booked in a cloud environment. b) Use resource utilization data: Resource utilization monitoring is often more readily available than power monitoring. Users, for example, typically lack access to power monitoring tools in shared cloud environments. Also, users may not have configured power monitoring when workflows were executed, but will often still have access to monitoring data. Hence, Ichnos+ uses existing workflow traces that contain task-level resource usage data, without energy measurements. c) Estimate CPU and Memory Energy Consumption: Ichnos+ focuses on the energy consumption of CPU and memory, as these components typically exhibit the widest dynamic power consumption ranges attributable to specific load on compute resources [12]. We focus on CPUs and do not consider GPUs, since workflow systems like Nextflow typically focus on executions on CPUs. In addition, workflows are often executed on shared and distributed resources, where storage access may not be limited to the nodes on which workflow tasks are executed, yet workflow traces are commonly limited to resource usage by tasks on specific nodes. d) Estimate Operational and Embodied Carbon Emissions: Ichnos+ estimates both the operational and embodied carbon emissions. By default, it will make use of electricity grid emissions data like the average and marginal CI for operational emission estimations. In contrast, users can choose
to also estimate embodied emissions, with hardware LCAs detailing embodied carbon emissions less widely available than CI data. e) Estimate Workflow Carbon Footprint: Many workflow traces are produced for individual workflow runs and offer no insight into other processes running on the same machines. We, therefore, rely on the generated workflow traces for accounting for the correct shares of an overall system. f) Estimate Water and Land Use: Once workflow energy consumption has been estimated, users can choose to also estimate water and land use by configuring the respective intensity factors, based on the energy mix in the utilized region. g) Extensibility: While Ichnos+ was developed to estimate the environmental footprint of Nextflow workflows, the system is intended to be extensible, allowing for the footprint of applications implemented using other workflow systems to be estimated. Though, resource utilization monitoring is required for systems that do not log this information themselves. We provide functionality to integrate other systems and demonstrate how Ichnos+ can be extended, using the example of Apache Airflow workflows. B. System Overview Ichnos+ (Figure 2) is a system that produces an estimate of the operational end embodied carbon emissions from the execution trace of a Nextflow scientific workflow using power and energy data aligned with the execution. Ichnos+ can also be used to calculate estimates for water and land use. Footprint Estimation
Input Data
Reporting
Ichnos Workflow Trace 1
2
Augmented Workflow Trace
Compute Resource Power Model
70% 35% idle
Energy Consumption (CPU + Memory)
100%
Carbon Intensity Time Series
sum
4
CO2
CI
3 ...
(Optional) Embodied Carbon Data Land + Water Use Factors
8am
10am
Embodied Carbon Footprint
CO2 server sum
...
Carbon Footprint
land
water
200 kg 10m2
1L
CO2 Land + Water Use
Fig. 2: High-level design of the Ichnos+ Carbon Footprint estimator system with per-task power and emissions estimation, based on provided input data, and detailed impact reporting. First, the user must provide certain Input Data: 1) A workflow trace containing a task-level summary of resource usage including execution runtime, CPU utilization, and allocated memory; 2) The power model selected to estimate the power consumption, which can be either an automatically generated power function or a regression-based model configured to reflect processor settings; and
4
3) CI data supplied as fine-grained time-series data, if available, or as a coarse-grained average. 4) (Optional) The embodied carbon emissions of utilized compute and memory resources, alongside the water and land use factors specific to the region where the workflow was executed. Next, during the Footprint Estimation phase, resource usage data are extracted from the workflow trace for each task, and the energy consumption is estimated using the selected power model. Subsequently, the energy consumption per task is translated into carbon emissions using the provided CI data. This estimates operational carbon emissions by aligning the tasks of potentially long-running workflow applications with CI data matching the specific execution times. These estimations are summed to calculate the power consumption and carbon emissions for the overall workflow execution. Finally, during the Reporting phase, the energy consumption and carbon emissions estimated for each task are summarized in a trace file, alongside a summary of the overall carbon footprint. When enabled, the embodied carbon emissions, as well as water and land use are also reported in Ichnos+ summary file, allowing users to better understand the environmental impact of their workflow executions. We also identify the 10 most energy-intensive and the 10 longest-running workflow tasks, allowing users to review their relative emissions, and to consider the potential of aligning tasks with fluctuating CI – applying existing carbon-aware methods to reduce the overall footprint [13]–[15]. C. Automated Power Modelling Ichnos+ supports generating power models for utilized compute resources in an automated manner, selecting the most accurate available model based on automated readings over different levels of resource utilization as depicted in Figure 3. Power Model Generation - stress test and measure energy (0-100%) Compute Resource Power Model Power Turbostress Power Stress-NG idle
100%
CPU Utilisation
idle
100%
Memory Utilisation
Fig. 3: Overview of automated power modelling in Ichnos+. Approach. The estimator system contains scripts which are used to take node-specific power measurements. First, several measurements of the energy consumed by the CPU are obtained by stress-testing the CPU using the Turbostress4 tool. Ichnos+ has a default setting of 11 measurements, adjusting CPU load from 0% (idle) to 100% (max) in 10% increments. These measurements should ideally be taken at the time of execution, on the compute resources where workflows were executed, so they reflect the current processor settings such as the governor selected (which decides how the CPU frequency 4 https://github.com/teads/turbostress
is adjusted based on CPU demand) on each node. Next, similar measurements of the energy consumed by memory are taken using the stress-ng tool5 , varying memory load from 0% (idle) to 100% in 10% increments like CPU. Typically, memory energy consumption does not increase linearly as the load increases, and, instead, the power draw over time is relatively constant when load is applied, only differing between the readings at 0% and with load [12]. Once the CPU and memory have both been measured, a power model is generated by fitting a linear model from the CPU energy consumption readings, while a constant is taken from the memory readings, averaging over the measurements taken with load. The power modeling phase should be repeated at regular intervals through compute resource lifetimes as well as when hardware is changed, to account for altered device performance. We evaluate the accuracy of Ichnos+’s power model generation in Section IV-B. In the scenario where users estimate energy consumed by a historical workflow, executed on resources that they no longer have access to, or on public cloud resources, or anywhere else where a user cannot execute the energy measurements script – Ichnos+ has the fallback option of using a linear power model, or if only the CPU model is known, a per-core value based on vendor-specified TDP. Both these fallbacks are used in existing estimation methodologies, like GA [8] and CCF1 , and can offer ballpark estimates of the energy consumption to then translate into carbon emissions. Similarly, the memory energy consumption coefficient in Ichnos+ can default to a constant conversion factor, as used in existing estimation methodologies. Estimation of CPU Energy Consumption. When estimating the CPU energy consumption, Ichnos+ uses a linear power model in the form: P = ∇node (CP Uusage ) + idlenode
(1)
Nextflow scientific workflows can run workflow tasks on multiple nodes, with many nodes running tasks in parallel on the same node. When using a linear power model, each task is responsible for their own dynamic power consumption, that is, their share of the over all system CPU usage (CP Uusage ), which is calculated for each task by Ichnos. However, when tasks run in parallel, they are all partially responsible for idle power consumption, using the idlenode value – this must only be added once, over the periods of time when a node is running one or more tasks. In our work, we assume that users have reserved the compute nodes where the workflow was executed, so they would be responsible for the idle system load. If this was not the case and users had, for instance, access to 50% of the resources of a node, they could adjust the idlenode value to be half of the system’s idle power consumption. Therefore, the overall CPU energy consumed by an individual compute node is, where t represents the time: X E= ∇node (CP Uusage ) ∗ ttask + idlenode ∗ tnode (2) tasks
where we sum each task’s dynamic energy consumption, with the idle energy consumed by the node when active. 5 https://github.com/ColinIanKing/stress-ng
5
This approach requires a reliable estimation of the average CPU usage for each task. We use the CPU utilization as reported by Nextflow. Nextflow calculates the average CPU utilization of a physical workflow task by reading the total CPU time used by all waited-for child processes from /proc/$pid/stat and dividing it by the total CPU time used by all processes during task execution6 . Since the calculation is based directly on data derived from system performance counters provided by Linux, the accuracy of the resulting CPU usage estimation depends on the accuracy of these counters. In practice, prior research shows that Linux hardware performance counters are typically very accurate, with reported observed errors of less than 0.002% across multiple workloads and CPU models [16]. Estimation of Memory Energy Consumption. When estimating memory energy consumption, Ichnos+ uses a constant, measured, coefficient: E = t ∗ memsize ∗ memcoef f
(3)
Specifically, memory energy consumption can be estimated in two ways. To provide task-level estimates of memory energy consumption, we set memsize as the amount of memory allocated to a task, and set t as the task’s runtime. This approach provides granular task-level estimates, but it can underestimate node-level memory energy for CPU-intensive workflows in which memory is not well utilized, e.g. only 30% of available memory is allocated to the workflow. Since the power consumed by the node memory is fairly constant, regardless of the exact overall memory utilization, the sum of task memory energy consumption will be significantly less than overall node memory energy consumption in these situations. We also note that RAPL readings of memory energy consumption are for the entire node, regardless of whether it is shared or not, meaning that comparing node memory energy consumption would provide a better comparison with RAPL. For this reason, Ichnos also provides a node-level estimate of memory energy consumption, setting memsize to the amount of memory available on the node, and set t as the time that a node is running one or more tasks. This approach captures the node memory consumption regardless of how heavily it is utilized. However, this means that individual tasks that are more memory-intensive cannot be identified. Ichnos+, consequently, reports both of these values, with task-level estimates provided in the output trace file, and the summed task estimates in the summary file. The summary file also contains the total node-level estimate of memory energy consumption, allowing for the user to understand their overall memory energy consumption, and to identify memoryintensive tasks. D. Environmental Impact Reporting Ichnos+ offers human-readable files to quickly understand the footprint of a workflow for general reporting. It also produces computer-readable files as an augmented trace file 6 https://github.com/nextflow-io/nextflow/blob/master/modules/nextflow/src/
main/resources/nextflow/executor/command-trace.txt
where the energy consumption and carbon emissions of all tasks are reported. This is provided to enable scientists to better understand their workflow’s footprint, and identify the heavyhitting tasks that may be disproportionately contributing to the overall footprint. E. Extensibility of Ichnos+ for Other Workflow Systems While the Ichnos+ estimator system was developed for the Nextflow SWMS, we believe that our approach can be applied to other workflow systems. For this, we must have the following information available for the workflow execution to make estimations: • at task-level: the runtime, CPU utilization, allocated no. of cores, and the amount of memory assigned to each task, and the compute node utilized • at node-level: the generated power model, measured memory coefficient, the no. of CPU cores and total available memory, and details of the CPU model and RAM utilized if estimating embodied carbon emissions • at cluster-level: the region where cluster nodes are located With all of the required information, an Airflow workflow trace can be created, reporting this information for every individual task. Given that this is not automatically produced by Airflow, a provenance management system, HyProv [17], was used as an additional system to create the traces needed. We then developed a template script to convert all Airflow task records into Ichnos+ trace records, AirflowTraceToIchnos7 . This script can be used as a basis for other systems when converting from one trace format to another. IV. E VALUATION In this section, we present: • The experimental setup that we used to evaluate Ichnos; • An analysis of the accuracy of the system’s generated power models for estimating power consumed during workflow execution; • An analysis of the accuracy of workflow energy consumption estimations, compared against ground truth energy measurements and a baseline, the nf-co2footprint plugin8 ; • An analysis of the accuracy of workflow energy consumption estimations for the Airflow workflow system, comparing against ground truth energy measurements; • A demonstration of Ichnos+ being used to estimate the embodied carbon, water, and land impacts of workflow executions. A. Experimental Setup We use ground truth data, a baseline, multiple workflows and infrastructures, as well as water and land use factors for our experiments as described here. Comparison with Ground Truth and Baseline Method. To evaluate the accuracy of our approach when estimating energy 7 https://github.com/GlasgowC3lab/ichnos/blob/main/src/scripts/ AirflowTraceToIchnos.py 8 https://github.com/nextflow-io/nf-co2footprint
6
TABLE I: The compute nodes used in the study. Hardware Intel Xeon E5-2640 v2 (x2) Intel Xeon Gold 6426Y Intel Xeon Silver 4314 Intel Xeon Platinum 8275CL
Memory (GB) 64 128 256 192
Type Cluster Cluster Cluster AWS
consumption we compare all estimates against hardware-level measurements taken using Intel’s RAPL, which we consider to be the ground truth throughout our experiments. We additionally evaluate our approach by comparing against the nf-co2footprint plugin, which implements the GA methodology [8]. GA uses the manufacturer-specified processor TDP to estimate per-core energy consumption. The nf-co2footprint plugin has been accepted by the nf-core community and is the official Nextflow plugin for estimating carbon emissions. Workflows. To evaluate our system, we used six real-world workflows from the nf-core repository9 , a community-curated collection of workflows implemented using Nextflow [18]. We selected the Atac-Seq, Chip-Seq, Nano-Seq, RNA-Seq and Sarek bioinformatics workflows, all of which rank within the top 10 most popular workflows in nf-core, to represent typical domain usage of Nextflow. We also selected Rangeland to represent another scientific domain, namely earth observation. We manually executed the workflows to produce experimental data with RAPL energy consumption measurements. Infrastructure. Throughout our evaluation, we use the following compute nodes, which are described in Table I and are part of three clusters. In particular, the experiments in Sections IV-C and IV-D set up Kubernetes clusters on these compute nodes and use a Ceph PVC to run Nextflow. Carbon Intensity Factors. We retrieve average CI data from ElectricityMaps10 , marginal CI data from WattTime11 and LCA factors for embodied carbon from the Boavizta API [19]. Water and Land Use Factors. We retrieve historical data of the electricity grid’s energy mix for the regions where the compute clusters are located from ElectricityMaps10 . We combined these with carbon intensity coefficients taken from the IPCC [20] report and [21], EWIF coefficients from NREL [22], and ELIF coefficients from [23]. To estimate the water and land used by the data center, we must configure the WUE and LUE. These values might be known for larger data centers (such as AWS ones12 ), but are often unknown for smaller data centers. Therefore, we exemplify making a best guess, using a WUE of 1l/kW h, and a LUE of 5m2 /kW h. B. Power Modelling Accuracy We discuss the accuracy of Ichnos+’s generated power models, in relation to the actual energy consumption. Power Model Accuracy. For each available compute device, we took power consumption readings, as detailed in Section III-C for the CPU. We used these readings to generate linear and cubic regression models of consumed energy. 9 https://github.com/nf-core 10 https://www.electricitymaps.com/ 11 https://watttime.org/ 12 https://sustainability.aboutamazon.com/products-services/aws-cloud
150 Energy Consumption (W)
Node Glasgow-1* Glasgow-22 Berlin Dublin
Cores (#) 32 64 32 96
100
Nodes glasgow-15 glasgow-16
50 20
Model Fitted Cubic Fitted Linear Naive Linear Turbostress
10 0 10 20 30 40 50 60 70 80 90 100 Load (%)
Fig. 4: Power consumption versus relative load for Glasgow compute nodes utilizing the ondemand CPU governor. In Figures 4 and 5, we show plots comparing power models. The original Turbostress4 readings are marked on the plots. To these readings, Ichnos+ fits a linear model and a cubic model. We also plot a line that naively assumes linear scaling of power consumption from the readings at 0% (idle) and 100% (peak) utilization. In addition, we plot the memory energy consumption coefficient measured while varying memory load from 0% (idle) to 100% (peak) in the second row of the plot. Figure 4 shows that despite both Glasgow cluster nodes having identical hardware resources, their peak CPU power consumption varies substantially. At 100% utilization and under the same governor settings, Glasgow-15 reached ~140W while Glasgow-16 drew only ~110W , likely attributable to the age of the hardware. This ≈27% difference underscores the importance of node-specific power modeling grounded in actual measurements. Figure 5 shows readings for the Berlin cluster nodes. We compare power models generated for four compute nodes, using the governors: performance, powersave, schedutil and ondemand. This newer hardware shows far more consistent behavior, with most readings aligning with other nodes. It also reinforces that the selected governor impacts the power model, with the powersave governor consistently using less power at 100% utilization. We also observe that the measurements form more non-linear relationships, which highlights why linear models can be less than ideal. We calculated the Root Mean Square Error (RMSE) between the model predicted values and the energy consumption readings taken using Turbostress (which uses RAPL to take measurements), for the fitted cubic, fitted linear, and naive linear models. Across all nodes on both clusters, the fitted cubic model demonstrated superior accuracy, markedly outperforming fitted linear which, in turn, proved more accurate than the naive linear model. The fitted cubic model proved the most accurate when comparing model predictions and recorded readings. However, when we used the power models to estimate energy consumption for real Nextflow executions and reported the percentage error between the estimated and actual energy consumption of workflows, we found that the fitted linear model consistently outperformed the fitted cubic model. Given these results, we identify the following two drawbacks of using a non-linear model like the fitted cubic model: the impact of background load, and the reliance on coarse-grained CPU utilization data.
7
Energy Consumption (W)
performance 140 120 100 80 60 40 20 10
powersave
ondemand
schedutil
140 140 140 120 120 120 100 100 100 80 80 80 60 60 60 40 40 40 20 20 20 10 10 10 0 102030405060708090100 0 102030405060708090100 0 102030405060708090100 0 102030405060708090100 Load (%)
Nodes berlin-40 berlin-42 berlin-44 berlin-45 Model Fitted Cubic Fitted Linear Naive Linear Turbostress
Fig. 5: Power consumption versus relative load for Berlin cluster nodes utilizing different CPU governors.
Power Consumption (W)
80
gpgnode-22
gpgnode-13
C. Energy Consumption Estimates vs. Ground Truth Data
70 60 50 40 30 20 10 0 0 10 20 30 40 50 60 70 80 90 100
0 10 20 30 40 50 60 70 80 90 100
Load (%)
Fig. 6: Task power consumption under varying background system loads for Glasgow-22 (left) and Glasgow-13 (right).
Impact of Background Load. To enable trace-based resource estimations, we estimate the energy consumption for all individual tasks, considering each task’s share of utilized resources in isolation. This works well for several tasks running in parallel on the same shared compute resource only when we use a linear model. If we use a cubic model and consider a task that has an average CPU utilization of 100% on one core, its power consumption will differ depending on whether it runs on its own or shares resources with other CPU-intensive tasks. This effect can be seen in Figure 6, which shows the power consumption of the commonly used bioinformatics task FastQC13 at different system background loads. This task fully utilizes one core on each system. We can see that the power consumption is significantly affected by the background system load, and this is especially notable for Glasgow-22, which shows a large difference between 0–10% utilization. Reliance on Coarse-Grained CPU Utilization Data. Furthermore, the traces generated from Nextflow executions only provide a single coarse-grained CPU utilization average for each individual workflow task – even for tasks with a runtime spanning seconds to hours and markedly different utilization over time. Consequently, we recommend using the generated fitted linear model when estimating energy consumption to reduce the power modelling estimation error – compared to naive linear and TDP-based methods – and avoid the estimation being affected by background task utilization and how resource utilization data are aggregated. 13 https://github.com/s-andrews/FastQC
We executed several Nextflow workflows on three compute clusters and monitored the energy consumed using RAPL. We used Ichnos+ to generate estimations using fitted linear power models. For each cluster, we executed the workflow three times and report the energy measured and estimated for the median workflow run. We report the overall percentage error in the estimation made for the CPU, memory, and overall workflow energy consumption in Table II. In the table, we group our results into five groups, each presenting Ichnos+’ estimation and the RAPL measurement in kilowatt hours, before presenting the percentage error between them. Ichnos+ predicts the node’s overall CPU energy consumption, considering each task’s dynamic energy consumption summed with each node’s static energy consumption while workflow tasks are running, with a prediction error of 6.9±6.5 (p75 of 12.6, p95 of 17.2). Ichnos+ predicts the task memory energy consumption, considering each task’s assigned memory on each node over workflow execution, which does not consider the static energy consumed by memory. This was predicted with an error of 48.6 ± 15.5 (p75 of 60.5, p95 of 74.5). Ichnos+ also estimates the node memory energy consumption, considering the static energy consumed by the memory of each node used while workflow tasks are running. This had a prediction error of 11.5 ± 20.5 (p75 of 16.3, p95 of 56.8). Overall, when the predicted node CPU energy consumption is summed with the task memory energy consumption, and compared to RAPL’s total, workflow energy consumption was predicted with an error of 17.3 ± 8.3 (p75 of 22.9, p95 of 24.8). Meanwhile, when the predicted node CPU energy consumption is summed with node memory energy consumption, and compared to RAPL’s total, workflow energy consumption was predicted with an error of 10.8 ± 5.5 (p75 of 12.8, p95 of 15.3). We report both values, distinguishing between task and node memory, as they offer separate advantages. Using the task memory allows for task-level estimates to be made, allowing for tasks with significant memory requirements, and therefore energy consumption, to be identified by users. However, for workflows where some stages of execution have low levels of node memory utilization, like Atac-Seq, Nano-Seq or Sarek, task-level estimates may not capture overall node memory consumption well – which tends to be constant, leading to
8
TABLE II: Estimated energy consumption from Ichnos+ with fitted power models versus RAPL data (ground truth). Node CPU Ichnos+ RAPL Error Workflow (kWh) (kWh) (%)
Task Memory Ichnos+ RAPL Error (kWh) (kWh) (%)
Atac-Seq Chip-Seq Nano-Seq Rangeland RNA-Seq Sarek
0.47 3.53 0.34 1.56 1.71 3.83
0.47 4.12 0.34 2.00 1.99 4.40
-0.15 -14.4 -2.0 -22.3 -14.1 -12.8
0.03 0.30 0.02 0.17 0.15 0.16
0.06 0.54 0.06 0.25 0.24 0.62
-52.4 -44.1 -71.2 -30.5 -39.0 -74.8
Atac-Seq Chip-Seq Nano-Seq RNA-Seq
0.92 1.29 0.58 0.99
0.9 1.31 0.58 0.96
+1.96 -1.67 +0.89 +3.06
0.12 0.16 0.07 0.12
0.17 0.23 0.12 0.18
-31.06 31.85 -44.68 -35.99
Atac-Seq Chip-Seq Nano-Seq RNA-Seq
0.66 3.05 0.37 3.53
0.71 3.46 0.4 3.98
-7.06 -11.93 -6.75 -11.34
0.1 0.51 0.04 0.66
0.27 1.24 0.16 1.56
-61.06 -58.85 -74.3 -57.85
Total Total Node Memory (Node CPU + Task Memory) (Node CPU + Node Memory) Ichnos+ RAPL Error Ichnos+ RAPL Error Ichnos+ RAPL Error (kWh) (kWh) (%) (kWh) (kWh) (%) (kWh) (kWh) (%) Berlin Cluster 0.11 0.06 +79.8 0.50 0.53 -5.9 0.58 0.53 +9.4 0.53 0.54 -2.5 3.83 4.66 -17.9 4.06 4.66 -12.9 0.08 0.06 +44.5 0.35 0.40 -11.6 0.42 0.40 +5.0 0.26 0.25 +5.6 1.73 2.25 -23.2 1.82 2.25 -19.1 0.25 0.24 +4.3 1.86 2.23 -16.8 1.96 2.23 -12.1 0.54 0.62 -12.9 3.99 5.01 -20.5 4.37 5.01 -12.8 Glasgow Cluster 0.18 0.17 +4.0 1.04 1.08 -3.37 1.10 1.08 +1.85 0.24 0.23 +3.22 1.44 1.54 -6.2 1.53 1.54 -0.65 0.11 0.12 -10.11 0.65 0.7 -7.19 0.69 0.7 -1.43 0.19 0.18 +4.44 1.11 1.15 -3.16 1.18 1.15 +2.61 Dublin Cluster 0.23 0.27 -12.98 0.76 0.97 -21.85 0.89 0.97 -8.25 1.03 1.24 -17.05 3.56 4.7 -24.35 4.08 4.7 -13.19 0.11 0.16 -25.94 0.41 0.55 -25.64 0.48 0.55 -12.73 1.34 1.56 -14.02 4.19 5.54 -24.42 4.87 5.54 -12.09
significant underestimation. Here, it may make more sense to use node level memory estimates, which consider the entire node’s energy consumption while the overall workflow executes, leading to a reduced prediction error, and overall workflow energy predicted with slightly less variance. Overall, we observed that the majority of energy consumed by workflow executions was driven by the CPU, which typically consumed four times as much energy as memory. Impact of Background Energy Consumption. Given that scientific workflows are typically executed on shared infrastructure, or on Kubernetes clusters that require support software to run in the background to facilitate execution, additional energy is consumed. Since RAPL measurements are taken at a node-level, we cannot distinguish which processes are responsible for energy consumption without using some attribution-based approach, or attempting to monitor individual processes. We, hence, investigated the impact of background energy consumption for the Glasgow cluster. We compared our estimations of workflow energy consumption using two power model variations, one generated from measurements with the Kubernetes cluster running and one without. Table III shows our estimations made with no load on utilized nodes, and models configured with ‘background’ Kubernetes infrastructure, compared with RAPL readings. All values compared are the mean of three executions. Given that the power models generated with the Kubernetes cluster running lead to the lowest estimation error, we recommend that users of Ichnos+ should aim to use the most accurate power models available, i.e. training models with background infrastructure, such as Kubernetes clusters already running. If this is not possible, useful estimations can still be made, as estimates are still close to RAPL ground truth data.
D. Comparison with Baseline Methodology We compare Ichnos+ predicted workflow energy consumption with the estimation made by the nf-co2footprint plugin8 , and the measured energy consumption using RAPL.
TABLE III: Ichnos+ energy consumption estimates on the Glasgow Cluster, comparing power models trained with and without background load. Workload RNA-Seq Atac-Seq Chip-Seq Nano-Seq
RAPL (kWh) 1.15 1.08 1.54 0.69
Ichnos+ (no load) (kWh) (%) 1.23 +7.23 1.13 +4.79 1.61 +4.89 0.71 +2.69
Ichnos+ (background) (kWh) (%) 1.17 +2.16 1.10 +1.83 1.54 -0.04 0.68 -1.82
In Table IV, we show the total energy consumption estimated using Ichnos+ and nf-co2footprint in comparison to RAPL for the median of three executions. We also show the percentage error between these values, with the best performing method highlighted in green and bold. The nfco2footprint plugin only estimates dynamic energy, without the idle power consumed by CPU and memory. We, hence, manually measured the idle power consumption by reading RAPL counters for each node, and sum it with the dynamic energy for the overall comparison. We also report the average absolute mean error for Ichnos+ and nf-co2footprint for each cluster infrastructure. On the Glasgow cluster, Ichnos+ consistently outperforms the plugin which tends to overestimate energy consumption. Ichnos+ mean error is <2% while nf-co2footprint has a 22% error. On the Berlin cluster, the plugin slightly outperforms Ichnos+ for four workflows, with Ichnos+ significantly outperforming on the other two. We found the Ichnos+ mean error of 12% remained lower than nf-co2footprint’s 17% error for this cluster. Finally, on the Dublin cluster, Ichnos+ consistently outperforms the plugin, which tends to underestimate energy consumption. Ichnos+’s mean error is 12% while nfco2footprint has a 35% error. We conclude that using an approach that relies solely on the TDP of utilized processors, which do not reflect processor governor settings or variations in the performance of heterogeneous cluster nodes and further does not capture idle power draw, is less accurate than using fitted power models, as Ichnos+ clearly outperforms the nf-core plugin across all
9
TABLE IV: The estimated energy consumption using Ichnos+ compared with nf-co2footprint plugin, against RAPL ground truth data. The smaller error is highlighted in bold. Workload
RAPL (kWh)
Atac-Seq Chip-Seq Nano-Seq RNA-Seq Average
1.08 1.54 0.70 1.15
Atac-Seq Chip-Seq Nano-Seq Rangeland RNA-Seq Sarek Average
0.53 4.66 0.40 2.25 2.23 5.01
Atac-Seq Chip-Seq Nano-Seq RNA-Seq Average
0.97 4.70 0.55 5.52
Ichnos (kWh) (%) Glasgow Cluster 1.10 +1.85 1.54 0.00 0.68 -2.86 1.18 +2.61 1.83 Berlin Cluster 0.58 +9.43 4.04 -13.30 0.42 +5.00 1.81 -19.56 1.96 -12.11 4.38 -12.57 11.99 Dublin Cluster 0.89 -8.25 4.06 -13.62 0.48 -12.73 4.86 -11.96 11.64
nf-co2footprint (kWh) (%) 1.30 1.92 0.83 1.42
+20.37 +24.68 +18.57 +23.48 21.77
0.40 4.22 0.28 1.83 2.05 4.43
-24.53 -9.44 -30.00 -18.67 -8.07 -11.58 17.05
0.66 3.04 0.33 3.70
-31.96 -35.32 -40.00 -33.06 35.09
three tested cluster environments. E. Extension of Ichnos+ for Airflow Workflows Ichnos+ requires task-level metrics, but as Airflow does not natively record resource utilization per task, we integrated HyProv [17], a provenance management system capable of capturing execution metrics from the underlying infrastructure. With it, using the relevant APIs, we extracted the hostname, CPU, and memory consumption of each task. We manually captured hardware level information. We then developed a conversion script to map these into the explicit data format required by Ichnos. To evaluate the accuracy of the Ichnos+ estimation method when extended to a new system, we developed benchmark workflows on Airflow. The benchmark workflows utilized the sysbench framework14 , containerized, structured as four sequential groups of four concurrent tasks. Each task was set to last 10 minutes, yielding a 40-minute total runtime per benchmark workflow. We configured the resource intensity across three distinct tiers (High, Medium, and Low). CPU utilization was enforced using Kubernetes quotas (4.0, 2.0, and 0.5 cores, respectively). To configure memory usage, we managed both the static memory allocation and the active memory traffic. First, we instructed the tasks to allocate a fixed amount of RAM (2048 MB, 1024 MB, and 128 MB) for the duration of the run. Second, to use the memory bus, we configured the tasks to continuously perform random memory writes to this allocated space. Across all configurations, we allowed these write operations to execute continuously as fast as the underlying hardware permitted. We monitored the real energy consumption using RAPL and compare the estimations with the results in Table V. When using a fitted linear power model, energy consumption 14 https://github.com/akopytov/sysbench
TABLE V: Estimated energy consumption for benchmark Airflow workloads using Ichnos+ compared to RAPL, I=Ichnos, R=RAPL, E=Error. Selected Fitted–Linear Model for CPU. Workload CPU Mem High High High Med Med High Med Med Low Low
Node CPU (Wh) I R E (%) 210 255 -17.6 216 255 -15.3 202 235 -14.0 202 235 -14.0 190 121 +57.0
Node Memory (Wh) I R E (%) 42 45 -6.7 43 46 -6.5 43 45 -4.4 43 46 -6.5 43 28 +53.6
Total (Wh) I R E (%) 252 300 -16.0 259 301 -13.9 245 280 -12.5 245 281 -12.8 233 149 +56.4
TABLE VI: Estimated energy consumption for benchmark Airflow workloads using Ichnos+ compared to RAPL, I=Ichnos, R=RAPL, E=Error. Selected Naive–Linear Model for CPU. Workload CPU Mem High High Med Med Low Low
Node CPU (Wh) Total (Wh) I R E (%) I R E (%) 145 255 -43.1 187 300 -37.7 134 235 -43.0 177 281 -37.0 122 121 +0.8 165 149 +10.7
is estimated with an error of 13.9 ± 17.1% for all workloads. We noticed that the workload with low CPU utilization was predicted less well. When this is excluded, we found that the prediction error improves to 13.4 ± 1.4%. For workloads with low CPU utilization, Ichnos+ significantly overestimates energy consumption when using a fitted linear power model. This aligns with the models plotted for the schedutil governor in Figure 5, where the fitted model overestimates observed power at CPU loads between 0% and 20%. Under such low load, employing a naïve model, which assumes linear scaling from the minimum to the maximum observed readings, improves the energy consumption estimation (≈ 10% instead of ≈ 50%), as shown in Table VI. However, we emphasize that these benchmark workloads in Airflow were designed to represent various patterns, but that the extreme case where there is no significant CPU utilization or memory utilization rarely occurs when executing real workflows. Still, if the utilized workload exhibits such behavior, Ichnos+ with a fitted power model will not be best suited for accurate energy consumption estimation and users might, in these cases, want to opt for a naive linear model. F. Estimation of Environmental Impact Ichnos+ can be used to estimate the average and marginal carbon emissions as well as embodied carbon emissions, alongside water and land use. The results are shown in Table VII. The water and land use metrics were configured based on the historical energy mix and the intensity coefficients, as introduced in Section IV-A. We highlight the execution of each workflow on the cluster that minimizes each reported metric. We retrieved average and marginal CI data aligning with the actual execution times in the regions where compute servers were located. Average CI data was retrieved from Electricity Maps, and Marginal CI data from WattTime11 . Both sources provided data at 5-minute temporal granularity. The estimated carbon emissions produced by Ichnos+ demonstrate that the system enables footprint estimation with the most granular CI data available, while offering users the choice of signal.
10
TABLE VII: Estimated average, marginal, and embodied carbon emissions and water and land use. The optimal infrastructure for each impact factor and each workflow is highlighted. Workflow RNA-Seq Atac-Seq Chip-Seq Nano-Seq RNA-Seq Chip-Seq Atac-Seq Rangeland Nano-Seq Sarek RNA-Seq Atac-Seq Chip-Seq Nano-Seq
Carbon Emissions (gCO2 e) Average Marginal Embodied Glasgow Cluster 290.86 531.86 8.31 251.41 496.77 7.58 393.20 698.19 10.33 146.26 314.45 4.61 Berlin Cluster 806.80 1,348.30 35.93 1,633.32 2,976.26 62.01 182.65 371.67 4.16 585.23 1,299.43 52.75 173.24 230.19 2.55 1,861.50 3,096.40 130.18 Dublin Cluster 1,061.08 2,116.52 26.59 135.83 370.70 3.50 790.62 1,824.27 19.39 85.13 167.19 1.59
Land Use (m2 )
Water Use (l)
1.08 1.16 1.60 0.68
0.35 0.42 0.62 0.24
3.78 7.71 0.40 2.93 0.24 8.38
1.75 3.84 0.16 1.21 0.14 4.06
5.66 1.17 6.07 0.76
2.01 0.39 1.95 0.27
We observe that the operational carbon emissions account for the majority of a workflow’s carbon footprint, with embodied carbon only responsible for a small fraction. We observed that workflows that consumed more energy tended to require more water and land – values which encompass the water and land effectiveness of the compute nodes, and the water and land used to generate the energy consumed. By estimating the carbon emissions of workflow execution, we can explore the impact of carbon-aware shifting and scaling techniques [15], and their wider influence on the water and land use of workflows. V. L IMITATIONS Generality. Ichnos+ was created to estimate the carbon footprint of Nextflow workflow executions from trace files. While we additionally exemplify how the system can be extended to support Airflow workflows, we only evaluate the method for two workflow systems, for selected workflows on three infrastructures. There is no confirmation that the system is directly applicable to other workflow systems. However, we detail the requirements to use Ichnos+ in §III and we welcome contributions to our open-source system, which remains under active development. Power Model Generation and Use. Ichnos+ requires that resource-specific power models are repeatedly generated when hardware is changed or at regular intervals to track device degradation. However, this is reliant on users having the required permissions available and access to compute infrastructure on which workflows are executed. If power models are not up-to-date or do not align with the original workflow execution, the accuracy of the energy consumption estimations will be limited. Furthermore, in the rare scenario where workloads have low CPU utilization, using a fitted linear power model may lead to overestimation of CPU energy consumption – here, it is an option to select a naive linear model for improved accuracy. Limitations of Input Data. Because Nextflow calculates the average utilization for workflow tasks using their total
CPU time, we are able to use Ichnos+ to make estimations of CPU energy consumption with significant accuracy. For other workflow systems, it is important that CPU usage is accurately represented, if this is not the case, estimates deviate further from RAPL readings. Ichnos+ further allows users to provide CI data at varied granularity levels, enabling the use of both average and marginal CI. However, CI data usually specify a value over a given period of time; e.g. WattTime offers marginal CI at intervals of five-minutes, while the National Grid offers average CI at intervals of thirty-minutes. As these intervals become coarser, overall footprint estimation becomes less accurate. Furthermore, we are reliant on these data sources to supply accurate data. By enabling post-hoc estimation, where the user will likely not have had access to power or emissions monitoring tools, we can only guarantee that our tool uses the estimation methodology described and the user-provided data – the workflow trace and the CI as well as the power model generated from measurements on compute resources utilized at the time, or as close as possible. This limitation is the same for other existing footprint estimation methodologies like CCF and GA. VI. R ELATED W ORK This section examines energy consumption monitoring and modeling methods in a broad context, followed by carbon footprint estimation methodologies and prior research wherein the carbon footprint of scientific workflows has been explored. To estimate the carbon footprint of computation, power consumption must first be monitored or modeled. Monitoring methods traditionally rely on software interfaces like RAPL – for Intel Processors – or the NVIDIA Management Library (NVML) – for NVIDIA GPUs. Tools built using these interfaces, such as Nvidia-smi, Perf and Scaphandre, can provide accurate measurements of energy consumption [24]. Scaphandre15 attributes energy to containers based on linear models of CPU and memory utilization. Kepler [25] provides similar container-level attribution, using RAPL-based linear models by default while supporting machine-specific training [26]. Both tools integrate with cluster observability stacks such as Prometheus. Nf-PEAK [27] enhances RAPL-based attribution on Kubernetes clusters with a non-linear model for CPU and DRAM. It provides a containerized deployment aimed specifically at Nextflow workflows. However, these methods necessitate configuration prior to workload execution, making them unsuitable for our post-hoc estimation problem space. Instead, we focus on methods capable of retrospectively modeling power consumption based on compute resource usage. Many methods have been proposed to model server power consumption [28]–[34]. Some works consider the power consumption of a server to be the sum of idle server consumption – thought to be a fixed value – and active consumption caused by computational workloads [29]–[31]. Other studies use regression models to predict power consumption [32]– [34]. Some works consider the CPU utilization to be the dominant contributor when modelling server consumption (for 15 https://github.com/hubblo-org/scaphandre
11
example, the linear model given by Fan et al. [32]) which produced reasonably accurate estimations and has since been implemented in various estimation methodologies, including CCF. Therefore, we implemented fitted linear-regression models and fitted cubic-regression models for CPU power draw, comparing them with monitored power consumption and existing estimation methodologies. Several tools have been created to estimate the carbon footprint from computational workloads [35]–[38]. Many of these tools model power consumption by using the server utilization and the TDP reported by the manufacturer [36], [37]. However, this value does not reflect idle power draw and also does not consider processor settings such as the frequency, reducing the estimation’s accuracy. Other tools require the user to have privileged (root) access [35], [36], [38]. Consequently, we focus on existing carbon footprint estimation methodologies that support post-hoc estimation and involve an intermediate step where energy consumption is estimated: CCF1 and GA [8]. We evaluate Ichnos+ against GA when comparing against the nf-co2footprint plugin8 . Prior studies have specifically applied existing carbon footprint estimation methodologies to analyze the footprint of bioinformatics [39], remote sensing [40] and neuroimaging [41] research processes. In other works where the focus is instead on reducing the energy footprint of scientific workflows, linear power models have been employed to estimate power consumption [42]. The presence of these works clearly indicates interest in being able to estimate the carbon footprint of computation, and validate the use of estimation methodologies in a post-hoc manner. Beyond carbon emissions, computing exerts significant pressure on water and land resources. For example, [43] highlight that training large AI models alone can require hundreds of thousands of liters of direct freshwater. More recently, [44] proposed a scheduling framework that optimizes carbon and water sustainability across geographically distributed data centers using a MILP-based scheduler. Similarly, land use has been considered a relevant factor in cloud workload orchestration for workloads such as big data analytics and FaaS [11]. However, the application of such methodologies to scientific computing workflows, to the best of our knowledge, remains largely unexplored. To illustrate the broader environmental footprint of computation beyond carbon, Ichnos+ supports water and land use estimation and we include respective evaluation scenarios. Differences with Prior Work. We introduced a first version of Ichnos and presented preliminary results in our previous work [9]. In this article, we present Ichnos+, with an expanded methodology with support to estimate embodied carbon emissions, water and land use, using node-specific fitted power models and memory energy coefficients. We significantly expanded our evaluation to measure the accuracy of our energy consumption estimations compared to ground truth RAPL data for distributed workflow executions on three compute infrastructures. We now also compare Ichnos+ with the nfco2footprint plugin, the accepted tool within the Nextflow nf-core community, which implements the GA methodology. We further demonstrate Ichnos+’s functionality to estimate
embodied emissions as well as water and land use. VII. C ONCLUSION In this paper, we presented Ichnos+, a novel system to estimate the environmental footprint of scientific workflow executions. By analyzing trace files, carbon intensity signals, and hardware-validated power models, Ichnos+ establishes a rigorous system for post-hoc estimation of energy and carbon footprints in data-intensive scientific computing. In addition, the estimated energy footprint can be used to, in turn, estimate additional environmental impacts. Ichnos+ takes a series of power measurements to generate a fitted linear model used to estimate CPU energy consumption, and measures the memory power consumption to determine the constant used to estimate memory energy consumption. These measurements are repeatable, enabling users to update models when processor settings change or device performance degrades. The system extends beyond operational carbon accounting by offering the ability to estimate embodied emissions, water and land use, thereby allowing users to quantify the wider environmental impact of workflow executions. Empirical evaluation across diverse compute clusters demonstrates that Ichnos+ predicts energy consumption with a median error of 10.8 ± 5.5% compared to hardware-level energy readings using RAPL. When compared against the nf-co2footprint plugin (the community-accepted measurement method for Nextflow workflows, which implements the GA methodology), Ichnos+ consistently produced higher accuracy across different infrastructures. Finally, we demonstrated the generalizability of our approach by successfully extending Ichnos+ to Apache Airflow. ACKNOWLEDGMENTS This work was supported by the UK Engineering and Physical Sciences Research Council (EPSRC) under grant number UKRI154, and the German Research Council (DFG) as part of CRC 1404. We gratefully acknowledge the sources of electricity grid data: NESO Open Data and Electricity Maps (historical average carbon intensity), and WattTime (marginal operating emission rates). We thank AWS and Google Cloud for providing research cloud computing credits. DATA /C ODE AVAILABILITY An open-source implementation of Ichnos+ is available at https://github.com/GlasgowC3lab/ichnos. R EFERENCES [1] P. Muir et al., “The real cost of sequencing: Scaling computation to keep pace with data generation,” Genome Biology, vol. 17, no. 1, p. 53, 2016. [2] J. A. Fellows Yates et al., “Reproducible, portable, and efficient ancient genome reconstruction with nf-core/eager,” PeerJ, vol. 9, p. e10947, 2021. [3] J. Schaarschmidt et al., “Workflow Engineering in Materials Design within the BATTERY 2030 + Project,” Advanced Energy Materials, vol. 12, p. 2102638, 2021. [4] B. Berriman et al., “Montage: A grid enabled engine for delivering custom science-grade mosaics on demand,” in Optimizing Scientific Return for Astronomy through Information Technologies, vol. 5493, 2004, pp. 221–232.
12
[5] C. Freitag et al., “The real climate and transformative impact of ICT: A critique of estimates, trends, and regulations,” Patterns, vol. 2, no. 9, 2021. [6] F. A. Nahid et al., “The rising energy footprint of data centers: A review of global trends, challenges, and opportunities,” in International Conference on Sustainable Technologies For Industry 5.0 (STI), 2025. [7] P. Di Tommaso et al., “Nextflow enables reproducible computational workflows,” Nature Biotechnology, vol. 35, no. 4, pp. 316–319, 2017. [8] L. Lannelongue, J. Grealey, and M. Inouye, “Green algorithms: Quantifying the carbon footprint of computation,” Advanced Science, vol. 8, no. 12, p. 2100707, 2021. [9] K. West et al., “Ichnos: A carbon footprint estimator for scientific workflows,” in LOCO Workshop, 2025. [10] R. U. Ayres, “Life cycle analysis: A critique,” Resources, Conservation and Recycling, vol. 14, no. 3, pp. 199–223, 1995. [11] G. Attenni et al., “Spatio-temporal shifting to reduce carbon, water, and land-use footprints of cloud workloads,” arXiv preprint 2512.08725, 2025. [12] L. A. Barroso, U. Hölzle, and P. Ranganathan, “Energy and sustainability,” in The Data Center as a Computer: Designing Warehouse-Scale Machines. Springer, 2025, pp. 213–267. [13] P. Wiesner et al., “Let’s wait awhile: How temporal workload shifting can reduce carbon emissions in the cloud,” in Middleware Conference, 2021, pp. 260–272. [14] W. A. Hanafy et al., “Carbonscaler: Leveraging cloud workload elasticity for optimizing carbon-efficiency,” Proceedings of the ACM on Measurement and Analysis of Computing Systems, vol. 7, no. 3, pp. 1–28, 2023. [15] K. West et al., “A systematic evaluation of the potential of carbonaware execution for scientific workflows,” Future Generation Computer Systems, p. 108453, 2026. [16] V. M. Weaver and S. A. McKee, “Can hardware performance counters be trusted?” in IEEE International Symposium on Workload Characterization, Seattle, WA, USA, 2008, pp. 141–150. [17] V. Bountris, L. Thamsen, and U. Leser, “HyProv: Hybrid provenance management for scientific workflows,” arXiv preprint 2511.07574, 2025. [18] P. A. Ewels et al., “The nf-core framework for community-curated bioinformatics pipelines,” Nature biotechnology, vol. 38, no. 3, pp. 276– 278, 2020. [19] T. Simon et al., “BoaviztAPI: A bottom-up model to assess the environmental impacts of cloud services,” SIGENERGY Energy Inform. Rev., vol. 4, no. 5, pp. 84–90, 2025. [20] IPCC, “Climate Change 2014: Mitigation of climate change. Annex III: Technology-specific cost and performance parameters,” 2014. [21] Our World in Data, “What are the safest and cleanest sources of energy?” 2020, accessed: 2026-02-20. [Online]. Available: https: //ourworldindata.org/safest-sources-of-energy [22] J. Macknick et al., “Consumptive water use for US power production,” 2011. [23] J. Lovering et al., “Land-use intensity of electricity production and tomorrow’s energy landscape,” PLoS One, vol. 17, no. 7, p. e0270155, 2022. [24] M. Jay et al., “An experimental comparison of software-based power meters: focus on cpu and gpu,” in IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing (CCGrid), 2023, pp. 106–118. [25] M. Amaral et al., “Kepler: A Framework to Calculate the Energy Consumption of Containerized Applications,” in International Conference on Cloud Computing (CLOUD). IEEE, 2023, pp. 69–71. [26] ——, “Process-Based Efficient Power Level Exporter,” in International Conference on Cloud Computing (CLOUD). IEEE, 2024, pp. 456–467. [27] P. Thamm et al., “Nf-PEAK: Process-Based Energy Attribution for Nextflow Workflows on Kubernetes Clusters,” arXiv preprint 2605.22393, 2026. [28] K. M. U. Ahmed et al., “A review of data centers energy consumption and reliability modeling,” IEEE Access, vol. 9, pp. 152 536–152 563, 2021. [29] S. Roy, A. Rudra, and A. Verma, “An energy complexity model for algorithms,” in Conference on Innovations in Theoretical Computer Science, 2013, pp. 283–304. [30] G. Dhiman, K. Mihic, and T. Rosing, “A system for online power prediction in virtualized environments using Gaussian mixture models,” in Design Automation Conference, 2010, pp. 807–812. [31] P. Xiao et al., “Virtual machine power measuring technique with bounded error in cloud environments,” J of Network and Computer Applications, vol. 36, no. 2, pp. 818–828, 2013. [32] X. Fan, W.-D. Weber, and L. A. Barroso, “Power provisioning for a warehouse-sized computer,” ser. ISCA ’07, 2007, p. 13–23.
[33] D. Economou et al., “Full-system power analysis and modeling for server environments,” 2006. [34] Y. Li et al., “An online power metering model for cloud environment,” in International Symposium on Network Computing and Applications, 2012, pp. 175–180. [35] P. Henderson et al., “Towards the systematic reporting of the energy and carbon footprints of machine learning,” pp. 1–43, 2020. [36] B. Courty et al., “mlco2/codecarbon: v2.4.1,” 2024. [37] S. A. Budennyy et al., “eco2AI: Carbon emissions tracking of machine learning models as the first step towards sustainable AI,” Doklady Mathematics, pp. S118–S128, 2023. [38] L. F. W. Anthony, B. Kanding, and R. Selvan, “Carbontracker: Tracking and predicting the carbon footprint of training deep learning models,” ICML Workshop on Challenges in Deploying and Monitoring Machine Learning Systems, 2020. [39] J. Grealey et al., “The carbon footprint of bioinformatics,” Molecular Biology and Evolution, vol. 39, no. 3, p. msac034, 2022. [40] L. Thamsen et al., “Energy-aware workflow execution: An overview of techniques for saving energy and emissions in scientific compute clusters,” 2025. [41] N. E. Souter et al., “Measuring and reducing the carbon footprint of fMRI preprocessing in fMRIPrep,” Tech. Rep., 2024. [42] Y. Saadi et al., “Reducing energy footprint in cloud computing: A study on the impact of clustering techniques and scheduling algorithms for scientific workflows,” Computing, vol. 105, no. 10, pp. 2231–2261, 2023. [43] P. Li et al., “Making AI less ‘thirsty’,” Commun. ACM, vol. 68, no. 7, pp. 54–61, 2025. [44] Y. Jiang et al., “Waterwise: Co-optimizing carbon- and water-footprint toward environmentally sustainable cloud computing,” in ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, 2025, pp. 297–311.
B IOGRAPHIES
Kathleen West (GS, IEEE) is a PhD student at the University of Glasgow, United Kingdom. She is working on the carbon-aware execution of scientific workflows on heterogeneous clusters.
Youssef Moawad is a postdoctoral researcher at the University of Glasgow. He is working on carbon- and performance-aware schedulers for scalable batch processing systems.
Philipp Thamm is a PhD student in the WBI group at Humboldt-Universität zu Berlin, Germany. His research is focused on energy efficiency, scientific workflows and distributed systems.
Vasilis Bountris is a PhD student in the WBI group at Humboldt-Universität zu Berlin, Germany. His research is focused on provenance management, scientific workflows and distributed systems.
Giulio Attenni is a PhD student at Sapienza University of Rome, Italy. His research focuses on applications for sustainable development such as environmentally-conscious cloud orchestration.
Magnus Reid earned his MSci degree at the University of Glasgow while his research focused on carbon-aware scientific workflow execution.
Yehia Elkhatib is an Associate Professor at the University of Glasgow. His research is on data-driven tools to optimize complex distributed systems.
Lauritz Thamsen is a Lecturer / Assistant Professor at the University of Glasgow, where he researches adaptive compute resource management and carbon-aware execution of data-intensive systems.