Machines: rename oneapi to intel everywhere - #8652
Conversation
|
I see some odd changes in |
Because intel.cmake was defining as intel compilers the classic compilers. Since we want to use the name "intel" for the new (oneapi) compilers, this file must define the correct compilers names. The flags were relatively similar between oneapi-ifx.cmake and (the old) intel.cmake but, in the spirit of "intel means oneapi", i basically copied oneapi-ifx.cmake to intel.cmake (after moving the old intel.cmake to intel-classic.cmake). Unfortunately gh does not show that move, as |
eb5c49a to
95d9f6e
Compare
|
Why do you need to make changes to CICE builds? Maybe just explain what you need to do in the first place? What is not working for you now? |
95d9f6e to
8c30dd3
Compare
|
I am not sure what you mean with changing CICE builds. The key point in today's call seemed (to me, I may have musunderstood) that E3SM officially supported machines should use "intel" to mean "the new oneapi compilers series", and the old compilers should be referred to as "intel-classic". This PR addresses that by:
|
8c30dd3 to
e48e5dc
Compare
| set(SFC "ifort") | ||
|
|
||
| # Intel has to link fortran mains with fortran | ||
| if (MPILIB STREQUAL impi) |
There was a problem hiding this comment.
I added this bit, since it seems silly that the base compiler cmake file dictates the MPI compilers without checking what MPI lib to use. The original oneapi-ifx did not do this distinction.
The change should not be consequential, since all the machines that had oneapi-ifx are using mpich, not impi.
| <env name="ZFP_ROOT">$SHELL{if [ -z "$ZFP_ROOT" ]; then echo /lcrc/soft/climate/zfp/1.0.1/gcc-11.2.0; else echo "$ZFP_ROOT"; fi}</env> | ||
| </environment_variables> | ||
| <environment_variables compiler="oneapi-ifx" mpilib="openmpi"> | ||
| <environment_variables compiler="intel" mpilib="openmpi"> |
There was a problem hiding this comment.
This seems like its left over from when we changed oneapi to intel on chrysalis. Just delete this and the MOAB_ROOT setting. Right @vijaysm ?
There was a problem hiding this comment.
Yeah, I can reinstall to "intel" folder if we want to make that the oneapi default now, and use "intel-classic" for the older one? Do we need the classic version?
There was a problem hiding this comment.
I also see line 2854 repeats this. Need to check this more.
There was a problem hiding this comment.
will moving the folder work? A symlink also works probably.
| </resource_limits> | ||
| </machine> | ||
|
|
||
| <machine MACH="jlse"> |
There was a problem hiding this comment.
yes, it's an experimental cluster
There was a problem hiding this comment.
I know but are we interested in running on it?
There was a problem hiding this comment.
We may consider to remove the JLSE. THe intel stack is outdated and hardware is a copy of what we have on sunspot and aurora. It wont be updated as frequently as other places. I am not sure from reading the config-machines, which GPU hardware are we targetting in JLSE. (because it has machines from all 3 major vendors)
There was a problem hiding this comment.
That was the first place Intel hardware landed I think which is why we once supported it.
| </environment_variables> | ||
| </machine> | ||
|
|
||
| <machine MACH="sunspot"> |
There was a problem hiding this comment.
@amametjanov We might have to redo the sunspot setup, paths, modules are not valid. The only filesystem mounted is tegu so the paths with gila is not valid. So as the modules. Lets work this offline ?
/tegu/E3SMinput/soft
and the modules:
Currently Loaded Modules:
1) gcc/14.3.0 6) cray-libpals/1.8.0
2) oneapi/release/2026.1.0 7) cmake/3.31.11
3) mpich/prd/5.0.0.aurora_test.87e2045 8) gcc-runtime/14.3.0-pzdp6un (H)
4) libfabric/2.3.1 9) intel-oneapi-runtime/2026.1.0-sesoxjw (H)
5) cray-pals/1.8.0 10) kokkos/5.1.1-sycl
Where:
H: Hidden Module
|
The only machines reporting to cdash this should disrupt is aurora and ghci-snl-oneapi. |
|
This should be tested on chrysalis, pm-cpu and pm-gpu before merging to next. |
There was a problem hiding this comment.
Pull request overview
Standardizes Intel oneAPI compiler names and consolidates shared compiler
configuration.
Changes:
- Renames
oneapi-ifx/oneapi-ifxgputointel/intelgpu. - Introduces
intel-classicfor the legacy Intel toolchain. - Deduplicates GNU and Intel GPU macro configuration.
Reviewed changes
Copilot reviewed 10 out of 12 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
cime_config/machines/config_machines.xml |
Renames compiler selections. |
cime_config/machines/cmake_macros/sunspot_intelgpu.cmake |
Enables SYCL on Sunspot. |
cime_config/machines/cmake_macros/oneapi-ifxgpu.cmake |
Removes the old GPU macro. |
cime_config/machines/cmake_macros/oneapi-ifx.cmake |
Removes the old CPU macro. |
cime_config/machines/cmake_macros/intelgpu.cmake |
Reuses Intel configuration. |
cime_config/machines/cmake_macros/intel.cmake |
Configures the oneAPI toolchain. |
cime_config/machines/cmake_macros/intel-classic.cmake |
Preserves classic Intel settings. |
cime_config/machines/cmake_macros/gnugpu.cmake |
Reuses GNU configuration. |
cime_config/machines/cmake_macros/gnu.cmake |
Corrects flag spacing and comments. |
cime_config/machines/cmake_macros/dane_intel.cmake |
Adds Dane library RPATHs. |
cime_config/machines/cmake_macros/aurora_intelgpu.cmake |
Enables SYCL on Aurora. |
cime_config/machines/cmake_macros/aurora_intel.cmake |
Adds Aurora CPU linker settings. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| if (MPILIB STREQUAL impi) | ||
| set(MPICC "mpiicc") | ||
| set(MPICXX "mpiicpc") | ||
| set(MPIFC "mpiifort") |
There was a problem hiding this comment.
Copilot is right here. Since the old oneapi-ifx.cmake script set only the mpicxx/mpicc/mpifort wrappers (without checking the MPILIB name), I'm rolling this back to match that.
| <NODENAME_REGEX>jlse.*</NODENAME_REGEX> | ||
| <OS>LINUX</OS> | ||
| <COMPILERS>oneapi-ifx,oneapi-ifxgpu,gnu</COMPILERS> | ||
| <COMPILERS>intel,intelgpu,gnu</COMPILERS> |
There was a problem hiding this comment.
@abagusetty I'm going to ignore this, since from what you said we may remove this machine altogether.
| <NODENAME_REGEX>jlse.*</NODENAME_REGEX> | ||
| <OS>LINUX</OS> | ||
| <COMPILERS>oneapi-ifx,oneapi-ifxgpu,gnu</COMPILERS> | ||
| <COMPILERS>intel,intelgpu,gnu</COMPILERS> |
e48e5dc to
b30051e
Compare
|
@rljacob I will test this next week on pm and chrys next week. @abagusetty As you said, the current state of the |
b30051e to
54a9ac0
Compare
54a9ac0 to
c662a11
Compare
The oneapi-ifx compiler becomes intel, while oneapi-ifxgpu becomes intelgpu. If conflicting, intel becomes intel-classic.
A few comments:
gnugpu.cmakewas virtually the same asgnu.cmake, and simillarly forintelgpu.cmakevsintel.cmake. So I made the gpu ones simply include the non-gpu ones, possibly adding a couple of new settings. This saves code duplication.$machine_intel.cmakemacro file, where they set the compiler names to the old intel compilers ($mach_$compiler.cmakeis parsed AFTER$compiler.cmake).@rljacob This will break nightlies on all machines that use oneapi-ifx, as that compiler no longer exists. I will take care of changing the testing scripts repo once this is merged.
Side q: should this PR be marked BFB or non-BFB? It will break baselines tests (and scripts), but it technically does not change answers.