Add support for optional MKL and support for aarch64

[mathomp4]

This PR adds support for optional MKL as well as preliminary support for aarch64 (Graviton2) processors with GNU

Should be taken in concert with:

GEOS-ESM/NCEP_Shared#8
GEOS-ESM/GEOSgcm_GridComp#321

ETA: Turns out thanks to CMake knowledge of @tclune this is no longer true! Since each component specifies what they need, they are now independent!

[mathomp4]

Pinging @lizziel and @LiamBindle.

I wanted to bring this to your attention. I've been building/running GEOS on an Arm64 machine at AWS and as such, I've had to make some branches to avoid an MKL dependency in GEOS (in RRTMGP). Now, you probably don't care much about that, but in order to get other bits of GEOS to build, I found that we had a semi-undocumented LAPACK dependency. Thus, this PR will do more than find_package(MKL) but also find_package(LAPACK) and find_package(BLAS). I want to make sure you know this and it doesn't break anything on your end. It's pretty passive, but...

Also, it adds a bit of change the GNU.cmake where I can't exactly use -march=westmere on an Arm processor. :)

[mathomp4]

Also, I'm pinging you because this set of PRs might go in soon.

[LiamBindle]

@mathomp4 Thanks for the heads up! Just to make sure I understand this correctly, this doesn't introduce MKL/LAPACK/BLAS as a new dependency in MAPL right? It's just the CMakeLists will include find_package() calls to find them since GEOS needs it?

[mathomp4]

@LiamBindle MAPL doesn't care at all. But, technically, MKL has always been a required dependency of using ESMA_cmake (or include(esma)). Now it wouldn't be (though you'd lose functionality of RRTMGP), and makes BLAS and LAPACK as required.

[mathomp4]

@LiamBindle If need be, I could code in an option that would allow for skipping this altogether? Something like:

option(USE_BLASLAPACK "disable BLAS and LAPACK detection" ON)

if you really don't want any BLAS or LAPACK requirement? Or do you not even do include(esma)?

[LiamBindle]

@mathomp4 Sounds good, this shouldn't cause a problem on our end. We're using #57 which does something similar to disable find_package() calls that we don't actually need. In the near future I'm planning to revise our integration of the GEOS-ESM build system into GCHPctm in a way that's less intrusive than #57, with the compiler option ordering in mind, and because it seems like there have been lots of good updates in the last few months!

Thanks again for the heads up!

[tclune]

I wonder if the right thing to do in this regard is the following:

• No find_package() in the top esma.cmake except maybe MPI?
• Layers that have dependencies issue find_package() as appropriate.

It does not hurt to repeat these and it will make the dependencies more correct under random configurations. We probably cannot fix this overnight - or would not want to take such a risk. But over time we should migrate these.

[LiamBindle]

@tclune I love that idea. Working towards that would help on our end since it would decouple MAPL's build from GEOS.

[mathomp4]

I wonder if the right thing to do in this regard is the following:

• No find_package() in the top esma.cmake except maybe MPI?
• Layers that have dependencies issue find_package() as appropriate.

It does not hurt to repeat these and it will make the dependencies more correct under random configurations. We probably cannot fix this overnight - or would not want to take such a risk. But over time we should migrate these.

Yes, indeed. And doing that would allow us to better do PUBLIC/PRIVATE as well. For example, the NCEP_Shared PR is a PUBLIC which...ugh. But, if we make everything PRIVATE that might be optional (like MKL/BLAS/LAPACK) then we could help isolate these things and say, okay, NCEP_sp should find_package(LAPACK REQUIRED) and maybe RRTMG would find_package(MKL).

(Of course, things like MPI are just "required" at all levels and goes up to the top.)

[mathomp4]

Another edit is incoming from/inspired by Dan Kokron. Technically, esma.cmake shouldn't have REQUIRED on find_package(BLAS) and find_package(LAPACK). Why? Well, take GEOSfvdycore. It doesn't need MKL, BLAS, or LAPACK. But this branch makes it required.

Now that NCEP_sp is the one requiring LAPACK, that should cause the fault in CMake, not the esma.cmake step. Testing now.