Sustainability Scenarios

Power, heat, energy, carbon, and material accounting.

All domains · Classes A–Z

Source locations

• Inputs and calculations: mlsysim/engine/scenario_definitions/sustainability.py.
• Named configurations: mlsysim/engine/scenario_catalog/sustainability/.
• Result schemas: mlsysim/engine/result_types/sustainability.py.

Public imports and existing class reference URLs remain stable.

Scenario contracts

• BatteryBudgetScenario: A continuous power_draw against a battery and a required runtime.
• CarbonPricedPlacementScenario: A run of it_energy on fleet placed among regions with and without a carbon price.
• CascadeEnergyScenario: An edge model on every input, escalating a fraction to a cloud model over a radio link.
• CoolingScenario: Coolant flow that carries heat_load at temperature_rise.
• DataMovementEnergyScenario: One weight of bytes_per_param used for flops_per_param FLOPs at stated per-op energies.
• DemandReboundScenario: Per-unit energy scaled by a factor (or by a unit-price ratio) while volume scales by another.
• DevelopmentSweepScenario: A sweep of candidates runs, each costing relative_cost of the final run.
• DutyCycledPowerScenario: An always-on detector, a stage active a share of the time, and a full model run per event.
• EmbodiedPaybackScenario: A replacement for device that does its work with saved_fraction less energy, on named grids.
• EnergyPerInferenceScenario: Energy per inference across tiers: solver-derived device energies plus stated anchors.
• FacilityPowerScenario: devices accelerators at device_power in racks shaped like rack, at pue.
• GridPlacementScenario: One facility energy placed on each named grid, with an optional fractional energy cut.
• OffloadEnergyScenario: Energy to send payload by radio against running the model locally.
• OperationalCarbonScenario: Operational carbon = energy x PUE x grid intensity.
• OutageScenario: A failure domain of failed_devices down for repair_time during a job on fleet.
• PeriodicInferencePowerScenario: workload run once per period on hardware at its peak precision rate, idling between runs.
• PowerTransientScenario: A barrier-aligned load step on hardware and across n_devices.
• PueRetrofitScenario: A fixed IT load moved from pue_before to pue_after for period at an electricity price.
• RepeatedWorkEnergyScenario: fleet’s accelerators at rated power, rolled back by each named interval.
• RunFootprintScenario: A training run of device_hours on devices of device: energy, carbon, embodied carbon, water.
• ServiceLifeExtensionScenario: A hardware service life extended from short_life to long_life.
• ServingCrossoverScenario: Serving requests_per_day at energy_per_request against a one-time energy.
• TemporalShiftScenario: A flexible run of duration at power that may wait up to slack for a cleaner hour on a time-varying intensities signal.
• ThermalCeilingScenario: A model’s sustained power against a passively cooled device’s ceiling, before and after a reduction.
• TokenEnergyScenario: Joules per generated token: node power over aggregate token rate, well used and poorly used.
• WaterUseScenario: An IT load held for period at each named WUE.