Home / DC Solutions / Technical Manuals / AI Data Hall Cockpit

Technical Manual · Cockpit Basis

AI/HPC Data Hall — NVL72 Cockpit — Methodology & Formulas

Every input, equation, constant, output, and reference behind the GB200 NVL72 AI Data Hall Cockpit. All math is anchored to the locked Scenario A basis-of-design and executed by the deterministic engine js/datahall-calculations.js (DATAHALL_CALC) against the deep-frozen model in js/datahall-model.js (DATAHALL_MODEL) — no Math.random() on basis KPIs, no back-solved constants, no per-tab divergence.

Engine DATAHALL_CALC v1.0 Basis BASELINE-DECISION.md (locked 2026-05-17) Scenario A (132 kW / NVL72) Inputs LOCKED + tab selection Worked examples 10 (doc-21)
▶ Open the AI Data Hall Cockpit

01 Purpose & engineering basis

The AI Data Hall Cockpit is a deterministic digital-twin dashboard for a GB200 NVL72 HPC facility operating direct liquid cooling. It answers five engineering questions: what is the IT load per hall and per facility, how is heat split between liquid and air paths, what hydronic flow and how many CDUs are required, what is the honest bottom-up PUE, and what does the electrical distribution look like under the locked load.

Basis of design is locked: the DATAHALL_MODEL object is deep-frozen at page load. No tab can mutate it. Every KPI on every tab reads from the same DATAHALL_CALC.lockedState() and DATAHALL_CALC.pueBasis() call — Rule 1 (one source of truth) of standarization/ACCURACY_VALIDATION.md. The governing hardware reference is the NVIDIA GB200 NVL72 specification; thermal and facility methodology follows ASHRAE A2 and ISO/IEC 30134-2 (PUE) and ISO/IEC 30134-8 (CUEIT).

02 Inputs — LOCKED basis + tab selection

The primary input block is the immutable DATAHALL_MODEL (Scenario A, locked 2026-05-17). Tab-selection controls (scenario toggle, view mode) change which derived quantities are displayed but do not alter the underlying constants. All values below are from BASELINE-DECISION.md and verified in doc-21 worked examples.

ParameterSymbolValue (Scenario A)Source
Facility data hallshalls4BASELINE-DECISION.md
NVL72 domains per hallnvl72PerHall27BASELINE-DECISION.md
Physical rack positions per NVL72racksPerNVL722doc-21 Ex1 "1 NVL72 = 2 rack concept"
Physical rack positions per hallracksPerHall5427 × 2
GPU per NVL72 / CPU per NVL72gpuPerNVL72 / cpuPerNVL7272 / 36NVIDIA GB200 NVL72 spec
IT load per NVL72 pair (LOCKED)kwPerNVL72132 kWBASELINE-DECISION.md "Adopted load — 132 kW per NVL72 (NOT per rack)"
IT load per physical rack positionkwPerRack66 kW132 / 2 — doc-21 Ex1
IT load per hall (Scenario A)itPerHall_kW3,564 kW27 × 132 — doc-21 Ex1
IT load per facility (Scenario A)itPerFacility_kW14,256 kW3,564 × 4
Liquid capture ratioliquidCaptureRatio0.85BASELINE-DECISION.md "Liquid capture 85%"
TCS supply / returntcsSupplyC / tcsReturnC35 / 45 °CBASELINE-DECISION.md "35 / 45 °C (ΔT 10 K)"
TCS delta-TtcsDeltaT_K10 KBASELINE-DECISION.md
Water densityrhoKgPerL1.0 kg/Ldoc-21 Ex6
Water specific heatcpKjPerKgK4.186 kJ/kg·Kdoc-21 Ex6
LV voltage (line-line)voltageLL400 Vdoc-21 Ex3
Power factorpowerFactor0.96doc-21 Ex3
CDU ratingcdu.ratingKW350 kW (EoR)doc-21 Ex7
Chiller nameplate COPchiller.nameplateCOP6.8doc-21 Ex9; Carrier 19DV
UPS rating per feedups.ratingKW4,500 kW (2N)doc-21 Ex2
Transformer ratingtransformer.ratingMVA5 MVAdoc-21 Ex4
Active CRAH unitscrah.activeUnits5doc-21 Ex8
CRAH chilled-water ΔTcrah.chwDeltaT_K5 Kdoc-21 Ex8
PUE design band (target)pueDesignBand1.12 – 1.25BASELINE-DECISION.md
Data hall geometry (L × W × H)geometry32 × 20 × 4.2 mdoc-21 Ex10
Scenario A vs B: Scenario A (LOCKED) treats 132 kW as per NVL72 pair → 3,564 kW/hall. Scenario B (variant, NOT adopted) treats 132 kW as per physical rack → 7,128 kW/hall, which overloads the 4,500 kW 2N UPS (158% loading — impossible per doc-21 Ex2) and requires 12,000 A busway. The cockpit labels every KPI with its basis scenario and locks the derived panel to Scenario A.
GB300 reference study — not adopted: the platform selector may compare the locked GB200 footprint with one GB300 NVL72 rack per logical domain at the official up-to-142 kW/rack reference. With the same 27-domain planning count, that is 27 physical racks and 3,834 kW IT per hall (15.336 MW across four halls). It does not replace Scenario A, alter DATAHALL_MODEL, or prove that the existing electrical, liquid-cooling, structural or network design can support GB300.

