AMD AOCC compiler support for WPS?

Hi,
Thanks for sharing that configuration! I successfully compiled wps 4.5.1 with your suggested entries for configure.wps (I've attached the full configure.wps file here). I was able to get ungrib & metgrid to run.
However, I'm still seeing an odd scrambling effect, but only for fields read in from grib2 files. Below is the resulting skintemp field (read from a grib1 file) on the left as an example and the SST (read from a grib2 file and exhibiting the scrambling effect) on the right:

1777652567218.png1777652610900.png
As I described in my prior post, these same SST grib files are correctly processed with the SST field appearing normal when I use my previously compiled wps 4.5.1 built with intel. So it's not a problem with the file itself and it only seems to effect this one field (which is the only input that comes from a grib 2 file).
Could any compiler flags I'm using be causing this issue (which seems to be some sort of scrambling of the coordinates of the grid cells)?
Thanks for your help with compiling and I'd welcome your thoughts on this odd bug with reading grib2.
Megan
 

Attachments

William.Hatheway said:
will try and visualize a zen3 arch system
Click to expand...
I was able to sucessfully build WPS with AOCC compilers using this stanza in arch/configure.defaults on a zen3 emulated system.

Screenshot from 2026-05-14 13-31-22.png

@dudhia @mgduda @kwerner @Ming Chen @mmallard @ali_4906 @leuthold @Gabriel Cassol @islas

I have opened a few pull requests and bug reports for AOCC compilers to be added:

For anyone interested here they are:
github.com

Add AOCC flang/clang build configuration for WPS on AMD Linux x86_64 by HathewayWill · Pull Request #286 · wrf-model/WPS

TYPE: enhancement KEYWORDS: WPS, AOCC, flang, clang, AMD, x86_64, configure, dmpar, serial SOURCE: Will H ([affiliation]) DESCRIPTION OF CHANGES: Problem: WPS does not currently provide a configure...
github.com github.com
github.com

fix a vectorization option in AOCC stanza by weiwangncar · Pull Request #2335 · wrf-model/WRF

TYPE: bug fix KEYWORDS: AOCC, vectorization SOURCE: Will Hatheway DESCRIPTION OF CHANGES: Problem: The AOCC stanza in arch/configure.defaults contains a misspelled LLVM optimizer option. This PR pr...
github.com github.com
github.com

WRFPLUS & WRFDA 4DVAR V4.7.1 does not build cleanly with the AMD AOCC flang/clang dmpar configuration unless the AOCC architecture stanza is adjusted for WRFPLUS. · Issue #2338 · wrf-model/WRF

Describe the bug Two changes appear to be required for WRFPLUS with AOCC: OMPCPP = OMP = OMPCC = PROMOTION = -fdefault-real-8 WRFPLUS configures the build with RWORDSIZE = 8 and -DDOUBLE_PRECISION,...
github.com github.com
github.com

BUGFIX: AMD AOCC configure.wrf Build Hardcodes -march=znver3 · Issue #2337 · wrf-model/WRF

Issue type: Build configuration / portability Affected file: configure.wrf generated from the AMD AOCC architecture stanza Describe the bug The AMD AOCC configuration used to generate configure.wrf...
github.com github.com
github.com

Update configure.defaults by HathewayWill · Pull Request #14 · wrf-model/OBSGRID

#13 @kkeene44 @islas @mgduda @weiwangncar
github.com github.com
github.com

Add WRF-style executable checks to WPS compile script by HathewayWill · Pull Request #287 · wrf-model/WPS

Summary This PR updates the WPS compile script to perform WRF-style executable checks after compilation. The script now verifies that each requested target produced the expected .exe file and repor...
github.com github.com
 

Attachments

Last edited:
I tried this, and ungrib.exe compiled successfully using AOCC 5.2. However, when I use ungrib on GFS (GDAS) files for MPAS, I encounter several errors while generating the initial conditions with init_atmosphere.

Some of the error messages include the following:

1. Error during vertical grid interpolation using config_extrap_airtemp = 'lapse-rate':

ERROR: extrap_type == 2 not implemented for target_z >= zf(1,nz)
ERROR: *****************************************************************
ERROR: Error in interpolation of t(k,iCell) for k= 1, iCell= 15
CRITICAL ERROR: *****************************************************************

I was able to work around this issue by setting:
config_extrap_airtemp = 'linear'
However, this is not an acceptable solution for users who want to interpolate the vertical air temperature using the lapse-rate method.

2. Error during soil temperature level interpolation:

nSoilLevels = 4
nFGSoilLevels = 4
CRITICAL ERROR: Error in interpolation of st_fg to MPAS grid: num_st = 11056

To investigate this issue, I tried using different forecast timestamps and several GFS (GDAS) datasets, but none of these resolved the problem.

As a comparison, I recompiled WPS using gfortran and reran init_atmosphere with the same GFS (GDAS) input files. Surprisingly, the workflow completed successfully without any issues, and none of the errors described above were encountered.

This suggests that, although WPS compiles successfully with AOCC, the ungrib output generated by the AOCC build may differ from that produced by a gfortran build. The differences appear to be significant enough to produce incorrect values during the interpolation process. I suspect this because I examined the init_atmosphere source code where these error messages are generated and found that they are triggered when negative values are encountered. This raises the possibility that the AOCC-generated ungrib output contains invalid or unphysical values that are not present in the output generated by gfortran.

One of the key linker flags required to compile WPS successfully with AOCC is:

-Wl,--allow-multiple-definition

My understanding is that this linker flag suppresses multiple-definition linker errors, allowing the build to complete successfully. I wonder whether relying on this flag could be masking an underlying issue that ultimately affects the correctness of the generated ungrib output.
 
Last edited:
ep-98d said:
I tried this, and ungrib.exe compiled successfully using AOCC 5.2. However, when I use ungrib on GFS (GDAS) files for MPAS, I encounter several errors while generating the initial conditions with init_atmosphere.

Some of the error messages include the following:

1. Error during vertical grid interpolation using config_extrap_airtemp = 'lapse-rate':

ERROR: extrap_type == 2 not implemented for target_z >= zf(1,nz)
ERROR: *****************************************************************
ERROR: Error in interpolation of t(k,iCell) for k= 1, iCell= 15
CRITICAL ERROR: *****************************************************************

I was able to work around this issue by setting:
config_extrap_airtemp = 'linear'
However, this is not an acceptable solution for users who want to interpolate the vertical air temperature using the lapse-rate method.

2. Error during soil temperature level interpolation:

nSoilLevels = 4
nFGSoilLevels = 4
CRITICAL ERROR: Error in interpolation of st_fg to MPAS grid: num_st = 11056

To investigate this issue, I tried using different forecast timestamps and several GFS (GDAS) datasets, but none of these resolved the problem.

As a comparison, I recompiled WPS using gfortran and reran init_atmosphere with the same GFS (GDAS) input files. Surprisingly, the workflow completed successfully without any issues, and none of the errors described above were encountered.

This suggests that, although WPS compiles successfully with AOCC, the ungrib output generated by the AOCC build may differ from that produced by a gfortran build. The differences appear to be significant enough to produce incorrect values during the interpolation process. I suspect this because I examined the init_atmosphere source code where these error messages are generated and found that they are triggered when negative values are encountered. This raises the possibility that the AOCC-generated ungrib output contains invalid or unphysical values that are not present in the output generated by gfortran.

One of the key linker flags required to compile WPS successfully with AOCC is:

-Wl,--allow-multiple-definition

My understanding is that this linker flag suppresses multiple-definition linker errors, allowing the build to complete successfully. I wonder whether relying on this flag could be masking an underlying issue that ultimately affects the correctness of the generated ungrib output.
Click to expand...
I am currently dealing with health issues and cannot respond. My solution was for wrf not mpas configuration.

I will try to get to it in a few weeks or more. Hopefully one of the admins can help you. @islas
 
Regarding building WPS with AOCC, my suspicion appears to have been correct. There are a couple of major issues with the external libraries included with WPS.


The first issue comes from the fact that the gbytes subroutine exists in multiple locations:


src/ungrib/src/ngl/g2/gbytesc.f
src/ungrib/src/ngl/w3/gbytes.f


During the final stage of building ungrib.exe, make attempts to link both objects at the same time, which results in a duplicate symbol error. With gfortran, the linker appears to tolerate this issue and still produces correct results when generating intermediate files for MPAS or WRF. However, with AOCC, this behavior is not permitted. The linker flag:


-Wl,--allow-multiple-definition


suppresses this error and allows ungrib.exe to compile, but this can lead to incorrect results for MPAS and possibly WRF as well (as you can see from mmallard's SST problem shown above)


To resolve this issue, I excluded gbytes.o from the Makefile in:


src/ungrib/src/ngl/w3


so that only one gbytes implementation is linked into ungrib.exe during the build process. This is because, for GRIB2 processing, the gbytes subroutine from:


src/ungrib/src/ngl/g2


is used rather than the one from:


src/ungrib/src/ngl/w3


With this modification, I was able to successfully run MPAS init_atmosphere without encountering any of the error messages described above.


The second issue is related to the JasPer library. Some functions in the JasPer source code use an older C syntax that is no longer accepted by modern C standards. Specifically, some functions are defined without explicitly specifying that they take no arguments. For example:


jpc_dec_seg_t *jpc_seg_alloc()
{
}


Modern C standards require an explicit void declaration for functions that do not accept arguments:


jpc_dec_seg_t *jpc_seg_alloc(void)
{
}


This caused numerous compilation errors with AOCC. After adding void to these empty argument lists, the compilation completed successfully.
 
This is how i'm building jasper @ep-98d

Bash: 
    export Jasper_Version=1.900.1
    GCC_MAJOR="$(gcc -dumpfullversion | cut -d. -f1)"
    GCC_INSTALL_DIR="/usr/lib/gcc/x86_64-linux-gnu/${GCC_MAJOR}"
    export CC=clang
    export CXX=clang++
    export FC=flang
    export F77=flang
    export F90=flang

    export CFLAGS="-O3 -fPIC -Wno-implicit-function-declaration -Wno-incompatible-pointer-types"
    export CXXFLAGS="-O3 -fPIC $CXXFLAGS --gcc-install-dir=${GCC_INSTALL_DIR} -isystem /usr/include/c++/${GCC_MAJOR} -isystem /usr/include/x86_64-linux-gnu/c++/${GCC_MAJOR}"
    export FFLAGS="-O3 -fPIC"
    export FCFLAGS="-O3 -fPIC"
    cd "${WRF_FOLDER}"/Downloads
    env -u LD_LIBRARY_PATH tar -xzf jasper-$Jasper_Version.tar.gz
    cd jasper-$Jasper_Version/

    CC=$MPICC FC=$MPIFC F77=$MPIF77 F90=$MPIF90 CXX=$MPICXX CFLAGS=$CFLAGS FFLAGS=$FFLAGS FCFLAGS=$FCFLAGS ./configure --prefix=$DIR/grib2 2>&1 | tee configure.log

    make -j $CPU_QUARTER_EVEN 2>&1 | tee make.log
    make -j $CPU_QUARTER_EVEN install 2>&1 | tee make.install.log

    export JASPERLIB=$DIR/grib2/lib
    export JASPERINC=$DIR/grib2/include
    export JASPER_DIR=$DIR/grib2
    export Jasper_ROOT=$DIR/grib2/lib

    echo " "
 
You must log in or register to reply here.
Back
Top