4.6 KiB
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，未漏乘。