03 Calculation methodology

All formulas below are implemented verbatim in js/datahall-calculations.js. Function names are in parentheses. Source lines cite 00-overview-audit.md "Core Calculation Engine" (lines 104-125) and doc-21 worked examples.

IT load — itLoad()

IT_kW = Σ rack_kW + network_kW + storage_kW In itLoad(rackPowerKWArray, networkKW, storageKW). For Scenario A: Σ rack_kW = 27 NVL72 × 132 kW = 3,564 kW. Network and storage additive.doc-00 line 107 · doc-21 Ex1

NVL72 power — nvl72Power()

NVL72_kW = racksPerNVL72 × rack_kW In nvl72Power(nvl36RackPowerKW, racksPerNVL72). 2 × 66 kW = 132 kW per NVL72 pair.doc-00 line 108 · doc-21 Ex1

Facility load — facilityKW()

Facility_kW = IT_kW + coolingElec_kW + upsLoss_kW + distLoss_kW + aux_kW In facilityKW(itKW, coolingElecKW, upsLossKW, distLossKW, auxKW). The denominator for PUE and CUE.doc-00 line 109

PUE — pue()

PUE = Facility_kW / IT_kW In pue(facilityKW, itKW). ISO/IEC 30134-2 definition. The result is DERIVED (cyan chip), not the TARGET (1.12–1.25 band from BASELINE). Rule 4: marketing target ≠ derived value.doc-00 line 110 · doc-21 Ex9 · ISO/IEC 30134-2

Liquid heat / air heat — liquidHeat(), airHeat()

Liquid_heat_kW = IT_kW × liquid_capture_ratio (0.85 for NVL72 direct liquid) Air_heat_kW = IT_kW × (1 − liquid_capture_ratio) In liquidHeat(itKW, captureRatio) and airHeat(itKW, captureRatio). Scenario A: 3,564 × 0.85 = 3,029 kW liquid; 3,564 × 0.15 = 535 kW residual air.doc-00 lines 114-115 · doc-21 Ex5

Hydronic TCS flow — hydronicFlowLPM()

Flow_LPM = Q_kW × 60 / (ρ_kg/L × Cp_kJ/kg·K × ΔT_K) In hydronicFlowLPM(qKW, rhoKgL, cpKjKgK, deltaTK). Q is the LIQUID CAPTURED heat (85% of IT), not full IT load. The UI must state this basis explicitly per doc-21 Ex6 "UI requirement: show whether flow is based on liquid captured heat or full rack heat."doc-00 line 117 · doc-21 Ex6 · BASELINE-DECISION.md

CDU count — cduRunningCount()

