green-coding-solutions · ribalba · Jul 16, 2026 · Jul 16, 2026
diff --git a/content/en/docs/carbondb/overview.md b/content/en/docs/carbondb/overview.md
@@ -84,7 +84,7 @@ Cronjobs are all placed in the `/cron` directory of GMT and are de-activated by
 
 The following cron jobs are used to maintain the data in CarbonDB:
 
-- **carbondb_copy_over_and_remove_duplicates.py**: This cron job copies data from other sources (e.g., `hog_simplified_measurements`, `ci_measurements`) into the `carbondb_data_raw` table. It also backfills missing carbon intensity data.
+- **carbondb_copy_over_and_remove_duplicates.py**: This cron job copies data from other sources (e.g., `hog_simplified_measurements`, `ci_measurements`) into the `carbondb_data_raw` table. It also de-duplicates the data and validates that the copied over data is complete.
 - **carbondb_compress.py**: This cron job compresses the raw data in `carbondb_data_raw` into daily sums. It also normalizes the data by transforming text fields into integers and storing them in separate tables.
 - **backfill_geo.py**: This cron job will backfill geo information for IPs. They are needed to backfill carbon intensity which works on Geo coordinates.
   + The cron job only backfills IP data up to 30 days. Then it considers information to be outdate

diff --git a/content/en/docs/cluster/accuracy-control.md b/content/en/docs/cluster/accuracy-control.md
@@ -23,7 +23,7 @@ cluster:
       name: "Measurement control Workload"
       uri: "https://github.com/green-coding-solutions/measurement-control-workload"
       filename: "usage_scenario.yml"
-      branch: "main"
+      branch: "event-bound"
       comparison_window: 5
       phase: "004_[RUNTIME]"
       metrics:
@@ -39,10 +39,7 @@ cluster:
         cpu_energy_rapl_msr_component:
           threshold: 0.01 # 1%
           type: stddev_rel
-        cpu_energy_rapl_msr_component:
-          threshold: 0.01 # 1%
-          type: stddev_rel
-        psu_co2_ac_mcp_machine:
+        psu_carbon_ac_mcp_machine:
           threshold: 0.01 # 1%
           type: stddev_rel
         network_total_cgroup_container:

diff --git a/content/en/docs/cluster/cron-jobs.md b/content/en/docs/cluster/cron-jobs.md
@@ -17,7 +17,7 @@ This page provides examples how we setup the *cron jobs*. Adjust the times and f
 SHELL=/bin/bash
 
 ## Deprecated! We do not recommend to use the cron feature to schedule jobs
-#*\/5    *       *       *       *       PATH_TO_GMT/venv/bin/python3 PATH_TO_GMT/tools/jobs.py project &>> /var/log/green-metrics-jobs.log
+#*\/5    *       *       *       *       PATH_TO_GMT/venv/bin/python3 PATH_TO_GMT/cron/jobs.py run &>> /var/log/green-metrics-jobs.log
 
 ## We recommend to trigger the email job every 2 minutes
 ## You can trigger it more often, as it has a locking mechanism. The mechanism is however not fully parallel safe and email processing is not done in a transaction which might lead to race conditions if multiple connections to the DB in parallel try to set the DB lock.

diff --git a/content/en/docs/cluster/host-resource-reservations.md b/content/en/docs/cluster/host-resource-reservations.md
@@ -27,8 +27,8 @@ machine:
 
 #### Specifications
 
-- `host_reserved_cpus` **[integer]** (Default 1): Value between 1 and CPU_MAX. CPU_MAX is the amount of available compute threads on the system.
-- `host_reserved_memory` **[integer]** (Default 0): Value between 0 and MEMORY_MAX. MEMORY_MAX is the amount of available physical memory on the system.
+- `host_reserved_cpus` **[integer]** (Default 1): Value between 1 and CPU_MAX, where CPU_MAX itself is excluded. CPU_MAX is the amount of compute threads Docker reports as available (`docker info --format '{{.NCPU}}'`). At least one thread must be left assignable to containers, so reserving all of them fails.
+- `host_reserved_memory` **[integer]** (Default 0): Value between 0 and MEMORY_MAX, where MEMORY_MAX itself is excluded. MEMORY_MAX is the memory Docker reports as available (`docker info --format '{{.MemTotal}}'`), which is not necessarily the physical memory of the host — under Docker Desktop it is the VM's memory. At least one byte must be left assignable to containers, so reserving all of it fails.
 
 ## How to choose good values
 

