PFAS-data-center

A modular model connecting AI computing demand, GPU infrastructure, liquid-cooling requirements, and environmental burdens. The workflow covers equipment turnover, coolant use and recovery, operating electricity, technology scenarios, and uncertainty propagation.

The repository includes a complete runnable example with synthetic quarterly inputs and impact factors. The example data are generated by Demo/generate_inputs.py, so their origin and assumptions can be inspected directly.

Model structure

Training and inference demand
              ↓
GPU rack purchases, stock and retirement ──→ Retired hardware mass
              ↓
Liquid-cooling adoption and equipment retrofit
              ├──→ Coolant filling, replenishment, retirement and recovery
              └──→ IT electricity and cooling overhead
                                      ↓
                     Environmental burdens by activity
                                      ↓
             Scenario comparison, cumulative results and uncertainty

Demand and equipment. Training demand follows the number of model architectures, training frequency and compute per run. Inference demand follows model size, active users and daily token use. Training and inference have separate rack fleets. Purchases fill the gap between required compute and surviving capacity. Each purchase batch retains its GPU performance and board power, and retires according to a discrete lifetime distribution. Retired rack mass is also reported.

Cooling and material flows. A quarterly adoption path specifies the liquid-cooled share of rated IT capacity. New racks are assigned liquid cooling first; additional capacity comes from retrofitting surviving air-cooled racks. Retrofits retain the equipment's original age. Fluid is tracked by hardware batch and filling-quarter intensity, so later improvements affect new fills without rescaling existing inventories. Evaporation and maintenance losses are replenished each quarter. Retired fluid is collected, processed and reused; processing residues go to treatment, and unused recovered fluid carries forward as inventory.

Energy and burden. Operating electricity uses average opening and closing rated power, with separate training and inference utilization. Cooling overhead is calculated from liquid-cooled IT electricity and PUE - 1. The burden module combines activity quantities with factors for coolant production, retirement treatment, recovery processing and cooling electricity. It reports climate change (CC), human toxicity—cancer (HTC), and cumulative energy demand (CED), with source contributions kept separate. Quarterly electricity-background multipliers allow comparison of alternative grid pathways.

In the research workflow, life cycle assessment (LCA) and integrated assessment model (IAM) analyses are performed externally, and their outputs are compiled into input datasets for the core calculations.

Scenarios and analysis. AI growth and cooling adoption are independent dimensions. Technology strategies modify PUE overhead, the intensity of new coolant fills, and recovery. The same calculation functions are used for deterministic scenarios, Monte Carlo sampling and one-at-a-time sensitivity analysis.

Quick start

Python 3.9 or later; standard library only.

From the repository root:

python3 Demo/run_demo.py

The supplied configuration runs 24 quarters and 180 cases:

• Three AI growth paths: low, central and high.
• Three liquid-cooling adoption paths: low, central and high.
• Five strategies: baseline, improved PUE, advanced coolant, recovery and a combined strategy.
• Two cooling systems: single-phase and two-phase, evaluated separately.
• Two electricity backgrounds: steady and transition.

The command also runs 40 Monte Carlo samples and a sensitivity sweep for the selected central case. To increase the sample count or choose another output directory:

python3 Demo/run_demo.py --runs 200 --output Demo/output_extended

Paths default to the script's own directory, so the command also works from another working directory. Each run replaces its named output files.

Files

Module	Responsibility
demand_model.py	Training and inference compute demand.
scale_model.py	Purchase batches, surviving capacity, power and hardware retirement.
cooling_model.py	Liquid-cooled capacity, retrofits and installed fluid.
material_flow_model.py	Replenishment, processing, reuse, treatment and recovery storage.
energy_model.py	Workload IT electricity and cooling overhead.
burden_model.py	Activity quantities, impact factors and source-level burdens.
scenario_model.py	Cooling-share selection and technology improvement paths.
analysis.py	Monte Carlo sampling, quantiles and sensitivity.
simulation.py	Connect the modules and accumulate results.
model_inputs.py / run_demo.py	Input checks, command-line entry and export.

All modules are in Demo/. The six files in Demo/input/ contain quarterly demand drivers and hardware paths, lifetime probabilities, operating settings, technology strategies, impact factors, and electricity-background paths. Field names include units where applicable. The settings file selects the cumulative reporting start, analysis case, sample count and seed.

To regenerate the supplied synthetic inputs:

python3 Demo/generate_inputs.py

This replaces the six example input files. Editing them directly is sufficient for running a different example.

Results

Files are written to Demo/output/:

Output	Contents
scale_results.csv	Demand, available compute, rack additions/stock/retirements, GPU power and retired hardware mass.
material_flows.csv	Liquid-cooled capacity, retrofit flows and the coolant mass balance.
energy_results.csv	Training/inference IT electricity, liquid-cooled IT electricity and cooling overhead.
burden_results.csv	Impacts by case, quarter, source and indicator, including quantities, factors and units.
cumulative_results.csv	Cumulative flow quantities and burdens from the configured starting quarter.
scenario_summary.csv	Cumulative totals and final installed/recovered fluid stocks for each case.
uncertainty_runs.csv / uncertainty_draws.csv	Sampled case totals and parameter multipliers.
uncertainty_summary.csv	Mean and error bar of cumulative outcomes.
sensitivity_results.csv	Low/high parameter changes relative to the selected baseline.
run_manifest.json	Input hashes, seed, sample count and output row counts.

The first eight quarters establish the equipment and coolant stocks; cumulative reporting starts at Q09. Stocks remain quarter-end quantities and are never summed as consumption. CC, HTC and CED are reported in their own units.

Monte Carlo multipliers are uniform within the ranges in the settings file. Each draw is held across the time series and shared by both cooling systems. Model size and training compute share one demand multiplier; GPU performance and board power share a hardware multiplier. These illustrative correlations and ranges are configurable. Samples are accumulated before calculating cumulative quantiles. Sensitivity analysis varies one parameter at a time and reports a blank percentage when its baseline is zero.

Accounting conventions

Cooling adoption paths are nondecreasing; conversion from liquid cooling back to air cooling is not included. Technology improvements ramp from baseline at Q01 to the configured final multiplier at Q24. Recovery processing is charged per kg processed, while usable recovered fluid depends on both collection rate and processing yield. Reuse reduces virgin purchases directly, with no additional avoided-production credit.

Environmental totals cover coolant supply, retirement treatment, recovery processing and cooling electricity. IT electricity and retired hardware mass are reported separately. Evaporation and maintenance are physical outflows; direct PFAS fate/exposure characterization and hardware life-cycle impacts require additional factors. Remaining equipment fluid and recovery storage are carried as final inventories without an assumed terminal disposal event. The synthetic data define an example scenario, and results should be interpreted within those assumptions.

Validation

python3 -B -m unittest discover -s Demo/tests -v

Tests check demand units, purchase-vintage power, rack and coolant balances, retrofit age, filling intensity, recovery residues/storage, energy boundaries, burden aggregation, scenario effects, input alignment and seeded analysis. A standalone-copy test runs the example twice and checks that the exported files are identical.