CDU_running = ceil( Liquid_heat_kW / CDU_rating_kW ) In cduRunningCount(liquidHeatKW, cduRatingKW). CDU_rating = 350 kW (end-of-row, doc-21 Ex7). Recommended installed count is N+1 or N+2 above running minimum.doc-21 Ex7

CRAH residual cooling — fwsFlowM3h()

perCRAH_kW = Air_heat_kW / activeUnits Flow_m3/h = Q_kW × 3600 / (ρ_kg/m³ × Cp_kJ/kg·K × ΔT_K) In fwsFlowM3h(qKW, rhoKgM3, cpKjKgK, deltaTK). ρ = 1000 kg/m³, ΔT = 5 K (CRAH chilled-water loop). Residual air carries the remaining 15% of IT heat. Doc-21 Ex8 demonstrates: Scenario B 214 kW/CRAH → 36.8 m³/h per unit.doc-00 line 118 · doc-21 Ex8

Chiller input — chillerInput()

Chiller_input_kW = cooling_heat_kW / COP_nameplate In chillerInput(coolingKW, cop). COP_nameplate = 6.8 (Carrier 19DV, doc-21 Ex9). This COP is NEVER calibrated or back-solved to hit a target PUE. "cooling_heat" in the PUE path equals full IT load (doc-21 Ex9: "cooling heat = 7,128 kW = IT").doc-00 line 119 · doc-21 Ex9

Bottom-up PUE with 5-part basis — pueBasis()

chillerInput_kW = IT_kW / COP (COP = 6.8 nameplate) pumps_kW = 200 × (IT / 7128) (scale from Ex9 ref) fans_kW = 250 × (IT / 7128) cduPumps_kW = 120 × (IT / 7128) crahFans_kW = 80 × (IT / 7128) upsDistLoss_kW = 300 × (IT / 7128) aux_kW = 150 × (IT / 7128) nonIT_kW = chillerInput + pumps + fans + cduPumps + crahFans + upsDistLoss + aux Facility_kW = IT_kW + nonIT_kW PUE = Facility_kW / IT_kW In pueBasis(itKW, model). The 6 ancillary reference values (200/250/120/80/300/150 kW) are the Scenario B reference point from doc-21 Ex9, scaled linearly for any IT load. The 5-part basis breakdown (IT / cooling / UPS-loss / dist-loss / aux) is returned for display per doc-00 lines 301-308. Nothing is back-solved.doc-21 Ex9 · doc-00 lines 301-308 · BASELINE-DECISION.md

Electrical — current, kVA, 3-phase kW

I_A = kW × 1000 / (√3 × V_LL × PF) [required current] kVA = kW / PF [apparent power] kW = √3 × V_LL × I × PF / 1000 [3-phase real power check] In requiredCurrentA(), kva(), threePhaseKW(). Spec uses 1.732 (not full √3 = 1.7320508) to match doc-21 Ex3 exactly. V = 400 V, PF = 0.96.doc-00 lines 122-123 · doc-21 Ex3 · doc-21 Ex4

Room volume — roomVolumeM3()

Volume_m³ = length_m × width_m × height_m In roomVolumeM3(lengthM, widthM, heightM). Geometry: 32 × 20 × 4.2 = 2,688 m³ per doc-21 Ex10. Fire-agent sizing (if implemented) requires further inputs per NFPA 2001 — room volume alone is insufficient.doc-21 Ex10

04 Constants & data sources

Every constant lives in the deep-frozen DATAHALL_MODEL with a // source: comment. No economically-material literal lives inside a function body. Key hardware constants:

