Build issue with MAPL 2.26.0 on AWS

[lizziel]

I have been successfully using MAPL 2.26.0 in GCHP locally but am running into a build error when using the GEOS-Chem benchmark pipeline on AWS. I am getting build errors in the new ExtData section of the code, such as this:

/tmp/tmp.1eQRnmBr8I/GCHP/src/MAPL/gridcomps/ExtData2G/ExtDataGridCompNG.F90(1134):
error #6632: Keyword arguments are invalid without an explicit interface.   [RC]

The line in question for this example is a simple call to ESMF: call ESMF_InfoGetFromHost(grid,infoh,rc=status)

The same error is occurring for calls to ESMF_InfoIsPresent. As far as I can see the interface for this in ESMF has not changed recently so I am confused about what the problem is. Have you seen this before?

[yantosca]

@lizziel and I have been looking at the ESMF_EsmfInfoSync.F90 module. One thing I noticed is this interface:

https://github.com/esmf-org/esmf/blob/c2f82972f6cf47af0b83b998fc07962722677e65/src/Superstructure/InfoAPI/interface/ESMF_InfoSync.F90#L82-L95

The error seems to be that whatever is getting passed as the host argument to

call ESMF_InfoGetFromHost(grid,infoh,rc=status)

is an object of a type that does not have a specific function to handle it.. We are looking into the ESMF version used on our AWS environment. It may be that we need to update it.

Any other thoughts would be appreciated.

[mathomp4]

First, I'll ping @bena-nasa since this is his code. It is odd that it's the one place with ESMF_Info in MAPL 2...

That said, this code has been pretty stable for a while (since MAPL 2.23 or so) and ESMF_Info has been in ESMF for a long time now. I'd be interested to what version of ESMF you are running.

That is definitely an allowed use of ESMF_InfoGetFromHost otherwise our MAPL3 would never compile!

[mathomp4]

Ah. MAPL 2.23.0 coincided with a move to Baselibs 7.5.0. That means ESMF 8.3.0.

I think ESMF_Info came into ESMF around 8.1.0 (paging @theurich), but I'd probably go with ESMF 8.3.0 (at least) if possible. 8.4.0 should work too and would future proof you 😄

[theurich]

@mathomp4 is correct, ESMF_Info came with ESMF 8.1.0 (release date 03/29/21).

[lizziel]

Thanks all. I suspect the version is indeed the culprit then. I test with 8.1 here at Harvard but just found that spack downloaded 8.0.1 for use on AWS. This might be a pain, but would it be possible to include minimum ESMF version in the MAPL release notes? This is something we will need to notify GCHP users about when releasing GCHP with new versions of MAPL.

[tclune]

@lizziel Yes - we should at least put something into the CHANGELOG when the version of external dependencies change. For most of these we can further enforce with cmake find_package(...) but since ESMF is not CMake'd we'll have to rely on documentation.

Note that we do document which version of ESMF in our baselibs, and I think MAPL documents which version of baselibs. None of this is particularly convenient for GCMP though, since it does not use baselibs. Spack is coming.

[theurich]

We recommend code like this

find_package(ESMF 8.3.0 MODULE REQUIRED)

in CMake based projects that use ESMF. See e.g. the ESMF_HelloWorld_CMake as an example.

[tclune]

Thanks @theurich . I thought that might be there now, but could not immediately recall.

Apparently we are not using that and should be ... (@mathomp4 )

[lizziel]

Thanks, that will be helpful. The inclusion of Baselibs ESMF version in the release notes has limited use since you use such a recent version. We don't want to require users to get the latest ESMF just to be safe if an older one is sufficient.

For what it's worth I also ran into this issue when I was testing with MAPL 2.28 since that version requires at least ESMF 8.2, but I didn't figure that out until I built with 8.1.

Our next MAPL update in GCHP will be to MAPL3 next year so no need to worry about including minimum ESMF version for the rest of the MAPL 2 series.

[mathomp4]

Yeah, we should move to that for our "non-Baselibs" builds of MAPL (aka spack). I guess we will "double" enforce it, both by spack package and by CMake.

And I'll make a PR now to do it. Better safe than sorry. We have some protections around netCDF (for example, to use Quantize you need 4.9.0/4.6.0, but if you don't have it, code just will die with a message), but we don't generally code around ESMF changes...because we usually are driving those changes!

@theurich One question. Sometimes we need things in betas like v8.5.0b13 or something. I'm not sure find_package() would like those tags, right?

[theurich]

@mathomp4, betas work fine with the FindESMF.cmake that is distributed with ESMF (and also in the HelloWorld test). E.g. you get the following with a beta (and here even further locally modified from one of my local sandboxes):

-- Detected ESMF Beta snapshot: v8.5.0b08-15-gd376e4ed43
-- Found ESMF: /home/gerhard/WorkESMF/ESMF.check/lib/libg/Linux.gfortran.64.mpich.default/libesmf.so (found suitable version "8.5.0", minimum required is "8.3.0") 

[tclune]

I think he means that we can't use find_package() to force the beta to be required. Rather the baseline will meet this test.

In theory we should not release MAPL until ESMF has a formal release. This might mean we ask for small patch releases ahead of schedule?

[mathomp4]

@tclune I suppose the fact that it found it as "8.5.0" is not bad. We can specify in the release notes the beta version needed if we get to the point we need a release of MAPL with ESMF 8.5

[lizziel]

Building a new container on AWS with a newer ESMF works. Thanks all!