Tiling parity harness: assert the tiled run is tiled, give fextrema its own cache entry, stop appending its log

[asalmgren]

Summary

Follow-up to #3972, which added add_test_tiling_parity and Tests/RunTilingParity.cmake. Three problems in that harness. None of them affect the PBL fix; all of them are about the tests staying honest.

The tiled run is not checked to be tiled

RunTilingParity.cmake carefully rejects a comparison between two copies of a constant field (VARYING_3D / VARYING_2D), but nothing rejects a comparison between two effectively untiled runs.

FabArrayBase::buildTileArray splits a direction into max(ncells/tilesize,1) tiles, so a box splits only once it is twice the tile size: with the 8-cell default a 16-cell box gives two tiles and a 15-cell box gives one. A later edit to Tests/test_files/ABL_MRF_Tiling/ABL_MRF_Tiling.i that narrows the boxes in y — a smaller amr.max_grid_size_y, a shorter domain — therefore leaves one tile per box, and all three tests keep passing while testing nothing.

This is not hypothetical. Running the deck with amr.max_grid_size_y=8 gives eight boxes of one tile each, and fcompare on the two plotfiles reports PLOTFILE AGREE with every norm exactly 0:

 theta            0    0
 pressure         0    0
 Kmv              0    0
 Khv              0    0
 Lturb            0    0
 PLOTFILE AGREE

count_xy_tiles() now reads the level-0 boxes out of Level_0/Cell_H, the way RunBoxParity.cmake's count_level0_boxes() does, and requires the tiled tile count to exceed the untiled one. The same narrowed deck is now refused:

RunTilingParity.cmake: fabarray.mfiter_tile_size=1024000 8 8 gives 8 tiles in x-y
over the level-0 BoxArray and the untiled run 8; the tiled run must have more, or
the comparison is between two untiled runs. Widen the boxes in y
(amr.max_grid_size_y) in the deck

Only x and y are counted. These schemes iterate under TileNoZ(), which pins the z tile size to the whole box, so counting z would let z-tiling alone satisfy the check after the y split that exposes the bug had quietly gone away.

fextrema had no path of its own

FEXTREMA_EXE was derived from FCOMPARE_EXE with string(REPLACE "amrex_fcompare" "amrex_fextrema" ...). FCOMPARE_EXE is a user-facing CACHE STRING, so configuring with a path that does not contain that literal — -DFCOMPARE_EXE=/usr/local/bin/fcompare, say — made the substitution a no-op. FEXTREMA_EXE then pointed at fcompare, which was run as fcompare -v Lturb untiled_plt00010, treated -v as a plotfile and aborted. All three tests failed with fextrema could not read Lturb from ..., which reads as a broken deck rather than a misconfigured tool path.

fextrema now gets its own cache entry beside fcompare, in both the internal and external AMReX branches and for both WIN32 and not, so there is no derivation left to no-op. It is reported in the test configuration summary alongside fcompare:

--    fcompare executable           = .../Tools/Plotfile/amrex_fcompare
--    fextrema executable           = .../Tools/Plotfile/amrex_fextrema

RunTilingParity.cmake also checks the path exists before running anything, so a wrong path fails immediately instead of after two simulations:

RunTilingParity.cmake: FEXTREMA=/usr/local/bin/amrex_fextrema does not exist; set
the FEXTREMA_EXE cache entry to the amrex_fextrema built alongside amrex_fcompare

An EXISTS check at configure time would not work: FCOMPARE_EXE points into ${PROJECT_BINARY_DIR}/Submodules/AMReX/Tools/Plotfile/, which does not exist yet when CMake runs, so it would fire on every fresh build.

The fextrema log was appended, never truncated

execute_process(OUTPUT_FILE ...) rewrites the run and fcompare logs, but the fextrema output was appended one field at a time. On a repeated run in the same build directory the ATTACHED_FILES_ON_FAIL artifact accumulated one block per invocation, mixing this run's ranges with earlier ones — and that is the one file a developer reads to decide whether a field really varied. It is truncated at the start of each run: 22 lines after one run of ABL_MRF_Tiling, still 22 after a second, where it used to be 44.

Testing

GNU 13.3, Release, ERF_ENABLE_MPI=ON, 2 ranks, on this branch.

• ABL_MRF_Tiling, ABL_YSUNew_Tiling, ABL_YSU_Tiling pass, and MRF now reports RunTilingParity: 4 boxes on level 0, 8 x-y tiles with fabarray.mfiter_tile_size=1024000 8 8.
• ABL_MOST_WOA_ZSplit_NoSub_BoxParity and CloudChamber_SatAdj_Parity pass, so the shared Tests/CTestList.cmake still works for the other parity harnesses.
• Full ctest -L regression: 108/108. No gold files change.
• count_xy_tiles() checked against a stored plotfile of 12 boxes of 16³: 24 tiles at tile size 8, and 12 at tile size 16 — reproducing the floor semantics where a box splits at 2× the tile size, not at 1×.

Not changed here

#3972's registration guard is if(ERF_ENABLE_MPI AND NOT WIN32), so a serial build registers none of these tests even though the bug is pure CPU MFIter tiling. No CI job loses coverage — Windows is the only serial regression job and it is excluded by NOT WIN32 anyway — so this is left alone rather than restructured to RunBoxParity.cmake's launcher-guard pattern.

ApplyPBLHSmoothing is fixed in #3978. None of these tests set erf.enable_pblh_smoothing=true, so that path still has no parity coverage; the fourth registration belongs with that PR.

🤖 Generated with Claude Code