EquipmentModel / ReferenceRating / ValueSource
UPSModular UPS, 2N A/B topology4,500 kW per feeddoc-21 Ex2; BASELINE-DECISION.md
TransformerCast-resin distribution transformer5 MVA (10 MVA conservative)doc-21 Ex4; BASELINE-DECISION.md
BuswayUndersized: 4,000 A → Selected: 6,300 A~5,357 A required (Scenario A)doc-21 Ex3
GeneratorCaterpillar 3516E2,500–2,750 kWNVIDIA GB200 NVL72 spec context; BASELINE "NOT 8 MW"
CDU350 kW end-of-row CDU350 kW thermaldoc-21 Ex7
ChillerCarrier 19DV water-cooled centrifugal1,231–4,044 kW; COP 6.8doc-21 Ex9; Carrier 19DV nameplate
CRAHActive units per hall5 active; ΔT 5 Kdoc-21 Ex8
GB300 study referenceGB300 NVL72 full-rack systemUp to 142 kW/rack; 72 GPU + 36 CPUNVIDIA Enterprise Reference Architecture components; non-adopted comparison only
PUE ancillary (Ex9 Scenario B reference)kW (at IT = 7,128 kW)Scales by
Chiller input (COP 6.8 nameplate)1,048IT / COP (not scaled)
Primary pumps200IT / 7,128
Drycooler / cooling tower fans250IT / 7,128
CDU pumps120IT / 7,128
CRAH fans80IT / 7,128
UPS + distribution loss300IT / 7,128
Auxiliary (lighting, controls, security)150IT / 7,128
Total non-IT (Scenario B reference)2,148

05 Outputs

OutputEngine functionUnitBasis chipInterpretation
IT load per hall / facilitylockedState().itPerHall_kWkWBOD LOCKED27 × 132 kW (Scenario A). Never randomised.
Liquid heatlockedState().liquidHeat_kWkWDERIVEDIT × 0.85; drives CDU count and TCS flow.
Residual air heatlockedState().airHeat_kWkWDERIVEDIT × 0.15; drives CRAH sizing.
TCS total flowlockedState().tcsFlowTotal_LPMLPMDERIVEDBased on liquid captured heat (85%), not full rack heat — label required.
TCS flow per rack positionlockedState().tcsFlowPerRack_LPMLPMDERIVEDTotal / 54 rack positions. Shows 80.4 LPM for Scenario A.
CDU running countlockedState().cduRunningCountcountDERIVEDceil(liquid_kW / 350). Recommended installed = N+1 or N+2 above running.
CRAH flow per unitlockedState().crahFlowPerUnit_m3hm³/hDERIVEDPer active CRAH at 5 K CHW delta-T.
Required busway currentlockedState().requiredCurrent_AADERIVEDMust not exceed busway rating. 5,357 A Scenario A → 6,300 A selected.
Transformer apparent powerlockedState().transformer_kVAkVADERIVEDIT_kW / PF. 3,713 kVA → 74.3% of 5 MVA (Scenario A, plausible).
UPS loading %lockedState().upsLoadingPct%DERIVEDIT_kW / UPS_rated. 79.2% Scenario A — plausible with margin.
PUE (bottom-up)pueBasis().pueDERIVEDFacility / IT. Shows the honest derived value, never the target.
PUE 5-part basispueBasis().basiskWDERIVEDIT / cooling / UPS-loss / dist-loss / aux — human-auditable breakdown.
Data hall volumedataHallVolume()BOD LOCKED32 × 20 × 4.2 = 2,688 m³ per hall.
Gross IT floor density — lockedRZDataHallRackDensity.getBaseline()kW/m²BOD LOCKED3,564 kW / 640 m² = 5.56875 kW/m²; 54 physical positions at 66 kW each.
GB300 capacity referenceRZDataHallRackDensity.studyReference('gb300-nvl72-142kw-study')rack / kW / MW / kW/m²REFERENCE STUDY27 racks × 142 kW = 3.834 MW/hall = 5.990625 kW/m². No adoption or current telemetry claim.
Release acceptanceExecutable evidenceRequired invariant
Alarm query and first-outtools/test-datahall-ai-alarm-query.mjsAll filter families compose; first-out is earliest per incident; export follows the filtered set.
Rack-density profilestools/test-datahall-ai-rack-density.mjsLocked GB200 values remain immutable; GB300 is calculated and labeled reference-only.
Electrical semantic truthtools/test-datahall-ai-electrical-topology.mjsNormal/fault scenarios reconcile all 54 racks and animation consumes semantic state.
Fire cause/effecttools/test-datahall-ai-fire-cause-effect.mjsZoned commands, feedback, inhibition and reset authority validate; BMS/DCIM is monitor-only.
Shared Design Studiotools/test-rz-design-studio.mjsCurrent/current-plus-study registration, validated issue metadata and accessible dialog lifecycle remain intact.
Operator UI integrationtools/test-datahall-ai-operator-ui.mjs plus browser journeyControls bind to the pure modules, dialogs remain accessible, and no document overflow or console error is introduced.

