Summary
The golden packer treats every .dat file under D/ as a spatial field of the form <x> [<y> <z>] <value> and keeps only the last column of each row. Probe output is not a spatial field — it is a multi-column time series — so all but one of its columns are silently discarded. Probe regressions are therefore invisible to the test suite.
Mechanism
toolchain/mfc/packer/pack.py:139-144:
# Every line is <x> <y> <z> <value> (<y> and <z> are optional). So the
# number of dimensions is the number of doubles in the first line minus 1.
ndims = len(_extract_doubles(content.split("\n", 1)[0])) - 1
# We discard all <x> <y> <z> values and only keep the <value> ones.
doubles = _extract_doubles(content)[ndims :: ndims + 1]
lag_bubble files are already special-cased above this, which is the same underlying problem recognised once.
Effect on probe files
s_write_probe_files emits different column sets by configuration:
| Configuration |
Columns written |
Kept by the packer |
1D, general (m_data_output.fpp:1519) |
nondim_time, rho, vel(1), pres |
pres only |
| hypoelastic (line 1515) |
nondim_time, rho, vel(1), vel(2), pres, tau_e(1..3) |
tau_e(3) only |
| 3D (line 1524) |
nondim_time, rho, vel(1), vel(2), vel(3), pres, gamma, pi_inf, qv, c, accel |
accel only |
So in 3D the golden validates the acceleration magnitude and nothing else — density, velocity, pressure, and the sound speed are all dropped. Confirmed against the committed goldens: tests/5CAA4E68/golden.txt and tests/FBB296DA/golden.txt each store 50 values for a 50-row probe1_prim.dat, i.e. exactly one column.
Why it matters now
#1707 is a defect in the probe sound speed. It cannot be given a regression test through the normal golden path, because c is never the last column in any configuration. A case can be constructed that exercises the defective code, produce visibly wrong output, and still pass its golden.
More generally, any probe regression that does not happen to land in the last column is undetectable.
Suggested fix
Special-case probe files the way lag_bubble files already are, keeping every column (skipping any header). This will change the content of the three existing probe goldens — tests/5CAA4E68, tests/AE9A7D73, tests/FBB296DA — which will need regenerating. That regeneration is the point: it is coverage those cases should have had.
Worth checking whether other non-field .dat outputs under D/ are mis-parsed the same way.
Summary
The golden packer treats every
.datfile underD/as a spatial field of the form<x> [<y> <z>] <value>and keeps only the last column of each row. Probe output is not a spatial field — it is a multi-column time series — so all but one of its columns are silently discarded. Probe regressions are therefore invisible to the test suite.Mechanism
toolchain/mfc/packer/pack.py:139-144:lag_bubblefiles are already special-cased above this, which is the same underlying problem recognised once.Effect on probe files
s_write_probe_filesemits different column sets by configuration:m_data_output.fpp:1519)nondim_time, rho, vel(1), prespresonlynondim_time, rho, vel(1), vel(2), pres, tau_e(1..3)tau_e(3)onlynondim_time, rho, vel(1), vel(2), vel(3), pres, gamma, pi_inf, qv, c, accelaccelonlySo in 3D the golden validates the acceleration magnitude and nothing else — density, velocity, pressure, and the sound speed are all dropped. Confirmed against the committed goldens:
tests/5CAA4E68/golden.txtandtests/FBB296DA/golden.txteach store 50 values for a 50-rowprobe1_prim.dat, i.e. exactly one column.Why it matters now
#1707 is a defect in the probe sound speed. It cannot be given a regression test through the normal golden path, because
cis never the last column in any configuration. A case can be constructed that exercises the defective code, produce visibly wrong output, and still pass its golden.More generally, any probe regression that does not happen to land in the last column is undetectable.
Suggested fix
Special-case probe files the way
lag_bubblefiles already are, keeping every column (skipping any header). This will change the content of the three existing probe goldens —tests/5CAA4E68,tests/AE9A7D73,tests/FBB296DA— which will need regenerating. That regeneration is the point: it is coverage those cases should have had.Worth checking whether other non-field
.datoutputs underD/are mis-parsed the same way.