# POC-B 实测结果（gpr_poc headless 度量）

工具：`tools/gpr_poc`（CLI），构建产物 `build/release/tools/gpr_poc/gpr_poc.exe`。
执行机：Windows 11，MSVC（VS18 Community）+ Ninja，Release（/O2）。
日期：2026-06-23。

整条地基链路：
`assembleGprSurvey → buildGprVolume → ChunkedVolumeStore::write → buildPyramid → WholeVolumeSource(load)`。

---

## 1. selftest（合成极小数据）—— PASS

命令：`gpr_poc selftest`

- 构造 2 通道合成 survey（samples=8，traces=12），写临时 `.iprb/.iprh/.ord`，
  走完整 `assembleGprSurvey → buildGprVolume → write(brick=4) → buildPyramid(1) → WholeVolumeSource`。
- 断言：ntraces/samples/channels、channelY 升序、GridSpec `2x2x8`、建体维度、
  金字塔层数==2、整卷维度一致、(0,0,0) 非 blank。
- 结果：**PASS**（退出码 0）。

结论：除真实 `.iprb` 读入外，**整条地基管线在合成数据上端到端跑通**
（装配几何、建体量化、分块压缩落盘、金字塔降采样、整卷重组加载均正确）。

---

## 2. 真实数据（D:\Downloads\明星路，线 001）—— **PASS（实测）**

> 更新（任务 9b，2026-06-23）：先前 BLOCKED 的根因（`readIprb` 硬假设
> `traces = lastTrace + 1`）已修复。`readIprb` 改为**以文件大小为权威**
> （`traces = fileBytes / (samples·2)`），真实数据装配通过。

命令：
```
gpr_poc build "D:\Downloads\明星路" --line 001 --cellXY 0.2 --cellZ 0.05 --out <store> --levels 2
gpr_poc load  <store>
```

### 根因回顾（off-by-one：lastTrace+1 vs 真实道数）

旧 `readIprb` 硬编码 `traces = h.lastTrace + 1` 并对文件字节做严格相等校验。
真实明星路每个通道文件恰好含 `lastTrace` 条道（少 1 道），逐通道实测：

| 通道 | 文件字节 | samples | LAST TRACE | 旧期望(=samples·(lastTrace+1)·2) | 实际道数(=bytes/(samples·2)) |
|------|----------|---------|------------|----------------------------------|------------------------------|
| A01  | 74390810 | 821 | 45305 | 74392452 | 45305 |
| A02  | 74394094 | 821 | 45307 | 74395736 | 45307 |
| A12  | 74392452 | 821 | 45306 | 74394094 | 45306 |

**规律一致**：所有通道「实际道数 == LAST TRACE」。修复后 `readIprb` 不再用 `lastTrace`
决定道数，装配按各通道道数最小值对齐（min=45305）。

### build 实测指标（line 001, cellXY=0.2, cellZ=0.05, levels=2）

| 指标 | 值 |
|------|-----|
| 发现通道数 | 14 |
| 装配后 ntraces / samples / channels | 45305 / 821 / 14 |
| dx / dz（米） | 0.049084 / **0.00977756** |
| GridSpec（nx×ny×nz） | **11120 × 8 × 162** |
| 体素数 | 14,411,520 |
| 原始体积（int16） | 28,823,040 B（27.49 MB） |
| 落盘 data.bin（含金字塔各级） | 15,317,628 B（14.61 MB） |
| 压缩比（原始/落盘） | **1.88×** |
| 装配耗时 | 12,551 ms |
| 建体耗时 | 1,926 ms |
| 落盘耗时 | 3,597 ms |
| 金字塔耗时 | 3,923 ms |
| build 端到端墙钟 | ≈22.6 s |
| 峰值内存 | **4,975 MB** |

### load 实测指标

| 指标 | 值 |
|------|-----|
| 加载耗时 | 335 ms |
| 整卷维度 | 11120 × 8 × 162 |
| 整卷字节 | 28,823,040 B（27.49 MB） |
| 峰值内存 | 38 MB |

无 OOM、无超时，未调粗 cellXY 即一次通过。

### 峰值内存说明（4.98 GB）

峰值由**装配阶段**主导：同时持有 14 通道 BScan（14×74 MB ≈ 1 GB int16）
+ `GprSurvey.values` 以 **double** 存（14×45305×821×8 B ≈ 4.2 GB）。
建体/落盘/加载本身很轻（load 仅 38 MB）。若后续要压内存，可让 survey.values
改存 int16 或流式装配，但当前规模单机可承受，POC 不做此优化。

---

## 3. 深度/Z 尺度诊断结论（任务 9b）

先前 §3 预估「nz=1、深度量级 8e-6 m」是在 SOIL VELOCITY **未正确换算**时写下的
（当时按 100 m/s 计算）。Task 1 已将 `SOIL VELOCITY`（头文件单位 m/µs）×1e6 存为 m/s，
本任务实测确认整条 Z 链路正确：

- 头：SAMPLES=821，TIMEWINDOW=160.352 ns，SOIL VELOCITY=100（→ 1e8 m/s）。
- `depthOfSample(820) = 1e8 × 160.352e-9 / 2 ≈ **8.018 m**`（深度跨度合理）。
- `dz = depthOfSample(1) = 8.018/820 ≈ **0.009778 m**`（实测 0.00977756，吻合）。
- 故 cellZ=0.05 下 `nz = ceil(8.018/0.05)+1 = **162**`（实测 162，非 1）。

**结论**：`assembler`/`GprGeometry`/CLI `specFromSurvey` 的 Z 计算**全部正确**，
无需改 CLI。先前的 nz=1 症状是 soilVelocity 换算缺失时代的遗留，现已不复存在。
CLI 的 `specFromSurvey` 用的是 `survey.dz`（来自 `depthOfSample`），未误用原始 100，未漏乘。