06 Worked example — Scenario A (LOCKED basis)

Numbers reproduce the engine output exactly for Scenario A (132 kW / NVL72). Examples 1–10 are the acceptance tests in tools/test-datahall-calc.mjs (57/57 assertions). Below is a compressed trace of the ten examples.

  1. Ex1 — IT load & rack count: 27 NVL72 × 2 racks = 54 rack positions/hall. 27 × 132 kW = IT = 3,564 kW/hall; 66 kW/rack position.
  2. Ex2 — UPS sizing: IT 3,564 kW ÷ UPS 4,500 kW = 79.2% load — plausible (2N, some margin). Scenario B 7,128 ÷ 4,500 = 158.4% — impossible.
  3. Ex3 — Busway current: I = 3,564 × 1000 / (1.732 × 400 × 0.96) = 5,357 A → 4,000 A busway undersized; 6,300 A selected.
  4. Ex4 — Transformer loading: kVA = 3,564 / 0.96 = 3,713 kVA; 5 MVA load = 74.3% — plausible.
  5. Ex5 — Cooling split: Liquid = 3,564 × 0.85 = 3,029 kW; Air = 3,564 × 0.15 = 535 kW.
  6. Ex6 — TCS flow (Scenario A): Flow = 3,029 × 60 / (1.0 × 4.186 × 10) = 4,342 LPM total; 4,342 / 54 = 80.4 LPM/rack. Flow basis = liquid captured heat (85%), not full rack heat.
  7. Ex7 — CDU count: ceil(3,029 / 350) = ceil(8.65) = 9 CDUs running; recommended installed 10–12.
  8. Ex8 — CRAH residual: 535 kW / 5 CRAH = 107 kW/unit; m³/h = 107 × 3600 / (1000 × 4.186 × 5) = 18.4 m³/h/CRAH.
  9. Ex9 — Chiller input & PUE (Scenario B reference point): Chiller = 7,128 / 6.8 = 1,048 kW. Non-IT = 1,048 + 200 + 250 + 120 + 80 + 300 + 150 = 2,148 kW. PUE = (7,128 + 2,148) / 7,128 = 1.30. For Scenario A (IT 3,564 kW scaled): PUE ~1.30 by same methodology.
  10. Ex10 — Data hall volume: 32 × 20 × 4.2 = 2,688 m³/hall. Fire-agent design requires additional NFPA 2001 inputs; room volume alone is insufficient.
PUE reading: The derived PUE (~1.30 at full load, Scenario B reference) reflects chiller-based direct liquid cooling without free-cooling bypass. The target band 1.12–1.25 (BASELINE-DECISION.md) is achievable with partial free cooling or heat rejection improvements but is a design target, not the operational result from this engine. Rule 4 (ACCURACY_VALIDATION.md): target ≠ derived value — the cockpit shows them in different colours and chips.

07 Accuracy validation — 6 rules

Codified in standarization/ACCURACY_VALIDATION.md and enforced by tools/probe-accuracy-validation.mjs (40/40 acceptance tests). Gate any change that touches the cockpit pages.

