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.
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.
| Parameter | Symbol | Value (Scenario A) | Source |
|---|---|---|---|
| Facility data halls | halls | 4 | BASELINE-DECISION.md |
| NVL72 domains per hall | nvl72PerHall | 27 | BASELINE-DECISION.md |
| Physical rack positions per NVL72 | racksPerNVL72 | 2 | doc-21 Ex1 "1 NVL72 = 2 rack concept" |
| Physical rack positions per hall | racksPerHall | 54 | 27 × 2 |
| GPU per NVL72 / CPU per NVL72 | gpuPerNVL72 / cpuPerNVL72 | 72 / 36 | NVIDIA GB200 NVL72 spec |
| IT load per NVL72 pair (LOCKED) | kwPerNVL72 | 132 kW | BASELINE-DECISION.md "Adopted load — 132 kW per NVL72 (NOT per rack)" |
| IT load per physical rack position | kwPerRack | 66 kW | 132 / 2 — doc-21 Ex1 |
| IT load per hall (Scenario A) | itPerHall_kW | 3,564 kW | 27 × 132 — doc-21 Ex1 |
| IT load per facility (Scenario A) | itPerFacility_kW | 14,256 kW | 3,564 × 4 |
| Liquid capture ratio | liquidCaptureRatio | 0.85 | BASELINE-DECISION.md "Liquid capture 85%" |
| TCS supply / return | tcsSupplyC / tcsReturnC | 35 / 45 °C | BASELINE-DECISION.md "35 / 45 °C (ΔT 10 K)" |
| TCS delta-T | tcsDeltaT_K | 10 K | BASELINE-DECISION.md |
| Water density | rhoKgPerL | 1.0 kg/L | doc-21 Ex6 |
| Water specific heat | cpKjPerKgK | 4.186 kJ/kg·K | doc-21 Ex6 |
| LV voltage (line-line) | voltageLL | 400 V | doc-21 Ex3 |
| Power factor | powerFactor | 0.96 | doc-21 Ex3 |
| CDU rating | cdu.ratingKW | 350 kW (EoR) | doc-21 Ex7 |
| Chiller nameplate COP | chiller.nameplateCOP | 6.8 | doc-21 Ex9; Carrier 19DV |
| UPS rating per feed | ups.ratingKW | 4,500 kW (2N) | doc-21 Ex2 |
| Transformer rating | transformer.ratingMVA | 5 MVA | doc-21 Ex4 |
| Active CRAH units | crah.activeUnits | 5 | doc-21 Ex8 |
| CRAH chilled-water ΔT | crah.chwDeltaT_K | 5 K | doc-21 Ex8 |
| PUE design band (target) | pueDesignBand | 1.12 – 1.25 | BASELINE-DECISION.md |
| Data hall geometry (L × W × H) | geometry | 32 × 20 × 4.2 m | doc-21 Ex10 |
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()
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()
nvl72Power(nvl36RackPowerKW, racksPerNVL72). 2 × 66 kW = 132 kW per NVL72 pair.doc-00 line 108 · doc-21 Ex1
Facility load — facilityKW()
facilityKW(itKW, coolingElecKW, upsLossKW, distLossKW, auxKW). The denominator for PUE and CUE.doc-00 line 109
PUE — pue()
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()
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()
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()
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()
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()
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()
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
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()
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:
| Equipment | Model / Reference | Rating / Value | Source |
|---|---|---|---|
| UPS | Modular UPS, 2N A/B topology | 4,500 kW per feed | doc-21 Ex2; BASELINE-DECISION.md |
| Transformer | Cast-resin distribution transformer | 5 MVA (10 MVA conservative) | doc-21 Ex4; BASELINE-DECISION.md |
| Busway | Undersized: 4,000 A → Selected: 6,300 A | ~5,357 A required (Scenario A) | doc-21 Ex3 |
| Generator | Caterpillar 3516E | 2,500–2,750 kW | NVIDIA GB200 NVL72 spec context; BASELINE "NOT 8 MW" |
| CDU | 350 kW end-of-row CDU | 350 kW thermal | doc-21 Ex7 |
| Chiller | Carrier 19DV water-cooled centrifugal | 1,231–4,044 kW; COP 6.8 | doc-21 Ex9; Carrier 19DV nameplate |
| CRAH | Active units per hall | 5 active; ΔT 5 K | doc-21 Ex8 |
| GB300 study reference | GB300 NVL72 full-rack system | Up to 142 kW/rack; 72 GPU + 36 CPU | NVIDIA 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,048 | IT / COP (not scaled) |
| Primary pumps | 200 | IT / 7,128 |
| Drycooler / cooling tower fans | 250 | IT / 7,128 |
| CDU pumps | 120 | IT / 7,128 |
| CRAH fans | 80 | IT / 7,128 |
| UPS + distribution loss | 300 | IT / 7,128 |
| Auxiliary (lighting, controls, security) | 150 | IT / 7,128 |
| Total non-IT (Scenario B reference) | 2,148 |
05 Outputs
| Output | Engine function | Unit | Basis chip | Interpretation |
|---|---|---|---|---|
| IT load per hall / facility | lockedState().itPerHall_kW | kW | BOD LOCKED | 27 × 132 kW (Scenario A). Never randomised. |
| Liquid heat | lockedState().liquidHeat_kW | kW | DERIVED | IT × 0.85; drives CDU count and TCS flow. |
| Residual air heat | lockedState().airHeat_kW | kW | DERIVED | IT × 0.15; drives CRAH sizing. |
| TCS total flow | lockedState().tcsFlowTotal_LPM | LPM | DERIVED | Based on liquid captured heat (85%), not full rack heat — label required. |
| TCS flow per rack position | lockedState().tcsFlowPerRack_LPM | LPM | DERIVED | Total / 54 rack positions. Shows 80.4 LPM for Scenario A. |
| CDU running count | lockedState().cduRunningCount | count | DERIVED | ceil(liquid_kW / 350). Recommended installed = N+1 or N+2 above running. |
| CRAH flow per unit | lockedState().crahFlowPerUnit_m3h | m³/h | DERIVED | Per active CRAH at 5 K CHW delta-T. |
| Required busway current | lockedState().requiredCurrent_A | A | DERIVED | Must not exceed busway rating. 5,357 A Scenario A → 6,300 A selected. |
| Transformer apparent power | lockedState().transformer_kVA | kVA | DERIVED | IT_kW / PF. 3,713 kVA → 74.3% of 5 MVA (Scenario A, plausible). |
| UPS loading % | lockedState().upsLoadingPct | % | DERIVED | IT_kW / UPS_rated. 79.2% Scenario A — plausible with margin. |
| PUE (bottom-up) | pueBasis().pue | — | DERIVED | Facility / IT. Shows the honest derived value, never the target. |
| PUE 5-part basis | pueBasis().basis | kW | DERIVED | IT / cooling / UPS-loss / dist-loss / aux — human-auditable breakdown. |
| Data hall volume | dataHallVolume() | m³ | BOD LOCKED | 32 × 20 × 4.2 = 2,688 m³ per hall. |
| Gross IT floor density — locked | RZDataHallRackDensity.getBaseline() | kW/m² | BOD LOCKED | 3,564 kW / 640 m² = 5.56875 kW/m²; 54 physical positions at 66 kW each. |
| GB300 capacity reference | RZDataHallRackDensity.studyReference('gb300-nvl72-142kw-study') | rack / kW / MW / kW/m² | REFERENCE STUDY | 27 racks × 142 kW = 3.834 MW/hall = 5.990625 kW/m². No adoption or current telemetry claim. |
| Release acceptance | Executable evidence | Required invariant |
|---|---|---|
| Alarm query and first-out | tools/test-datahall-ai-alarm-query.mjs | All filter families compose; first-out is earliest per incident; export follows the filtered set. |
| Rack-density profiles | tools/test-datahall-ai-rack-density.mjs | Locked GB200 values remain immutable; GB300 is calculated and labeled reference-only. |
| Electrical semantic truth | tools/test-datahall-ai-electrical-topology.mjs | Normal/fault scenarios reconcile all 54 racks and animation consumes semantic state. |
| Fire cause/effect | tools/test-datahall-ai-fire-cause-effect.mjs | Zoned commands, feedback, inhibition and reset authority validate; BMS/DCIM is monitor-only. |
| Shared Design Studio | tools/test-rz-design-studio.mjs | Current/current-plus-study registration, validated issue metadata and accessible dialog lifecycle remain intact. |
| Operator UI integration | tools/test-datahall-ai-operator-ui.mjs plus browser journey | Controls 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.
- 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.
- 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.
- Ex3 — Busway current: I = 3,564 × 1000 / (1.732 × 400 × 0.96) = 5,357 A → 4,000 A busway undersized; 6,300 A selected.
- Ex4 — Transformer loading: kVA = 3,564 / 0.96 = 3,713 kVA; 5 MVA load = 74.3% — plausible.
- Ex5 — Cooling split: Liquid = 3,564 × 0.85 = 3,029 kW; Air = 3,564 × 0.15 = 535 kW.
- 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.
- Ex7 — CDU count: ceil(3,029 / 350) = ceil(8.65) = 9 CDUs running; recommended installed 10–12.
- Ex8 — CRAH residual: 535 kW / 5 CRAH = 107 kW/unit; m³/h = 107 × 3600 / (1000 × 4.186 × 5) = 18.4 m³/h/CRAH.
- 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.
- 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.
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.
| Rule | Requirement | Failure example |
|---|---|---|
Rule 1 — One source of truth | Every 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 KPIs | IT 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 denominator | PUE = 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 value | Target 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 basis | Use "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 KPI | Each 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
- NVIDIA DGX GB200 hardware documentation — governing hardware context for the locked 72-GPU / 36-Grace-CPU, direct-liquid-cooled GB200 baseline.
- NVIDIA Enterprise Reference Architecture — components — official GB300 full-rack and up-to-142 kW/rack reference used only in the non-adopted comparison.
- BASELINE-DECISION.md (locked 2026-05-17) — Single immutable source of truth for the whole cockpit: 4 halls, 27 NVL72/hall, 132 kW/NVL72 (Scenario A), 85% liquid capture, TCS 35/45 °C, PUE design band 1.12–1.25.
- 21-calculation-worked-examples.md (doc-21) — 10 fully-traced examples (Ex1–Ex10) that are the acceptance test cases for
tools/test-datahall-calc.mjs(57/57 assertions). - 00-overview-audit.md (doc-00) — Core Calculation Engine definition (lines 104-125), Source Sanity References, equipment corrections (Cat 3516E ≈ 2.5–2.75 MW).
- ASHRAE A2 / ASHRAE 90.4 — Inlet temperature envelope for HPC cooling; energy efficiency for data centres.
- ISO/IEC 30134-2 — Data centre key performance indicators: Power Usage Effectiveness (PUE) — definition, measurement scope, and boundary.
- ISO/IEC 30134-8 — Carbon Usage Effectiveness relative to IT equipment energy (CUEIT).
- Carrier 19DV centrifugal chiller — Nameplate COP 6.8 used in doc-21 Ex9 (not calibrated to hit a target PUE).
- Engine sources —
js/datahall-calculations.js(DATAHALL_CALC, pure derivation engine) +js/datahall-model.js(DATAHALL_MODEL, deep-frozen basis). - standarization/ACCURACY_VALIDATION.md — 6 accuracy rules + 40 acceptance tests enforced by
tools/probe-accuracy-validation.mjs. - ISA-18 alarm-management series — lifecycle, operator response, rationalization and first-out context for the simulated alarm workspace.
- IEC 62682:2022 — management of alarms for process industries; terminology and acceptance reference, not a conformance claim.
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 / view | Hook | Expected behavior | Engineering boundary |
|---|---|---|---|
| Portfolio / DC Solutions / PRD / Manual | .bbtn | Navigate without changing the locked scenario. | Documentation is public; the cockpit keeps its existing tier gate. |
| Basis of Design | bodTrig, bodDrawer | Open 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 Studio | genDesignTrig, RZDesignStudio | Open 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 / Theme | faqTrig, themeToggle | Open the FAQ dialog; switch/persist the light/dark palette. | Neither action changes model values. |
| Primary tabs | button[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 study | platformProfile, platformComparisonBody | Keep 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 / reopen | sideTog, sideReopen | Widen the active diagram on desktop and remember the preference. | Does not hide alarm meaning or alter data. |
| Floor selection / Overview | generated floor targets, floorBack | Open a tagged floor plan and return to the building view. | Geometry is a design visualization, not a surveyed as-built. |
| Hall selection | button[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-tabs | button[data-ep] | Select facility Overview or DH-01…DH-04 SLD. | Only one .ep panel is active. |
| Electrical operating scenario | electricalScenario, electricalPathSummary, electricalTimeline | Evaluate 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 equipment | data-sld-click, data-rz-line, data-rz-breaker | Open 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 presentation | sldZoomIn, sldZoomOut, sldZoomFit, sldPrint, sldResultsToggle, sldMimicClose | Zoom, 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 detail | generated rack/tray/component targets, rackModal | Open the selected tag, type and component diagram. | Component inventory follows the locked reference architecture. |
| CDU / chiller / cooling tower | data-cdu, data-ch, cooling-tower targets | Open a tag-specific process HMI with status and values. | Local pressure/flow/temperature movement is simulated sensor-class data. |
| Pump / TCS / chemistry equipment | generated equipment targets, eqHmi | Open the type-specific equipment HMI. | Displayed setpoints/nameplates require tag-level source records before field use. |
| In-rack CDU / CRAH | data-ircdu, generated CRAH targets | Open rack hydronic or air-side detail. | Heat/flow basis remains Scenario A; jitter is not a sizing input. |
| Corridor services | FWS, leak, cable-tray targets | Open corridor-service HMI for the selected family. | No service-isolation or safety command is implemented. |
| Battery ESS | data-bat, batHmi | Open 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 matrix | fireScenario, fireZone, fireCauseEffectBody | Select 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 workspace | alarmFilterForm, alarmResultsBody, alarmDetail | Filter 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 / CSV | alarmFirstOut, alarmExportCsv | Show 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 / scrim | modal-specific close IDs + shared modal controller | Dismiss the active surface and return focus to its trigger. | Focus must never fall silently to body. |
| Scroll to top | scrollTopBtn | Return 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 family | Representative hook | Class / cadence | Alarm or quality reading |
|---|---|---|---|
| Facility inventory and IT | DHE.halls, dkIt, sPit | BOD locked; immutable. | 4 halls, 27 NVL72/hall, 3,564 kW/hall, 14.256 MW facility. |
| Heat split / flow / CDU / CRAH | sDLC, sAir, sCDU, sCRAH | Derived; immutable. | 3,029/535 kW, 4,342 L/min, 9/12 CDU and five active CRAHs per hall. |
| Electrical capacity | reqCurrentA, transformer/UPS/busway fields | Derived; immutable. | 5,359 A, 3,713 kVA, 74.3% TX, 79.2% UPS failover, 6,300 A selected busway. |
| PUE / WUE / CUE / IT / GPU / domains | dkPue, dkWue, dkCue, dkIt, dkGpu, dkDom | Derived 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 KPI | Uptime card, dkAlm | Design placeholder. | 99.99% and zero active are not a persisted outage/event history. |
| TCS and room sensors | sTS, sTR, hot/cold temperature/RH IDs | Sensor-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/access | pplCount, lastEntry, dkPpl, dkEntry | Sensor/browser-time simulation. | Not a physical access-control record. |
| Fire/leak/maintenance counts | sbSmoke, sbHeat, sbVesda, sbRope, sbDisabled, sbMaint | Mixed static and sensor-class simulation. | Do not infer code compliance or maintenance work orders. |
| FWS instruments | fwsPI, fwsTI, fwsFM | Sensor-class jitter. | Ranges are illustrative; every HMI reading needs a simulated/quality chip. |
| Alarm strips | .dh-alarmbar | Rule 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-alarmline | Same alarm rule result at open. | Summary-first state must match the active panel strip. |
| BMS service health | bmsGwOnline, bmsAlmActive, bmsAlmAck, bmsAlmCleared | Static 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 quality | data-rz-line, data-rz-breaker, inspector Live tab | Local rendered state. | Seven breaker states and data-quality chip must remain distinguishable without color alone. |
| Global data mode | body[data-rz-data-mode="simulated"] | Persistent provenance. | The word Simulated must remain visible even when values animate. |
| Alarm-query records | RZDataHallAlarmQuery | Immutable 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 truth | RZDatahallAIElectrical.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/effect | RZDatahallAIFireCauseEffect.evaluateEvent() | Immutable zoned training matrix. | Rows expose command authority, expected feedback, inhibition and reset authority. FACP controls; BMS/DCIM monitor-only. |
| Rack-density comparison | RZDataHallRackDensity | Locked baseline plus reference-only study. | GB200 = 54 positions × 66 kW; GB300 study = 27 racks × up to 142 kW. Neither value is field telemetry. |
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.
| Term | Cockpit meaning | Do not confuse with |
|---|---|---|
| NVL72 domain | Logical 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 cooling | Cold-plate path capturing 85% of IT heat. | Total facility cooling electrical power. |
| TCS | Technology Cooling System at 35/45°C, ΔT 10 K. | Facility-water/chilled-water loop. |
| FWS | Facility Water System coupled through CDU heat exchangers. | Rack-side coolant circuit. |
| CDU | Coolant Distribution Unit, 350 kW design rating, nine running per hall. | Chiller or CRAH. |
| CRAH | Air-side unit serving the 15% residual heat. | Liquid-cooling primary path. |
| PUE | Facility power divided by IT power; ≈1.30 is derived, 1.12–1.25 is a target band. | A marketing target presented as measured output. |
| WUE | Water per IT energy; 0.00 only for the declared dry-only baseline. | Domestic/process water or an adiabatic configuration. |
| CUE | Carbon per IT energy; grid factor × PUE in the current calculation. | Raw facility-kWh grid emission factor. |
| 2N | Each UPS feed can carry the protected load; normal display assumes equal sharing. | N+1 parallel capacity. |
| Basis / sensor / placeholder | Immutable engine fact / bounded simulated reading / value awaiting authoritative source. | Three interchangeable meanings of “live”. |