I missed the parallelio flags:

depends_on("parallelio fflags='-qno-opt-dynamic-align -convert big_endian -assume byterecl -ftz -traceback -assume realloc_lhs -fp-model source' cflags='-qno-opt-dynamic-align -fp-model precise -std=gnu99'", when="%intel")

about half these flags are not in the oneapi programme guide

Are you or @manodeep familiar with their replacements ? Otherwise I will go digging :-)

@anton-seaice Flags that are not valid in oneAPI will be silently ignored - so, while not best practice, no harm done. There are two things I can see:

• The value of fp-model is different between fflags and cflags - should be set to precise for both
• the oneAPI compiler id for is oneapi under spack - might need to change that value.

I took. a quick look - the unsupported fortran flags seem to be: -convert big_endian -assume byterecl -assume realloc_lhs. The alphabetical list of supported compiler options in oneAPI 2025 is here: https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2025-0/alphabetical-option-list.html

The -assume realloc_lhs option is no longer needed - source

Thanks @manodeep

-convert big_endian is kind of strange. It sets the endianess for unformatted IO fortran IO. It looks like its only related to some GPTL timing stuff in the parallelio library. Maybe its ok to turn that off? There doesn't seem to be a oneapi alternative, but there is a Runtime Environment variable of FORT_CONVERSION = big_endian which might do the same thing.
-assume byterecl seems to be similar - it sets the block size for unformatted IO to interpret recl sizes as bytes. Again - the places in the code using unformatted IO seem to only be in tests, so I think its ok to change this.

They seem to go back to this commit: COSIMA/spack-config@3a1aca7

Any thoughts @micaeljtoliveira ?

@anton-seaice All those flags come from the corresponding CESM builds and, IIRC, I was not able to get a working model that gave bit-wise identical results to the equivalent CESM model without them.

SInce the flags are not supported by the compiler directly, and were originally put in place for bitwise-identical outputs - would a reasonable strategy be to first try without the flags and see whether that breaks bitwise-identical outputs?

(My bias: I am not a fan of environment variables that might break default user expectations)

Yeah - ill give it at a go. We broke this in a different but as yet undiscovered way recently, so it might take a while !