RuleRequirementFailure example
Rule 1 — One source of truthEvery KPI on every tab reads from DATAHALL_CALC.lockedState() or pueBasis() — never from a separate variable or inline literal.Dashboard showing 66 kW/rack while the electrical tab shows 132 kW/rack simultaneously.
Rule 2 — No Math.random on basis KPIsIT load, PUE, Facility load, GPU count, CDU count, UPS/transformer ratings: deterministic. Reload 20× — must be identical every time.Random jitter on TCS flow or dashboard rack-load causing different values each load.
Rule 3 — Every metric carries a denominatorPUE = Facility ÷ IT; UPS loading = load ÷ rated; transformer = kVA_load ÷ kVA_rating. Denominator shown in tooltip or inline.PUE shown without stating the IT kW basis.
Rule 4 — Target ≠ derived valueTarget PUE ≤ 1.12 (design band, blue chip) and derived PUE 1.30 (engine output, cyan chip) are two different numbers with different colour meanings.Showing "PUE 1.12" (target) in green as if it were the operating result.
Rule 5 — Terminology matches engineering basisUse "NVL72 domain" (132 kW logical pair) and "physical rack position" (66 kW per slot). Never call a 66 kW rack an "NVL72 rack" — NVIDIA spec says ~120 kW per NVL72 rack-scale system.Labelling the 66 kW slot as an "NVL72 rack" when it is one of two physical positions in an NVL72 footprint.
Rule 6 — Basis chip on every critical KPIEach KPI carries: MEASURED / DERIVED / TARGET / SIMULATED / BOD LOCKED / MANUAL. Click opens a drawer with formula, inputs, output, scope, denominator, source.A PUE tile with no chip — operator cannot determine if the value is a target or a derived result.

08 References & standards

09 Cockpit controls & view map

This operating map is additive to the locked methodology above. It identifies every visible control family in datahallAI.html and the state it is allowed to change. None of these controls writes to field equipment.

Control / viewHookExpected behaviorEngineering boundary
Portfolio / DC Solutions / PRD / Manual.bbtnNavigate without changing the locked scenario.Documentation is public; the cockpit keeps its existing tier gate.
Basis of DesignbodTrig, bodDrawerOpen the calculation-audit drawer populated from DATAHALL_CALC; export its printable PDF.It is an auditable design basis, not a field test certificate.
Generate Design / Design StudiogenDesignTrig, RZDesignStudioOpen the shared dialog, display one current engine snapshot and provenance, then allow only the registered document types and current/current-plus-study scopes.The study appendix is labeled non-adopted; it never mutates the snapshot. Focus is trapped and returned; failure is visible.
FAQ / ThemefaqTrig, themeToggleOpen the FAQ dialog; switch/persist the light/dark palette.Neither action changes model values.
Primary tabsbutton[data-t]Select Dashboard, Data Hall, Room Layout, Rack, Cooling, Electrical, Network, Fire, BMS, or Alarms & Events; one .pn remains active.Tab changes presentation only.
Rack-density platform studyplatformProfile, platformComparisonBodyKeep locked GB200 values visible and optionally show the GB300 planning reference.Selection is read-only presentation; GB300 is not adopted and does not alter any operating KPI.
Sidebar collapse / reopensideTog, sideReopenWiden the active diagram on desktop and remember the preference.Does not hide alarm meaning or alter data.
Floor selection / Overviewgenerated floor targets, floorBackOpen a tagged floor plan and return to the building view.Geometry is a design visualization, not a surveyed as-built.
Hall selectionbutton[data-dh="1…4"]Select DH-1 through DH-4 and update active hall context.All halls share Scenario A unless a future model declares a variance.
Electrical sub-tabsbutton[data-ep]Select facility Overview or DH-01…DH-04 SLD.Only one .ep panel is active.
Electrical operating scenarioelectricalScenario, electricalPathSummary, electricalTimelineEvaluate normal, utility/source, busway and rack-feed events; render served/2N/degraded/lost totals, path state and ordered event timeline.Semantic topology determines animation. De-energized paths never remain visually active; all meaning survives reduced motion.
SLD equipmentdata-sld-click, data-rz-line, data-rz-breakerOpen the appropriate SLD mimic or right inspector for MV, RMU, transformer, MSB, UPS, busway, rack PSU or cooling feed.Selection is read-only; no breaker command leaves the browser.
SLD presentationsldZoomIn, sldZoomOut, sldZoomFit, sldPrint, sldResultsToggle, sldMimicCloseZoom, fit, print, show/hide results or close the selected mimic.Results are modeled annotations, not IEC 60909/IEEE 1584 studies unless explicitly sourced.
Rack / component detailgenerated rack/tray/component targets, rackModalOpen the selected tag, type and component diagram.Component inventory follows the locked reference architecture.
CDU / chiller / cooling towerdata-cdu, data-ch, cooling-tower targetsOpen a tag-specific process HMI with status and values.Local pressure/flow/temperature movement is simulated sensor-class data.
Pump / TCS / chemistry equipmentgenerated equipment targets, eqHmiOpen the type-specific equipment HMI.Displayed setpoints/nameplates require tag-level source records before field use.
In-rack CDU / CRAHdata-ircdu, generated CRAH targetsOpen rack hydronic or air-side detail.Heat/flow basis remains Scenario A; jitter is not a sizing input.
Corridor servicesFWS, leak, cable-tray targetsOpen corridor-service HMI for the selected family.No service-isolation or safety command is implemented.
Battery ESSdata-bat, batHmiOpen the 480 VDC system/unit view for the selected hall and unit.Runtime/SOC/thermal values are simulation unless identified as engine basis.
Fire cause-and-effect matrixfireScenario, fireZone, fireCauseEffectBodySelect an initiating event/zone and inspect affected notification, lift, access, AHU/CRAH, smoke-control, suppression, EPO, generator, CCTV and BMS/DCIM outputs with required feedback.FACP is command authority. BMS/DCIM only publishes/monitors the event; the browser sends no command.
Alarm query workspacealarmFilterForm, alarmResultsBody, alarmDetailFilter by date/time, point/tag, system, severity, lifecycle, quality, value comparator, state transition, event/action/text or saved view; select a row for evidence.Records are immutable simulated fixtures, not a field historian.
First-out / CSValarmFirstOut, alarmExportCsvShow the earliest event per incident and export the current filtered record set with provenance fields.Export is evidence from the simulation only; it is not an acknowledged site log.
KPI basis cards.k[data-basis]Click, Enter or Space opens formula, inputs, output, scope, denominator, source, mode and timestamp.Uptime and alarm drawers explicitly identify design placeholders.
Close controls / Escape / scrimmodal-specific close IDs + shared modal controllerDismiss the active surface and return focus to its trigger.Focus must never fall silently to body.
Scroll to topscrollTopBtnReturn to the header without altering current scenario.Reduced-motion preference removes nonessential smooth animation.

