No description
- Shell 89.5%
- Python 10.5%
891a279b77
Target hardware is now expected to be AMD, and the validated GNU recipe
leaves the largest single win on the table: WRF v4.8.0's GNU x86_64 stanza
sets FCOPTIM = -O2 -ftree-vectorize -funroll-loops with no -march at all,
so gfortran targets baseline x86-64 (SSE2). The vectorizer is on but has
nothing wider than 128 bits to target.
wrf-gnu-openmpi-amd.def patches -march into FCOPTIM/CFLAGS_LOCAL after
./configure, with the Zen generation, optimization level, and optional
gcc-toolset exposed as build args. The dependency builds are left
byte-identical to the validated recipe so wrf.exe codegen is the only
variable when diffing output against the reference build.
Three guards, in the spirit of the existing pre-compile checks:
- gcc -march probe right after dnf install, so an arch the compiler
doesn't know (znver4 on Rocky 9's gcc 11.5) fails in a second
- objdump | grep vfmadd after compile, proving the flags reached the
binary rather than just configure.wrf
- /proc/cpuinfo ISA check in %runscript, so a mismatched image reports
a readable error instead of SIGILL-ing mid-run
Runtime side, no rebuild required: scripts/epyc_geometry.sh reads
/proc/cpuinfo and /sys on the target node and derives the Zen generation,
the ZENARCH to build with, and the rank x thread geometries to sweep.
Zen puts 8 cores per CCD behind a private L3, so threads-per-rank should
divide cores-per-CCD -- which retires the validated run's 4x5 layout.
scripts/run_wrf_epyc.sbatch is the matching launcher: SMT off, close/cores
binding, and it appends each run to sweep.csv so the scaling study
accumulates on its own.
Flag findings verified against the v4.8.0 tag of wrf-model/WRF. The image
itself is not built here -- this checkout has no WRF source tree.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|---|---|---|
| scripts | ||
| .gitignore | ||
| wrf-gnu-openmpi-amd.def | ||
| wrf-gnu-openmpi.def | ||
| WRF_BUILD_NOTES.md | ||