CRTM v3.1.1-build1 builds little-endian binaries

[DavidHuber-NOAA]

Describe the bug
The CRTM (v3.1.1-build1 in spack-stack 1.9.0-1) is building little-endian binaries when big-endian are required. (Reported by @wx20jjung).

To Reproduce
Attempt to read in the default CRTM-fix binaries (which are big-endian). The CRTM will fail with errors on endianness.

Expected behavior
The CRTM should be able to read the binary fix files without issue.

System:
Noticed on Orion, but possibly other systems.

[climbfuji]

Which version of CRTM?

[DavidHuber-NOAA]

3.1.1-build1. I'll update the description.

[DavidHuber-NOAA]

Related CRTM issue: JCSDA/CRTMv3#212.

[climbfuji]

@BenjaminTJohnson @stiggy87 Can you take a look, please?

@AlexanderRichert-NOAA FYI

[wx20jjung]

Dom, I also opened a crtm ticket (#212) about this issue. Jim

…

On Thu, Mar 13, 2025 at 1:32 PM Dom Heinzeller ***@***.***> wrote: @BenjaminTJohnson <https://github.com/BenjaminTJohnson> @stiggy87 <https://github.com/stiggy87> Can you take a look, please? @AlexanderRichert-NOAA <https://github.com/AlexanderRichert-NOAA> FYI — Reply to this email directly, view it on GitHub <#1561 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMPASA2POPBU3UQ6BDEQVQL2UG6JDAVCNFSM6AAAAABY6ZGTAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMRSGEYTKNRUGE> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: climbfuji]*climbfuji* left a comment (JCSDA/spack-stack#1561) <#1561 (comment)> @BenjaminTJohnson <https://github.com/BenjaminTJohnson> @stiggy87 <https://github.com/stiggy87> Can you take a look, please? @AlexanderRichert-NOAA <https://github.com/AlexanderRichert-NOAA> FYI — Reply to this email directly, view it on GitHub <#1561 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMPASA2POPBU3UQ6BDEQVQL2UG6JDAVCNFSM6AAAAABY6ZGTAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMRSGEYTKNRUGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[climbfuji]

If any changes are needed to spack-stack-1.9.1, they will be made in an addon/chained environment. We are not able to hold off the release of spack-stack-1.9.1 and reinstall the release everywhere, sorry.

[DavidHuber-NOAA]

Noted and thanks @climbfuji.

[DavidHuber-NOAA]

@climbfuji @AlexanderRichert-NOAA @stiggy87 @BenjaminTJohnson
It seems that the One-API compilers do not support big-endian and Intel has no plans to support this feature. Running icx -big-endian on a test code produces this message:

$ icx -big-endian test.c 
icx: command line warning #10430: Unsupported command line options encountered
These options as listed are not supported.
For more information, use '-qnextgen-diag'.
option list: 
	-big-endian

Running icx -qnextgen-diag produces a long list of Intel Classic options that Intel plans on supporting at some point and a long list of options 'being removed'. In the list of options being removed is -big-endian.

The CRTM is able to work with both binary and netCDF files. I'm not sure if the best option here is to move to little-endian binaries or netCDF. I'm not at all familiar with the inner workings of the CRTM, so I'm not sure if moving to little endian is an option. I also know that this would have repercussions on the GSI, UPP, and the GDASApp.

Though I don't believe @wx20jjung has tested it, I suspect that v2.4.1 will encounter the same problems when compiled with OneAPI compilers.

[climbfuji]

A major effort in the CRTMv3 development is the move away from these horrible binary files towards netCDF. I wouldn't spend any effort on big endian vs little endian if the netCDF implementation is fully supported and working.

@BenjaminTJohnson Can you comment on this, please?

[climbfuji]

That being said, aren't you reading and writing unformatted files with Fortran, not C/C++?

ifx@2025 does support big endian:

> ifx --help
...
-convert <keyword>
          specify the format of unformatted files containing numeric data
            keywords: big_endian, cray, ibm, little_endian, native, vaxd, vaxg

I just recently needed that for an NRL project.

[DavidHuber-NOAA]

@climbfuji Hmm, good point. I thought I had the answer there. And I see that the CRTM is mostly Fortran, so that -convert flag should work. Back to the drawing board. And a note of concurrence RE the netCDF files.

[BenjaminTJohnson]

@DavidHuber-NOAA @climbfuji I use the export F_UFMTENDIAN=big or little "trick" as needed to switch between endian types without the need for special compiler flags or recompiling.

That being said, currently working on getting everything all netcdf default in v3.2.0. We'll still support binary i/o, but won't carry those files in the tarball anymore. v3.2.0 Release is overdue, waiting on EMC feedback.