10 Telemetry, alarm & modal operating map

The cockpit deliberately contains three point classes. Basis/derived values are repeatable engine outputs, sensor-class values may jitter within declared ranges, and placeholder values require a future event or field source. Read the data-mode and quality label before acting on any number.

Point familyRepresentative hookClass / cadenceAlarm or quality reading
Facility inventory and ITDHE.halls, dkIt, sPitBOD locked; immutable.4 halls, 27 NVL72/hall, 3,564 kW/hall, 14.256 MW facility.
Heat split / flow / CDU / CRAHsDLC, sAir, sCDU, sCRAHDerived; immutable.3,029/535 kW, 4,342 L/min, 9/12 CDU and five active CRAHs per hall.
Electrical capacityreqCurrentA, transformer/UPS/busway fieldsDerived; immutable.5,359 A, 3,713 kVA, 74.3% TX, 79.2% UPS failover, 6,300 A selected busway.
PUE / WUE / CUE / IT / GPU / domainsdkPue, dkWue, dkCue, dkIt, dkGpu, dkDomDerived or BOD locked; 4 s reassertion for dashboard fields.Final text is deterministic; source/denominator lives in the basis drawer and tooltip.
Uptime / active alarms KPIUptime card, dkAlmDesign placeholder.99.99% and zero active are not a persisted outage/event history.
TCS and room sensorssTS, sTR, hot/cold temperature/RH IDsSensor-class jitter; 4 s cadence.Jitter is allowed only around 35/45°C or declared room bands; it must not alter locked ΔT sizing.
Occupancy/accesspplCount, lastEntry, dkPpl, dkEntrySensor/browser-time simulation.Not a physical access-control record.
Fire/leak/maintenance countssbSmoke, sbHeat, sbVesda, sbRope, sbDisabled, sbMaintMixed static and sensor-class simulation.Do not infer code compliance or maintenance work orders.
FWS instrumentsfwsPI, fwsTI, fwsFMSensor-class jitter.Ranges are illustrative; every HMI reading needs a simulated/quality chip.
Alarm strips.dh-alarmbarRule evaluation every 4 s.Critical/warning checks cover inlet temperature, CDU margin, UPS loading, TCS ΔT and stale percentage; maintenance is two scheduled items.
Equipment modal summary.dh-modal-alarmlineSame alarm rule result at open.Summary-first state must match the active panel strip.
BMS service healthbmsGwOnline, bmsAlmActive, bmsAlmAck, bmsAlmClearedStatic service baseline plus shared rules.16/16 gateways is modeled; “cleared” currently reuses the maintenance count and is not a true event lifecycle.
Line / breaker qualitydata-rz-line, data-rz-breaker, inspector Live tabLocal rendered state.Seven breaker states and data-quality chip must remain distinguishable without color alone.
Global data modebody[data-rz-data-mode="simulated"]Persistent provenance.The word Simulated must remain visible even when values animate.
Alarm-query recordsRZDataHallAlarmQueryImmutable simulated event fixtures.Date/point/system/severity/lifecycle/quality/value/state/event/action/text filters compose; first-out selects earliest per incident and CSV exports the filtered set.
Electrical scenario truthRZDatahallAIElectrical.evaluateScenario()Pure semantic topology evaluation.Served + lost = 54; 2N/degraded are mutually interpretable availability classes; CSS animation is a consumer, never the source of truth.
Fire cause/effectRZDatahallAIFireCauseEffect.evaluateEvent()Immutable zoned training matrix.Rows expose command authority, expected feedback, inhibition and reset authority. FACP controls; BMS/DCIM monitor-only.
Rack-density comparisonRZDataHallRackDensityLocked baseline plus reference-only study.GB200 = 54 positions × 66 kW; GB300 study = 27 racks × up to 142 kW. Neither value is field telemetry.
Threshold and lifecycle source: the panel alarm rules use rack inlet >27°C warning / >30°C critical, CDU margin <15% / <5%, UPS load >80% / >95%, TCS ΔT >13 K / >15 K, and stale points >1% / >5%. The query workspace adopts ISA-18/IEC 62682 lifecycle and first-out terminology, but its records and thresholds remain deterministic review fixtures—not approved field setpoints, historian evidence or alarm-system conformance.