diff --git a/content/en/docs/cluster/installation.md b/content/en/docs/cluster/installation.md
@@ -27,17 +27,17 @@ Now you can choose between two modes:
 
 ## 1) Systemd Service - Client mode
 
-The `tools/client.py` program is a script that should constantly be running and that periodically checks the database if a new job has been queued for this certain machine. If no job can be retried it sleeps for a certain amount of time set in the configuration file `config.yml`:
+The `cron/client.py` program is a script that should constantly be running and that periodically checks the database if a new job has been queued for this certain machine. If no job can be retried it sleeps for a certain amount of time set in the configuration file `config.yml`:
 
 ```yml
-client:
-  sleep_time_no_job: 300
-  sleep_time_after_job: 300
+cluster:
+  client:
+    sleep_time_no_job: 300
 ```
 
-You can also set a time that the script should wait after a job has finished execution to give the system time to cool down. Please use the [calibrate script]({{< relref "/docs/installation/calibration" >}}) to fine tune this value.
+There is no fixed cooldown time after a job. Instead the client checks the machine temperature before every job and holds the queue until the machine is back at its baseline: if the machine is hotter than `base_temperature_value` it sleeps 60 seconds and retries, and if it is 10° or more below it warms the machine up before retrying. See [Machine Baseline Checks →]({{< relref "machine-baseline-checks" >}}) for details. Please use the [calibrate script]({{< relref "/docs/installation/calibration" >}}) to fine tune the `base_temperature_value`.
 
-After running a job the client program executes the `tools/cluster/maintenance.py` script that does general house keeping on the machine. This is done in a batch fashion to not run when a benchmark is currently run.
+After running a job the client program executes the `maintenance.py` script that does general house keeping on the machine. This is done in a batch fashion to not run when a benchmark is currently run.
 
 To make sure that the client is always running you can create a service that will start at boot and keep running.
 
@@ -78,9 +78,11 @@ systemctl --user status green-coding-client # check status
 
 You should now see the client reporting it's status on the server. It is important to note that only the client ever talks to the server (polling). The server never tries to contact the client. This is to not create any interrupts while a measurement might be running.
 
-After running a job the client program executes the `tools/cluster/maintenance.py` script that does general house keeping on the machine. This is done in a batch fashion to not run when a benchmark is currently run.
+After running a job the client program executes the maintenance script that does general house keeping on the machine. This is done in a batch fashion to not run when a benchmark is currently run.
 
-This script is run as root and thus needs to be in the `/etc/sudoers` file or subdirectories somewhere. We recommend the following:
+The script lives in the repository as `tools/cluster/maintenance_original.py`. The installer copies it to `/usr/local/bin/green-metrics-tool/maintenance.py` and makes it owned by root, and that is the path the client actually executes.
+
+This script is run as root and thus needs to be in the `/etc/sudoers` file or subdirectories somewhere. The installer deliberately does *not* add this entry for you, as it is only needed in cluster mode. We recommend the following:
 
 ```bash
 echo "${USER} ALL=(ALL) NOPASSWD:$(realpath /usr/bin/python3) -I -B -S /usr/local/bin/green-metrics-tool/maintenance.py" | sudo tee /etc/sudoers.d/green-coding-cluster-maintenance
@@ -96,13 +98,15 @@ The Green Metrics Tool comes with an implemented queueing and locking mechanism.
 
 You can install a cronjob on your system to periodically call:
 
-- `python3 -u PATH_TO_GREEN_METRICS_TOOL/tools/jobs.py project` to measure projects in database queue
-- `python3 -u PATH_TO_GREEN_METRICS_TOOL/tools/jobs.py email` to send all emails in the database queue
+- `python3 -u PATH_TO_GREEN_METRICS_TOOL/cron/jobs.py run` to measure runs in database queue
+- `python3 -u PATH_TO_GREEN_METRICS_TOOL/cron/jobs.py email` to send all emails in the database queue
+
+Calling `jobs.py run` will print a deprecation warning, as this mode is only intended for CLI testing. Use the *client mode* above for production.
 
 The `jobs.py` uses the *Python* faulthandler mechanism and will also report to *STDERR* in case of a segfault.
 When running the cronjob we advice you to append all the output combined to a log file like so:
 
-`* * * * * python3 -u PATH_TO_GREEN_METRICS_TOOL/tools/jobs.py project &>> /var/log/green-metrics-jobs.log`
+`* * * * * python3 -u PATH_TO_GREEN_METRICS_TOOL/cron/jobs.py run &>> /var/log/green-metrics-jobs.log`
 
 Be sure to give the `green-metrics-jobs.log` file write access rights.
 
@@ -184,7 +188,7 @@ $ sudo nano /etc/default/grub
 
 # Change this line
 # GRUB_CMDLINE_LINUX_DEFAULT=""
-# to 
+# to
 # GRUB_CMDLINE_LINUX_DEFAULT="intel_pstate=disable acpi=force"
 
 $ sudo update-grub

diff --git a/content/en/docs/cluster/machine-baseline-checks.md b/content/en/docs/cluster/machine-baseline-checks.md
@@ -50,7 +50,7 @@ Also see [Accuracy Control →]({{< relref "accuracy-control" >}}).
 
 ## RAPL Power Capping
 
-Verifies that RAPL power limits are at or below the values you have locked on the machine. Ensures a consistent thermal envelope across cluster nodes.
+Verifies that the RAPL power limits locked on the machine are **exactly equal** to the values you configure. Ensures a consistent thermal envelope across cluster nodes.
 
 ```yaml
 machine:
@@ -60,12 +60,21 @@ machine:
     psys: 65       # Watts — platform-wide limit (if available)
 ```
 
-Each sub-key is independent; omit any you do not want to enforce. Values are compared against the `constraint_0_power_limit_uw` sysfs files under `/sys/devices/virtual/powercap/intel-rapl/`.
+Each sub-key is independent; omit any you do not want to enforce. The configured Watt value is converted to microwatts and compared for exact equality against **every** limit the domain exposes — both the long-term (`constraint_0`) and the short-term (`constraint_1`) limit, wherever present. This transitively also catches the two limits disagreeing with each other, which is why we recommend setting both to the same value.
+
+Domains are discovered under `/sys/devices/virtual/powercap/intel-rapl/`, including nested ones such as `intel-rapl:0:1` for DRAM. Each domain's `name` file classifies it as `package`, `dram` or `psys`, and its `constraint_N_name` files identify which constraint is the long- and which the short-term limit. Domains that expose only a long-term limit — typical for `dram` and `psys` — are checked on that limit alone.
 
 To read the current limits on your machine:
 
 ```sh
-cat /sys/devices/virtual/powercap/intel-rapl/intel-rapl:*/constraint_0_power_limit_uw
+for name in /sys/devices/virtual/powercap/intel-rapl/intel-rapl:*/name \
+            /sys/devices/virtual/powercap/intel-rapl/intel-rapl:*/*/name; do
+    domain=$(dirname "$name")
+    echo "$(basename "$domain") ($(cat "$name")):"
+    for constraint in "$domain"/constraint_*_name; do
+        echo "    $(cat "$constraint") = $(cat "${constraint%_name}_power_limit_uw") uW"
+    done
+done
 ```
 
 Also see [Power Saving →]({{< relref "power-saving#power-capping-machines" >}}) for how to make these limits persistent across reboots via a systemd service.
@@ -213,12 +222,13 @@ The following three checks need **no** `config.yml` entry at all — they always
 
 The [NOP Linux script →]({{< relref "nop-linux" >}}) auto-prepares a machine so that all three of these pass: it disables/masks system and user `systemd` timers, deletes all cron files, and zeroes out the kernel watchdog sysctls, in addition to disabling NTP and removing swap-adjacent packages. Run it once on a fresh cluster machine instead of doing the steps below by hand.
 
-### System-wide Systemd Timers
+### Systemd Timers
 
-Runs as root and warns when any active system-wide `systemd` timer is detected. Timers can wake the system and create measurement noise. To inspect active timers:
+Warns when any active `systemd` timer is detected. Both scopes are checked: system-wide timers (read via the root helper) and timers in the invoking user's own `systemd` scope. Timers can wake the system and create measurement noise. To inspect active timers:
 
 ```sh
-systemctl --all list-timers
+sudo systemctl --all list-timers    # system-wide scope
+systemctl --user --all list-timers  # user scope
 ```
 
 ### Cron Files

diff --git a/content/en/docs/cluster/nop-linux.md b/content/en/docs/cluster/nop-linux.md
@@ -16,7 +16,7 @@ NTP.
 The goal is to keep the system still very close to a production / user setup, but remove invariances from the system without
 decreasing idle power draw and skewing results.
 
-Please further note that you must execute certain service still periodically. The [client.py](https://github.com/green-coding-solutions/green-metrics-tool/blob/main/cron/client.py) cluster service will periodically run [a cleanup script](https://github.com/green-coding-solutions/green-metrics-tool/blob/main/tools/cluster/cleanup_original.py)
+Please further note that you must execute certain service still periodically. The [client.py](https://github.com/green-coding-solutions/green-metrics-tool/blob/main/cron/client.py) cluster service will periodically run [a maintenance script](https://github.com/green-coding-solutions/green-metrics-tool/blob/main/tools/cluster/maintenance_original.py)
 
 ```bash
 #!/bin/bash

diff --git a/content/en/docs/cluster/observability.md b/content/en/docs/cluster/observability.md
@@ -13,7 +13,7 @@ GMT provides two approaches to get insights into the cluster operations.
 
 ## Status Page
 
-Under the `/status.html` page of your GMT installation you can find a status page that contains:
+Under the `/cluster-status.html` page of your GMT installation you can find a status page that contains:
 
 - Currently configured machines in the cluster
 - Current temperature, installed GMT version and measurement configuration of the machines in the cluster

diff --git a/content/en/docs/cluster/security.md b/content/en/docs/cluster/security.md
@@ -166,6 +166,9 @@ GRANT UPDATE ON public.carbondb_sources TO manager;
 GRANT UPDATE ON public.carbondb_tags TO manager;
 GRANT UPDATE ON public.carbondb_types TO manager;
 
+-- to insert errors
+GRANT USAGE, SELECT ON SEQUENCE jobs_id_seq TO manager;
+GRANT SELECT, INSERT ON TABLE jobs TO manager;
 ```
 
 To complement the configuration you need also have a different `config.yml` file present to read the credentials from.
@@ -202,6 +205,35 @@ We recommend NOT to have SMTP credentials on the machines and also connect to th
 CREATE USER client WITH PASSWORD 'YOUR_PASSWORD';
 
 
+GRANT SELECT,INSERT,DELETE ON TABLE jobs TO client;
+GRANT USAGE, SELECT ON SEQUENCE jobs_id_seq TO client;
+GRANT UPDATE(state) ON TABLE jobs TO client;
+
+GRANT SELECT,INSERT ON TABLE client_status TO client;
+GRANT USAGE, SELECT ON SEQUENCE client_status_id_seq TO client;
+
+GRANT SELECT(id) ON TABLE network_intercepts TO client;
+GRANT INSERT ON TABLE network_intercepts TO client;
+GRANT USAGE, SELECT ON SEQUENCE network_intercepts_id_seq TO client;
+
+GRANT SELECT, INSERT ON TABLE measurement_metrics TO client;
+GRANT USAGE, SELECT ON SEQUENCE measurement_metrics_id_seq TO client;
+
+GRANT SELECT, INSERT ON TABLE measurement_values TO client;
+GRANT USAGE, SELECT ON SEQUENCE measurement_values_id_seq TO client;
+
+GRANT INSERT ON TABLE notes TO client;
+GRANT USAGE, SELECT ON SEQUENCE notes_id_seq TO client;
+
+GRANT SELECT,INSERT ON TABLE phase_stats TO client;
+GRANT USAGE, SELECT ON SEQUENCE phase_stats_id_seq TO client;
+
+GRANT INSERT on cluster_changelog to client;
+GRANT SELECT, USAGE on cluster_changelog_id_seq to client;
+
+GRANT SELECT,INSERT on warnings to client;
+GRANT SELECT, USAGE on warnings_id_seq to client;
+
 GRANT SELECT ON TABLE runs TO client; -- only needs a full select if optimizations are run on the measurement machines. Otherwise can be locked down
 
 REVOKE ALL PRIVILEGES ON DATABASE "green-coding" FROM client;

diff --git a/content/en/docs/contributing/green-metrics-tool-contribution.md b/content/en/docs/contributing/green-metrics-tool-contribution.md
@@ -64,7 +64,7 @@ A metric provider should always have:
 
 - **metric-provider-binary** - A binary or script that captures metrics from somewhere in the host system (for instance procfs for CPU utilization)
     - This file should **always** work standalone and not require a running GMT. Very often this is a native compiled C files.
-    - See also the `libs/c` directory for some convenience library files that ship with GMT.
+    - See also the `lib/c` directory for some convenience library files that ship with GMT.
 - **provider.py** - File containing Python class derived from *BaseMetricProvider* which implements how data is ingested into GMT
 - **README.md** - An info file specifying what is the ouput of the metric provider in terms of unit and dimension as well as how to execute it on a CLI and what arguments exist.
 
@@ -95,4 +95,4 @@ It is the easiest and also the only way to add back-office functionality to the
 ## Core functionality
 
 - All API code lives in /api and is typically divided by functionality. Every tool of the suite (Eco CI, ScenarioRunner etc.) has it's own file.
-- Optimizations live under optimizations. Look at the example file to create a new one. It will be automatically loaded
+- Optimizations live under `optimization_providers`. Look at the example file to create a new one. It will be automatically loaded
diff --git a/content/en/docs/frontend/customization.md b/content/en/docs/frontend/customization.md
@@ -21,6 +21,14 @@ The first part of the file should not be modified, as these variables are set by
 ```js
 API_URL = "__API_URL__"
 METRICS_URL = "__METRICS_URL__"
+ELEPHANT_URL = "__ELEPHANT_URL__"
+
+ACTIVATE_SCENARIO_RUNNER = __ACTIVATE_SCENARIO_RUNNER__;
+ACTIVATE_ECO_CI = __ACTIVATE_ECO_CI__;
+ACTIVATE_CARBON_DB = __ACTIVATE_CARBON_DB__;
+ACTIVATE_POWER_HOG = __ACTIVATE_POWER_HOG__;
+ACTIVATE_SOFTWARE_VIEW = __ACTIVATE_SOFTWARE_VIEW__;
+ACTIVATE_AI_OPTIMISATIONS = __ACTIVATE_AI_OPTIMISATIONS__;
 ```
 
 The later part you can customize. If you for instance want to have the top chart not display all energy metrics, but
@@ -29,18 +37,16 @@ rather only the RAPL energy metrics, change accordingly:
 ```js
 // old
 // title and filter function for the top left most chart in the Detailed Metrics / Compare view
-const TOP_BAR_CHART_TITLE = 'Energy metrics [mJ]'
+const TOP_BAR_CHART_TITLE = 'Energy Metrics';
 const top_bar_chart_condition = (metric) => {
-    if(metric.indexOf('_energy_') !== -1) return true;
-    return false;
+    return metric.indexOf('_energy_') !== -1 && (metric.endsWith('_machine') || metric.endsWith('_component'));
 }
 
 // new
 // title and filter function for the top left most chart in the Detailed Metrics / Compare view
-const TOP_BAR_CHART_TITLE = 'RAPL only energy metrics [mJ]'
+const TOP_BAR_CHART_TITLE = 'RAPL only energy metrics';
 const top_bar_chart_condition = (metric) => {
-    if(metric.indexOf('_energy_') !== -1 && metric.indexOf('_rapl_') !== -1) return true;
-    return false;
+    return metric.indexOf('_energy_') !== -1 && metric.indexOf('_rapl_') !== -1 && (metric.endsWith('_machine') || metric.endsWith('_component'));
 }
 ````
 

diff --git a/content/en/docs/frontend/libraries-and-components.md b/content/en/docs/frontend/libraries-and-components.md
@@ -38,8 +38,9 @@ The sidebar is done in flexbox.
 - All library files which live in `/frontend/dist/`
   + In the `site.min.css` from Fomantic UI where we removed the @import statement for the external fonts.
   + We removed the `emoji.min.css` because it contained external imports
-  + We removed the `flags.min.css` because it contained external imports
   + We then concatenated all the minified file into a `semantic_reduced.min.css`
+  + The `flag.min.css` is not part of that concatenation. It ships as a separate file and is only loaded on the pages
+    that need it (currently `simulation-yearly.html`)
 - The JS files from Fomantic UI are all included separately, since we don't need most of the components
 - We use the standard theme for Fomantic UI
 
@@ -51,8 +52,8 @@ On the website you can select a custom build by only including the needed charts
 
 Our selection was:
 
-- Only Bar, Line, Pie and Radar chart
-- Only Grid coordinate system
+- Only Bar, Line, Pie, Radar and Candlestick chart
+- Only Grid and Polar coordinate systems
 - All Components included
 - Utilities included
 - Code Compression

diff --git a/content/en/docs/general-info/files-and-folders.md b/content/en/docs/general-info/files-and-folders.md
@@ -37,6 +37,8 @@ Alternatively in the future we might consider running GMT as a module command (`
   - Includes DB migrations in *SQL* format to run after upgrading from one version to another
 - `optimization_providers`
   - Includes the modular *optimization providers*
+- `templates`
+  - Includes the ready-made `usage_scenario` templates for websites and AI models, the re-usable compose partials (e.g. the *Playwright* helpers) and the email templates
 - `tests`
   - Includes the *Python* unit- and E2E-tests
 - `tools`