[bartgol]

Stacked on #124 (base is its branch; retarget to main once #124 merges). Gives the HIP image a CIME compiler, gnu-mphipcc, and adds the CI that builds E3SM with it.

What changes

• Compiler gnu-mphipcc: GNU Fortran and C, hipcc for C++, the name E3SM's craygnu-mphipcc uses on Frontier. The HIP image's CIME machine now lists gnu-mphipcc,gnu (the first is the default), and the CPU gnu stays available.
• Macro file ghci/env/cime/e3sm-container_gnu-mphipcc.cmake: E3SM has no generic gnu-mphipcc.cmake, so it starts from E3SM's gnu.cmake, included from E3SM's source tree through ${SRCROOT} (as Macros.cmake does for its post-process file). CIME copies only the macro files a case names into the case, and follows the includes of the ones it copies from E3SM, not of the ones from ~/.cime, so a plain ${CMAKE_CURRENT_LIST_DIR}/gnu.cmake include is not found. It then adds the Kokkos HIP options (modelled on Frontier's), for MI200 by default; E3SM_KOKKOS_HIP_ARCH overrides it, e.g. AMD_GFX942, and the hipcc target follows from it.
• Machine XML: MPICH_CXX=hipcc and BLA_VENDOR for the compiler, and 2 MPI tasks per node as for gnugpu.
• CI: e3sm-case gets the HIP image (x86_64), build only like CUDA's since hosted runners have no GPU. It builds the wcycl and aqp cases with gnu-mphipcc. The EAMxx standalone tests are skipped, as for CUDA.

Checked / not checked

• The first e3sm-case run failed at CMake configure because of that gnu.cmake include; fixed above. A local cmake run of the macro file with only it in ~/.cime and gnu.cmake/universal.cmake read from an E3SM checkout gives the expected SCXX, KOKKOS_OPTIONS, flags and arch override.
• Not checked yet: that E3SM compiles and links with it. That is what this PR's e3sm-case HIP jobs are for, so expect more iteration. They are not part of required-check, like the rest of e3sm-case.
• No GPU in CI, so nothing runs on a device.
• E3SM's own ghci machine entry is not touched; making E3SM's CI use the HIP image would be a separate PR in E3SM, with the same compiler name.

🤖 Generated with Claude Code

https://claude.ai/code/session_019UTqLci8P681gR1erTA488

[mahf708]

just one tiny note ... is there a reason we name them differently?

• ghci/env/cime/e3sm-container_gnu-mphipcc.cmake
• ghci/env/cime/e3sm-container_gnugpu.cmake

    <MAX_MPITASKS_PER_NODE compiler="gnugpu">2</MAX_MPITASKS_PER_NODE>
    <MAX_MPITASKS_PER_NODE compiler="gnu-mphipcc">2</MAX_MPITASKS_PER_NODE>

why don't we use gnumphipcc or gnu-gpu?

i never followed the compiler naming stuff in e3sm, so i may be missing something

[mahf708]

tho, tbc, I don't mind if you merge this without explaining the compiler stuff 😆 approved ✅ 🚀 🌕

[bartgol]

just one tiny note ... is there a reason we name them differently?

• ghci/env/cime/e3sm-container_gnu-mphipcc.cmake
• ghci/env/cime/e3sm-container_gnugpu.cmake

    <MAX_MPITASKS_PER_NODE compiler="gnugpu">2</MAX_MPITASKS_PER_NODE>
    <MAX_MPITASKS_PER_NODE compiler="gnu-mphipcc">2</MAX_MPITASKS_PER_NODE>

why don't we use gnumphipcc or gnu-gpu?

i never followed the compiler naming stuff in e3sm, so i may be missing something

I actually had a convo with Mr C on this. The main rationale is that this is the way E3SM named the compilers on frontier, which is the main machine where we use HIP. More broadly though, I do NOT like the name gnugpu, as it does not answer "what kind of GPU?"... But in general, we only have ONE type of GPU on each HPC machine, so gnugpu means gnu+"whatever GPU backend makes sense on this machine". Unfortunately, the ghci machine in E3SM is an "umbrella" machine: we technically have 3 diff machines (one per compiler) but I put everything in one machine to avoid code duplication.

Ideally, I would like the compiler name to be <hostcompiler>-<gpu-backend> (where the second part is omitted for host-only compilers). So for us: gnu, intel, gnu-cuda, gnu-hip (and, for intel gpus, intel-sycl). Alas, I did not pick the e3sm names. I think Claude's idea of sticking with the same pattern as used in E3SM is probably the best one.

[Copilot]

Note

Copilot was unable to run its full agentic suite in this review.

Copilot review overview

3 open issues

• The case patterns make gcc:yes:* take precedence over gcc:*:yes, so if both WITH_CUDA=yes… · New
• This appends to CMAKE_HIP_FLAGS without a leading space. If CMAKE_HIP_FLAGS is already… · New
• This single long KOKKOS_OPTIONS append is hard to read and easy to accidentally break during… · New

What changed in this PR

Adds HIP (ROCm) support to the E3SM container CIME configuration and CI matrix, introducing a dedicated gnu-mphipcc compiler setup and updating documentation/comments accordingly.

Changes:

• Add a new CIME compiler macro file for GNU + hipcc (gnu-mphipcc) and wire it into machine config.
• Extend Dockerfile compiler selection and GitHub Actions matrix to include HIP images/jobs.
• Update README/test script/workflow comments to reflect HIP behavior (build-only in CI).

File	Description
ghci/​tests/​e3sm-case.sh	Updates header comment to include HIP in build-only CI behavior.
ghci/​env/​cime/​e3sm-container_gnu-mphipcc.cmake	Adds new CIME compiler macro for HIP builds (GNU + hipcc, arch selection, flags, linking).
ghci/​env/​cime/​config_machines.xml	Registers gnu-mphipcc limits and sets MPICH_CXX=hipcc for that compiler.
ghci/​env/​Dockerfile	Selects gnu-mphipcc compiler variant when building HIP images.
ghci/​README.md	Documents HIP default compiler and HIP arch override behavior.
.github/​workflows/​e3sm-case.yaml	Adds HIP env to CI matrix; marks HIP as build-only like CUDA.

_{Review effort: Lite}