11 Glossary & RZExplain

The shared RZExplain scanner attaches contextual definitions to marked engineering terms. The table also records the exact meaning used by this cockpit.

TermCockpit meaningDo not confuse with
NVL72 domainLogical 72-GPU / 36-Grace domain at 132 kW in Scenario A, represented by two 66 kW physical rack positions.A single 66 kW physical rack position.
Direct liquid coolingCold-plate path capturing 85% of IT heat.Total facility cooling electrical power.
TCSTechnology Cooling System at 35/45°C, ΔT 10 K.Facility-water/chilled-water loop.
FWSFacility Water System coupled through CDU heat exchangers.Rack-side coolant circuit.
CDUCoolant Distribution Unit, 350 kW design rating, nine running per hall.Chiller or CRAH.
CRAHAir-side unit serving the 15% residual heat.Liquid-cooling primary path.
PUEFacility power divided by IT power; ≈1.30 is derived, 1.12–1.25 is a target band.A marketing target presented as measured output.
WUEWater per IT energy; 0.00 only for the declared dry-only baseline.Domestic/process water or an adiabatic configuration.
CUECarbon per IT energy; grid factor × PUE in the current calculation.Raw facility-kWh grid emission factor.
2NEach UPS feed can carry the protected load; normal display assumes equal sharing.N+1 parallel capacity.
Basis / sensor / placeholderImmutable engine fact / bounded simulated reading / value awaiting authoritative source.Three interchangeable meanings of “live”.
▶ Open the AI Data Hall Cockpit