GEOS-ESM / MAPL

MAPL is a foundation layer of the GEOS architecture, whose original purpose is to supplement the Earth System Modeling Framework (ESMF)
https://geos-esm.github.io/MAPL/
Apache License 2.0
27 stars 18 forks source link

cmake installation instructions #2579

Open VictorEijkhout opened 7 months ago

VictorEijkhout commented 7 months ago

could someone point me to installation instructions? right now I'm running the default cmake installation, and then installating other packages as they come up. there has to be a better way, not?

VictorEijkhout commented 7 months ago

Ok, I'm getting pretty far, up to

  Unknown CMake command "ecbuild_declare_project".

So I installed ecbuild and used ecbuild instead of cmake in the cmake call, but the error remains.

What am I missing?

VictorEijkhout commented 7 months ago

FWIW the cmake command translates to

cmake -DCMAKE_MODULE_PATH=/work2/00434/eijkhout/ecbuild/installation-ecbuild-3.8.2-stampede3-intel24/share/ecbuild/cmake -D CMAKE_INSTALL_PREFIX=/work2/00434/eijkhout/mapl/installation-mapl-2.43.2-stampede3-intel24-impi -D CMAKE_VERBOSE_MAKEFILE=ON -D BUILD_SHARED_LIBS=ON /work2/00434/eijkhout/mapl/mapl-2.43.2/

and

[staff mapl:280] ls /work2/00434/eijkhout/ecbuild/installation-ecbuild-3.8.2-stampede3-intel24/share/ecbuild/cmake/ecbuild_declare*
/work2/00434/eijkhout/ecbuild/installation-ecbuild-3.8.2-stampede3-intel24/share/ecbuild/cmake/ecbuild_declare_project.cmake

so the macro seems to be there.

mathomp4 commented 7 months ago

@VictorEijkhout This probably falls on me. Most MAPL installs are done via GEOSgcm or our other GEOS-ESM fixtures, so installation instructions are a bit...lacking. Mea culpa. I'll work on an INSTALL.md file.

I'll list some words below, but beyond that, might I ask: why do you need/want MAPL? We know most projects using it and I'm not cognizant of anyone at TACC using it...so I'm curious! :)

But here we go.

Dependent libraries

You can see from the release notes of each release (e.g. https://github.com/GEOS-ESM/MAPL/releases/tag/v2.43.2), the dependencies needed for that release: netCDF-Fortran, ESMF, and the GFE libraries. I now realize I should also put MPI in there as well.

Getting MAPL

Obtaining MAPL from git clone

This is a bit involved as you'll need to also use mepo which is how we handle the subrepos within MAPL. mepo reads the components.yaml file and then downloads subrepos inside of MAPL. (We use it instead of Git submodules or ExternalProject/FetchContent for reasons that would be beyond this discussion, though the latter might be possible...)

mepo is pretty simple you just clone it and when you do there is an executable mepo that just needs Python3 and PyYAML. Then you can run mepo clone in your MAPL clone and you'll get three subrepos:

Obtaining MAPL from a complete release tarfile

On our releases page, you'll see each release has an asset titled like MAPL-v2.43.2.COMPLETE.tar.xz. This "complete" tarfile has had the mepo step above already applied so it is "complete" in that sense.

Building MAPL

At this point, if you have all the libraries and everything, the build process should be pretty standard:

cmake -B build-dir -S . --install-prefix install-dir -DUSE_F2PY=OFF < -DCMAKE_Fortran_COMPILER=XXX >
cmake --build build-dir --target install -j 10

If you have FC set in the environment, then no need for CMAKE_Fortran_COMPILER. The USE_F2PY=OFF is just to save your sanity. Almost no-one needs our f2py code, and f2py + CMake is a nightmare of challenges.

Spack

Perhaps a simpler path to MAPL is using spack. All the idiosyncracies of MAPL's build are "baked" into the package.py in spack and if you need MAPL-as-library, that could be an easier way to go. spack install mapl is pretty simple 😄

VictorEijkhout commented 7 months ago

Thanks for the writing that up. Maybe I was doing things the hard way.

  1. We got a ticket from a user who wants MPAS & MAPL on our new Stampede3 machine
  2. Which has only intel24 & gcc13, both of which are not supported by spack.
  3. Since I'm pretty good at installing packages I thought I'd see if I could do it without spack

so I've installed gftl, gftl-shared, yafyaml none of which were terribly hard.

And I'm stuck on ecbuild. Do you understand why it's not picking up the macros?

I could try backtracking and going the mepo route, but having come this far I'm wondering what the ecbuild problem is.

mathomp4 commented 7 months ago

Ack. Well, GCC 13 and MAPL is currently a no-go. And we only really work with Intel Fortran Classic ifort 2021.6.0 (maaaybe 2021.10.0), GCC 12, and NAG 7.1.

We don't yet support GCC 13 or ifx.

As for the ecbuild, in your clone do you have:

ESMA_cmake/ecbuild

as a directory in your base directory? If not, that means mepo was not run.

VictorEijkhout commented 7 months ago

See above, I have ecbuild in my path, I invoke it, the .cmake files are all there, but somehow not used.

VictorEijkhout commented 7 months ago

Btw, Intel 24 includes ifort for legacy reasons. If I can get ecbuild to work I may try that.

VictorEijkhout commented 7 months ago

Also for my own amusement: what is the problem with gcc13? I would think compilers are largely backwards compatible.

mathomp4 commented 7 months ago

Well, huh. I didn't see that. You are right. I am a bit confused now.

It's possible MAPL's cmake isn't good enough to see an external ecbuild? I mean this code:

https://github.com/GEOS-ESM/MAPL/blob/70d50bc687f3307ea1b82fa175c1b2dd1103f04b/CMakeLists.txt#L18-L32

should say "Hey we found ESMA_cmake, we'll use it" and that should bring in the internal ecbuild.

mathomp4 commented 7 months ago

In re GCC 13, I just tried it yesterday afternoon and...it worked? At least on macOS. So it's time now to build-and-test everywhere.

I swear it didn't work before...

mathomp4 commented 6 months ago

Okay, so I did some tests and while MAPL might have issues with GCC 13, it looks like GFE has some first:

https://github.com/Goddard-Fortran-Ecosystem/GFE/issues/29

and if GFE isn't happy, then we can't be sure of our unit tests here. My guess is if @tclune ever has a free moment or two, he might find whatever is causing the GFE issues and then MAPL might be okay (most likely because any GCC 12 workaround we have probably are needed for 13!)