Spackify JEDI components for NEPTUNE-JEDI

[climbfuji]

Summary

Much credit and thanks to @rhoneyager-tomorrow for the original PR to JCSDA/spack (now stale): JCSDA/spack#395.

This PR updates the JEDI packages from PR JCSDA/spack#395 that are relevant for NEPTUNE-JEDI (aka FALCON project) and adds them to our custom repo under repos/spack_stack. Building these components in spack-stack and providing them as modules allows us to reduce the NEPTUNE-JEDI build to a small number of repositories that are controlled and developed by NRL only, and - very important - allows us to implement a pure CMake build at the top level (neptune-bundle/neptune-ecosystem) without having to deal with ecbuild. A small change is made to the crtm package (in repos/builtin) to enable basic testing during spack install.

Notes/Limitations

1. The hashes added here are the exact versions needed by NEPTUNE-JEDI (aka FALCON), with additional bug fixes added on top of it in form of patches applied by Spack. In FALCON, these were kept in branches created from the commits used here. The Spack solution is cleaner, since it avoids maintaining branches. Most of these patches are already included in newer versions of the JEDI code.
2. I made sure that all ctests that are enabled pass with GCC (tested gcc@13) and Intel oneAPI (tested oneapi@2025.3.0). I made sure that the tests that are disabled are not related to the Spack package, but to the code itself or other issues outside of the scope of this PR. To run these tests, use spack install --test=root ioda, for example.
3. FALCON needs exactly these hashes in spack-stack-2.1.0 to transition from building JEDI components in neptune-bundle to loading them as modules. It is understood between JCSDA and NRL that these new Spack packages will not receive any additional support (i.e. beyond what JCSDA supports already) and that we will make an effort to update the JEDI code in the bundle to newer, official tags of the JEDI repositories.
4. We cannot test the JEDI packages in CI yet, because the ropp-ufo code is coming from the NRL Enterprise GitHub because of the unresolved issue https://github.com/JCSDA-internal/ropp-ufo/issues/1.

Testing

• Step 1. Build these components with spack-stack as part of the neptune-dev template using gcc@13 on @climbfuji's development system, and on DOD HPCMP Nautilus (gcc@13.3.1, intel-oneapi-compilers@2025.3.0).
• Step 2. Build neptune-bundle on these systems with these spack-stack modules
• Step 3. Initial testing with neptune-bundle - completed, but more work is necessary in the bundle (the outcome suggests that this spack-stack PR is good to go for version 2.1.0)
• Step 4. Merge this PR

Applications affected

NEPTUNE-JEDI

Systems affected

None directly

Dependencies

• Waiting on CRTM: add version 3.1.3 and logic to run minimal ctests spack-packages#39

Issue(s) addressed

This PR replaces a large part of JCSDA/spack#395.

Testing

• CI: Note whether the automatic tests (GitHub actions tests that run automatically for every commit) pass or not
  • GitHub actions CI tests pass
  • GitHub actions CI tests do not pass (provide explanation)
  • GitHub actions CI tests skipped (provide explanation if necessary)
• New tests added: List and describe any new tests added to GitHub actions
  • ...
• Additional testing: Add information on any additional tests conducted
  • ...

Checklist

• This PR addresses one issue/problem/enhancement or has a very good reason for not doing so.
• These changes have been tested on some of the affected systems and applications.
• All dependency PRs/issues have been resolved and this PR can be merged.
• All necessary updates to the documentation (spack-stack wiki) will be made when this PR is merged

[rhoneyager-tomorrow]

@climbfuji, thank you for carrying this through.

The dates encapsulated in the package version numbers are perhaps a bit confusing. For example, ioda version 2.9.0.20260120 points to commit 6e76616001067384f7d0ca4341ad78e81527af8b, which was made back in August 2025. I only mention this because yesterday the core repositories all received new tags, so there is now a ioda version 2.11.0, released 20260121, that is based on release branches cut back in November. Besides that, I'd love to push this into our own testing.

[climbfuji]

@climbfuji, thank you for carrying this through.

The dates encapsulated in the package version numbers are perhaps a bit confusing. For example, ioda version 2.9.0.20260120 points to commit 6e76616001067384f7d0ca4341ad78e81527af8b, which was made back in August 2025. I only mention this because yesterday the core repositories all received new tags, so there is now a ioda version 2.11.0, released 20260121, that is based on release branches cut back in November. Besides that, I'd love to push this into our own testing.

Agreed, and still being worked on. I need those for now as these are the hashes that neptune-bundle points to as of 2026/01/20. Likely won't get merged as is. We also discussed yesterday at the spack-stack meeting the desire to point to official tags of JEDI whenever possible. If we can't do this right away with neptune-bundle, then maybe using the date that the commit was made is a better idea.

[climbfuji]

Suggested change

	- ~mkl
	- ~mkl
	-

[climbfuji]

this will be reverted anyway