← Back to project catalogue
GP-CS-0GXR1I7Computer ScienceReady

Architecture-Level Carbon Accounting for Distributed Software Systems

Explore how hardware, caching and workload timing change the carbon footprint attributed to software.

Architecture-Level Carbon Accounting for Distributed Software Systems project visual
GP-CS-0GXR1I7 · Computer Science
  • Python 3.10+
  • Matplotlib

Software compatibility

Read without installing software

Word, PDF and editable slides explain the study. Optional calculations use standard-library Python. Matplotlib is needed only to regenerate figures. No web framework, cloud account or API key is required.

Project definition

Problem statement

A software carbon estimate can change when idle servers, networking, storage or reserved hardware are left outside the calculation.

Architectures also differ in placement, caching and demand. A fair comparison needs matching outcomes, explicit boundaries and a clear distinction between attribution and a marginal counterfactual.

Project objectives

  • Define non-overlapping energy and hardware accounting boundaries.
  • Compare central, remote, active-active and edge-cache deployments.
  • Derive retry, allocation, timing and break-even relationships.
  • Test how caching, network energy and hardware assumptions change the result.
  • Separate lower emissions per completed request from lower total emissions.
  • Explain the measurement evidence needed beyond a hypothetical study.

Project structure

Project components

01

Literature review

Sixteen annotated sources cover software carbon accounting, placement, hardware lifecycle, fairness and historical infrastructure.

02

Accounting model

Explicit units, energy scopes, PUE and hardware reservation rules prevent hidden double counting.

03

Architecture comparison

Four fixed deployments use the same declared workload and completion definition.

04

Sensitivity analysis

Paired cases examine caching, network energy, hardware allocation, hourly signals and demand growth.

05

Verification

Independent probability, rational and decimal calculations check the model, with portable reproduction and artifact corruption tests.

Methodology

Project workflow

  1. 01
    Read the evidence

    Separate published methods from the project's declared teaching assumptions.

  2. 02
    Follow the boundary

    Identify each resource, its units and whether its energy is IT-only or facility-inclusive.

  3. 03
    Compare architectures

    Inspect complete totals and explain why omitted resources change the comparison.

  4. 04
    Test assumptions

    Reproduce cache crossings, timing effects and capacity-limited demand cases.

  5. 05
    Extend the study

    Plan measurements and compare matched outcomes without claiming unmeasured savings.

Demonstration scenario

At the reference hypothetical inputs, the remote deployment totals 2,015.52 g CO2e/day and edge-cache totals 2,433.44 g CO2e/day. At a higher assumed network energy coefficient, changing the cache hit fraction from 0.4 to 0.6 reverses that paired preference. The study derives why, without claiming a universal best architecture.

Engineering

Tools and method

Engineering study
The documentation develops introduction, literature, theory, methodology, results, discussion and further work.
Offline reproduction
Python recalculates all eleven result tables without an online service.
Cross-platform checks
Retained file integrity is exact; an additional bounded-roundoff check supports macOS and Linux reproduction.
Editable material
Word documents, native presentation objects and SVG figures support supervised extensions.

Testing

Evaluation

Evaluation measures

  • Non-overlapping inventory coverage and correct PUE treatment
  • Independent energy, hardware and retry calculations
  • Hourly versus daily aggregation consistency
  • Cache thresholds and capacity-limited demand roots
  • Agreement across results, figures, documentation and slides
  • Clear separation of numerical verification and real-world validation

Project boundaries

  • Workloads, energy coefficients and grid signals are hypothetical, not measured cloud-provider data.
  • Equivalent useful outcomes are stipulated, not demonstrated by a deployed application.
  • Sensitivity-grid winner counts are not probabilities or market forecasts.
  • Capacity rejection is not a measured latency or availability guarantee.
  • No carbon-credit claim, emissions certification or universal architecture recommendation is provided.
  • Native Microsoft Word and PowerPoint application rendering has not been tested.

Included

  1. 0179-page project documentation in PDF and editable Word formats
  2. 02Six-page student guide in PDF and editable Word formats
  3. 0322-slide editable presentation with six native tables and four native charts
  4. 0416 annotated references and a source matrix
  5. 0518 report tables, 15 editable equations and eight original scientific figures
  6. 06One attributed, licensed historical server photograph
  7. 0711 reproducible CSV tables with explicit hypothetical inputs
  8. 08Complete Python source, 123 unit tests and 22 artifact checks

Project record

No information is collected on this page.

Permanent project ID
GP-CS-0GXR1I7
Catalogued
21 Aug 2026
Completed
07 Sept 2026
Verified
07 Sept 2026
Demonstration
Included in repository

Handover

After purchase

  1. 01
    Payment is confirmed

    The project is marked unavailable and cannot be purchased again.

  2. 02
    Repository access is granted

    The buyer's submitted GitHub account receives access to the private repository.

  3. 03
    The purchase record is delivered

    The certification sheet is prepared from the reviewed buyer details and sent privately by email.