Upstream, Operation, Downstream carbon in GMT Suite

[ArneTR]

Plan

GMT does currently understand the distinction between embodied carbon and operational carbon and also network carbon.network_co2_formula_global

However in tools like Eco-CI or Power HOG and CarbonDB this is currently not the case.

This discussions aims to discuss possible caveats and needed changes to make all tools understand and also send
the data in the necessary granularity.

Also we should make the additional distinction if all of these values are upstream, operational or downstream (thanks to @ribalba).
This enables us to have a chart similar to

CarbonDB

• Needs to split up the current column for carbon_kg_sum into embodied and operational
• Needs to have also the network energy and network carbon in a column
• A new chart must be done that categorizes all emissions into upstream, downstream, operational. Embodied can actually be in
  the upstream or the downstream, while energy can be in the operational or the downstream categories. Upstream energy does not exist in GHG.

PowerHOG

• Carbon must be added in general. Currently has no understanding of it. Or? @ribalba

Eco-CI

• Already derives embodied carbon and operational carbon separately, but sends them combined
• Data must just be sent separately
• Currently Network emissions are not derived. This feature needs to be added by reading data from the network adapter.
  • Downside: No actual distinction can be made if the traffic is external or internal. For internal traffic many papers
    say that the energy is negligable.

Double check

• Can we somehow also get network embodied carbon?
  • If I remember correctly the papers we use only have energy as a value and only we make it to carbon internally
  • In case we get a value but cannot separate just call the metric carbon_combined

Naming scheme suggestions

All namings should now have either upstream, downstream or operational as the first part.

• embodied_carbon_share_machine => upstream_manufacturing_embodied_carbon_derived_machine

  • manufacturing was added as the source of origin for the value was missing
  • share was changed for derived as our naming scheme requires the source as the next to last part
  • Other options could be 'data', 'datasheet', 'database', 'guess', 'paper', 'estimation', 'estimate'
  • Stuff like database or paper is most accurate but feels misleading an not intuitive on first read ... @ribalba ?

• network_co2_formula_global => mixed_network_carbon_derived_global

  • or if we find separate data
  • network_co2_formula_global => operational_network_carbon_derived_global + downstream_network_carbon_derived_global

• psu_co2_dc_rapl_msr_machine => upstream_psu_carbon_dc_rapl_msr_machine

• psu_energy_dc_rapl_msr_machine => operational_psu_carbon_dc_rapl_msr_machine

Open questions

A value GMT and our other tools currently do not respect is downstream energy. In GHG if we create a software product and it is used client side the energy used to run it is our downstream energy cost.
We can influence it if we make our tools for instance carbon aware.
Currently however this is not integrated.

Question would be how to best integrate it. Only in CarbonDB. Or in the GMT measurement process as a value directly? Effectively it would be the overhead of the tool itself ... @ribalba ?