cmake build working on cheyenne for mksurfdata_esmf

[jedwards4b]

Description of changes

This improves the cmake build by building the executable with cmake instead of just the library.
build steps are:

Currently Loaded Modules:

1. ncarenv/1.3
2. intel/19.1.1
3. ncarcompilers/0.5.0
4. mpt/2.25
5. esmf-8.3.0b13-ncdfio-mpt-O
6. netcdf-mpi/4.8.1
7. pnetcdf/1.12.2
8. pio/2.5.7
9. cmake/3.18.2

(or use ../../../cime/tools/configure --macros-format CMake --machine cheyenne)

mkdir bld
cd bld
CC=mpicc FC=mpif90 cmake ../src
make

Specific notes

Contributors other than yourself, if any: @slevisconsulting @ekluzek

CTSM Issues Fixed (include github issue #):

This handles most of what's needed in #645

Are answers expected to change (and if so in what way)? No

Any User Interface Changes (namelist or namelist defaults changes)? Makefile build is different

Testing performed, if any: ran build on both cheyenne and izumi

[mvertens]

@jedwards4b - the mksurfdata_esmf/README needs to be updated as part of this PR.

[mvertens]

@jedwards4b - I am not able to load the ESMF module esmf-8.3.0b13-ncdfio-mpt-O. It tells me this is not available on cheyenne. Can you please specify how to do this - and also what needs to be done on izumi.

[mvertens]

@jedwards4b - you need to use the following:
module use /glade/p/cesmdata/cseg/PROGS/modulefiles/esmfpkgs/intel/19.1.1/
module load esmf-8.3.0b13-ncdfio-mpt-O

[mvertens]

@jedwards4b - pushed an updated README back to your branch and verified that the build did in fact work on cheyenne.

[mvertens]

@slevisconsulting - could you please try building this as well using the updated README and make sure it builds. If so we should merge this and updated the branch tag.

[slevis-lmwg]

@slevisconsulting - could you please try building this as well using the updated README and make sure it builds. If so we should merge this and updated the branch tag.

Success! I have small updates to the README that I cannot push to this branch but can push later to the ctsm5.2.mksurfdata branch.

[slevis-lmwg]

If you do include my README updates, here's another:

the git checkout needs to change to:
git checkout ctsm5.2.mksurfdata

Otherwise, I can get these updates in at a later time.

Thanks, @jedwards4b

[jedwards4b]

I pushed the README changes to my branch - look okay @slevisconsulting ?

[slevis-lmwg]

I pushed the README changes to my branch - look okay @slevisconsulting ?

4dd0eb6
looks right, but the "resolve merge conflict" seems to reverse a couple of the changes. Or am I mistaken?

[jedwards4b]

look okay now?

[slevis-lmwg]

@ekluzek I see that I have permission to merge here, but I don't know how to make a new tag. Do you want to keep making the new tags or should I also have permission to do that in this branch?

[ekluzek]

I think I should still make the tags. But, if that becomes a problem we can reassess. We likely could give you permission for the alpha branch, whereas we are more careful about having limited access to the main and release branches. We should discuss this with CTSM SE people next week. We could bring it up at the Tuesday meeting. @billsacks do you have any thoughts on this now?

[billsacks]

I have no problem with @slevisconsulting pushing to this branch and making tags himself.

[ekluzek]

@slevisconsulting and I discussed this a bit, and decided on a few things. I'm going to make a few changes to get the build script working, and we'll recommend using it in the README file. We think relying on the cime build makes sense, since in general people will be running on the same machine and they'll need to do a port to cime to get it work. Relying on the cime port allows cime to manage the module load versions, which is otherwise to difficult manage for mksurfdata, the versions change faster than we can keep up with for the tool, but we do keep up with it in cime/ccs_config.

[ekluzek]

@jedwards4b I tried to see if this would work on izumi, and I see there is an implicit assumption here that a PIO library is already built. For cases such as on izumi, where you'll need to also build PIO, how should that work? Should you build PIO independently and then run this build? I think that's OK, but we'll need to document more about it.

[jedwards4b]

As I've stated in the cseg meeting we need to start installing a PIO module on all systems.
Currently I have a PIO build in /home/jedwards/pio/2.5.7/intel that I used to get the mksurfdata build working there.

[ekluzek]

OK, sounds good. Sorry I missed hearing that and connecting that to mksurfdata_esmf. It does make sense to me to require a build of PIO for CESM. We should add to the documentation that a build of: MPI, ESMF, and PIO are all required.

[ekluzek]

@slevisconsulting and I are meeting to go over this. Two things that we think should probably happen with this:

1.) A FindPIO cmake module to make sure an appropriate version of PIO is found.
2.) Convert the build script from bash to python? At least for consistency with other scripts.
3.) A FindMPI cmake module? This might not be needed because that sort of falls out of getting
an ESMF version and there already is a FindESMF in place.

We think those should likely become issues and I'll do that later.