2. Energy and cost metrics for HPC crash simulation

Crash simulation is one of the most compute-intensive workloads in automotive CAE. A single full-vehicle frontal impact model may contain 8–15 million shell and solid elements, run for 120–200 ms of physical time with an explicit time step of roughly 0.5–1.5 µs, and require hundreds of CPU cores for several hours. Before you can optimize cost or energy, you must be able to measure them consistently. This section defines the six metrics that form the accounting backbone of every later optimization decision: core-hours, wall-clock time, kWh, PUE, carbon intensity, and total cost of ownership (TCO).

Core-hours: the unit of computational work

A core-hour is one physical CPU core running for one hour. It is the fundamental billing and capacity unit on nearly every HPC cluster, whether the scheduler charges by node-hour or by core-hour. For a job that requests N cores and runs for T hours of wall-clock time, the consumed core-hours are:

core_hours = N_cores × wall_clock_hours × allocation_efficiency

# Example: 512 cores, 3.5 h wall clock, 92% allocation efficiency
core_hours = 512 × 3.5 × 0.92 = 1648.6 core-hours

The allocation efficiency term matters because schedulers often reserve whole nodes. If a job requests 100 cores on a 128-core node, you are billed for 128 cores unless the site supports sub-node allocation. Always confirm whether your site bills by requested cores, allocated cores, or node-hours — the difference can exceed 25% of the reported cost.

Core-hours alone do not tell you whether the simulation was efficient. A job that finishes in 2 hours on 1024 cores consumes the same core-hours as one that finishes in 4 hours on 512 cores, but the first may have suffered from poor parallel scaling. Core-hours measure work, not quality of work.

Wall-clock time: the constraint that drives cost

Wall-clock time is the elapsed real time from job submission to completion. It is the metric engineers feel most directly, because it determines how many design iterations fit into a development cycle. It is also the metric that interacts most sharply with cost: doubling core count typically reduces wall-clock time by less than half due to parallel overhead, so the marginal cost per unit of time saved rises steeply.

For crash simulation, wall-clock time is dominated by three phases: model initialization and domain decomposition, explicit time integration, and output writing. On a well-tuned LS-DYNA or Pam-Crash job, the integration phase should account for 85–95% of wall-clock time. If initialization exceeds 10%, investigate I/O and decomposition settings before adding cores.

kWh: translating compute into energy

Energy consumption is measured in kilowatt-hours (kWh). For a compute job, the energy attributable to the job is the product of average power draw and wall-clock time, summed across all nodes involved:

energy_kWh = Σ (P_node_avg_kW × wall_clock_hours)

# Example: 8 nodes, each drawing 1.8 kW average, 3.5 h
energy_kWh = 8 × 1.8 × 3.5 = 50.4 kWh

Average power is not the nameplate rating. A dual-socket server rated at 2.5 kW may draw 1.4 kW at idle, 1.9 kW under a memory-bound explicit solver, and 2.3 kW under a compute-bound implicit phase. Use measured values from BMC telemetry (IPMI/Redfish) or job-level power capping data where available. For crash simulation, memory bandwidth is often the limiting resource, so power draw tends to plateau well below thermal design power.

PUE: from facility energy to IT energy

Power Usage Effectiveness (PUE) is the ratio of total facility power to IT equipment power:

PUE = total_facility_power / IT_equipment_power

# Example: facility draws 120 kW, IT equipment draws 90 kW
PUE = 120 / 90 = 1.33

A PUE of 1.33 means that for every 1 kWh delivered to servers, an additional 0.33 kWh is consumed by cooling, power distribution losses, and lighting. Hyperscale facilities routinely achieve 1.1–1.2; older enterprise data centers may exceed 1.8. When you compute the energy cost of a simulation, multiply IT energy by PUE to get the true facility energy:

facility_energy_kWh = IT_energy_kWh × PUE
# 50.4 kWh × 1.33 = 67.0 kWh

PUE is a site-level metric, not a job-level one. It varies with ambient temperature, load level, and cooling mode. For cost accounting, use a seasonal or annual average rather than a single instantaneous reading.

Carbon intensity: converting kWh to emissions

Carbon intensity expresses the greenhouse gas emissions per unit of electricity, typically in gCO₂e/kWh. It depends on the generation mix at the time and location of consumption. A grid dominated by coal may exceed 700 gCO₂e/kWh; a grid with heavy hydro or nuclear may be below 50 gCO₂e/kWh.

emissions_kgCO2e = facility_energy_kWh × carbon_intensity_gCO2e_per_kWh / 1000

# Example: 67.0 kWh × 350 gCO₂e/kWh
emissions_kgCO2e = 67.0 × 350 / 1000 = 23.5 kgCO₂e

Carbon intensity is time-varying. If your scheduler supports deferrable or flexible jobs, shifting a batch of crash simulations to a low-carbon window can reduce reported emissions without changing core-hours. This is increasingly relevant for corporate sustainability reporting under frameworks such as GHG Protocol Scope 2.

TCO: the full cost picture

Total cost of ownership for HPC simulation extends far beyond electricity. A practical TCO model for a crash simulation workload includes:

A simplified per-job TCO calculation might look like this:

# Example assumptions (illustrative, not measured)
compute_rate     = $0.045 / core-hour
license_rate     = $0.020 / core-hour
electricity_rate = $0.12 / kWh
overhead_factor  = 1.25   # staff, storage, facility

core_hours = 1648.6
facility_kWh = 67.0

compute_cost = 1648.6 × 0.045 = $74.19
license_cost = 1648.6 × 0.020 = $32.97
energy_cost  = 67.0 × 0.12    = $8.04
subtotal     = $115.20
TCO          = 115.20 × 1.25  = $144.00

Notice that energy is only about 7% of the subtotal in this example. Compute and license costs dominate. This is a critical insight: energy optimization and cost optimization are not always the same thing. Reducing wall-clock time by adding cores may increase core-hours and license token consumption even as it reduces kWh. The right objective depends on whether your constraint is budget, carbon, or engineering throughput.

How the metrics relate

The six metrics form a chain from computational work to business impact. The SVG below shows how a single simulation job maps onto each metric and where the key conversion factors enter.

Practical measurement checklist

To make these metrics actionable, establish a consistent data collection routine. The following checklist is designed for a site running LS-DYNA or Pam-Crash on a shared cluster:

• Core-hours: Extract from scheduler accounting (Slurm sacct, PBS qstat -x) using allocated cores, not requested cores.
• Wall-clock time: Record both scheduler-reported elapsed time and solver-reported CPU time; the ratio reveals parallel efficiency.
• kWh: Pull node-level power from BMC (Redfish /Chassis/Power) at 1-minute intervals; integrate over the job window.
• PUE: Obtain from facility DCIM or compute from CRAC and UPS readings; use a monthly average.
• Carbon intensity: Use a grid operator API or a published annual average for your region; note the source and vintage.
• TCO: Maintain a rate card with compute, license, energy, and overhead components; review quarterly.

With these six metrics defined and instrumented, you can compare design alternatives on equal footing. The next section applies them to a concrete optimization problem: reducing core-hours without extending wall-clock time beyond a deadline.