Autoconf: FMS 2020.x compatibility testing (diag_axis_mod, data_override_mod)

[marshallward]

The autoconf build was updated to verify that calls to diag_axis_init
support the domain_position argument. This was introduced in FMS
2019.01.02, so this acts as an implicit minimum FMS version test.

This test is done indirectly by confirming that the valid
domain_position values (NORTH, EAST, CENTER) are in diag_axis_mod.

[marshallward]

It was pointed out by @Hallberg-NOAA that MOM6 cannot build on various 2020.x releases, so some additional tests will be required to improve the FMS fidelity.

[marshallward]

I've pushed a change which detects if data_override_init can support axes in grid_spec.nc with two dimensions. It seems there was an assumption of four dimensions in these releases:

• 2020.01.x
• 2020.02.x
• 2020.03 without -Duse_mpp_io

It appears to work for these releases:

• 2019.01.02
• 2010.01.03
• 2020.03 with -Duse_mpp_io
• 2020.04

These results appear to be unrelated or unaffected by the choice of infra (FMS1/2).

Presumably newer FMS releases also have this fix.

This is probably not the only transitional issue, but it was the main issue which I detected in MOM6-examples and it should act as a proxy for any other 2020.x issues during the FMS1->2 I/O transition.

[marshallward]

I've added a --with-framework flag to select the backend framework. fms1 and fms2 arguments are currently supported.

[marshallward]

After talking with @adcroft, we agreed that the data_override_init test is better suited as a runtime FMS compatibility test handled in .testing, rather than a compile-time requirement.

[marshallward]

I've flipped back on this, and now think that the test should stay as it is.

It is not good to rely on AC_RUN_IFELSE tests for many reasons (too restrictive for testing, blocks out runs based on those versions, cross-compilation, etc) but we are also trying to navigate a very transitional period for the FMS API.

Keeping this test is less about compatibility and more of a declaration of support. We don't want to an anonymous user to build a version which cannot call data_override_init, and this test ensures that will not happen.

Similarly, we do not necessarily want to run .testing on those libraries, even if they do happen to pass at the moment. If we have proper code coverage, then they would not pass.

Finally, if someone did need to build using those libraries, they still can do it with native commands (or mkmf or whatever) so we are not preventing such usage.

So I would suggest leaving it in.

[marshallward]

The runtime data_override_init test has been dropped, and we've decided to avoid any FMS runtime tests at this time.

For now, we will only ensure that MOM6 can be built using the designated FMS library.

Any runtime requirements will be handled as part of a post-build tests, and will be reported as more of a warning rather than a rejection of the build.

Part of the rationale for this is that we don't want to prevent builds with older FMS libraries, since they may be required to reproduce older results.

We will probably come back to this issue later. We will be in a better position to address this when the code coverage has expanded, including any data_override functionality.