Rework the CMEPS GitHub Action build to use the CESM_share library instead of the share code in CDEPS

[billsacks]

I'm running into trouble in the GitHub testing for #620 that I think is coming from the fact that I have made some changes in CESM_share that that CMEPS PR depends on. My understanding of the CMEPS GitHub action is that it gets the share code from CDEPS. This means that a change in CESM_share needed for CMEPS requires a new CDEPS tag as well, which feels kind of awkward.

@jedwards4b and @mvertens - This is something I could take on at some point, but I'd be interested in hearing your thoughts on this. @jedwards4b I'm especially interested in hearing any reasons you know of why making this change might be harder than expected....

[billsacks]

One thing that makes this a little harder is that the share GitHub action now depends on having a copy of CIME, whereas I see that the CMEPS action seems to deliberately avoid needing CIME. (I introduced this dependency on CIME a couple of months ago to remove duplication from the share build system.) So this change I'm suggesting here would introduce a new dependency of CMEPS on CIME for the GitHub action build, in addition to introducing a dependency on CESM_share; I'm not sure if that's considered a problem?

[jedwards4b]

I think that this was a requirement for UFS compatibility as they want to be able to use CMEPS and CDEPS without cime and without cesm specific externals like share.

[billsacks]

I think that this was a requirement for UFS compatibility as they want to be able to use CMEPS and CDEPS without cime and without cesm specific externals like share.

Thanks for this reminder. I guess this warrants some discussion involving UFS folks. It feels like the current situation is problematic to maintain and still keeps UFS dependent on the CESM share code, just via manual copies rater than a more maintainable mechanism. So I'd like to talk about whether there's a way we can improve this situation.

[jedwards4b]

I would love not to have to have copies if you can think of a way to do it. In the case of #620 I proposed an ifdef instead of a copy.

[mvertens]

Although I would also love to not have copies - I actually think the code with #ifdefs is bound to be more problematic longer term - since you are never guaranteed to compile the code where the #ifdefs don't apply. I think a talk with the UFS users/developers would be good - at least ping @DeniseWorthen about this.

[uturuncoglu]

@billsacks JFYI, here is the place under UFS WM: https://github.com/ufs-community/ufs-weather-model/tree/develop/CDEPS-interface. As I know they are also using same folder CDEPS-interface/ufs/cdeps_share also for CMEPS. They have also their own CMake interface.

[mvertens]

@uturuncoglu - thanks for the pointer. What is your feeling about the best approach for the new share code that Bill introduced.

[uturuncoglu]

@mvertens I have no any short answer to it. I have some level of experience to use both component outside of any modeling system. I am regularly using them with ESMX driver to test some ideas. My impression is that building and using them is way more complicated with the shared code and you need to find tricks that satisfies their dependencies. It is also same for the external components like MOM6, CICE. Even if you build them with tricks, you are still ending in a situation that all those components are requiring lots of attributes from ESMF config which are not documented well. cpl_scalar is also another issue that is creating problems when you connect those components via NUOPC connectors. There is no special handling of cpl_scalar in there and you are ending up an interpolation error since cpl_scalar is not a real field. I have recently tried fix an issue in my end related to MOM6 and it is handing of cpl_scalar. I think the ultimate approach is to have self contained components rater than relying on shared code or set of attributes etc. If we really need to introduce some dependency then it needs to be well documented and tested. That would be beneficial especially for external users that do not use any application like CESM or UFS. I think before doing any work on those component, we need to look them carefully and remove dependencies to external libraries, shared code etc. It is getting more complex along with the development in both end (NCAR and NOAA).

[mvertens]

@uturuncoglu - thanks for your thoughts. If we move away from share code (e.g. in CESM) you would be duplicating routines (e.g. shr_string_mod.F90, etc) in many components. In my initial implementation of CMEPS that is exactly what I tried to do - but @JEdwards convinced me that this was a step in the wrong direction. However, if enough different modeling efforts will use CMEPS - maybe that is something we should again consider. What I really don't like is CPP-ifdefs.
And that is a good point to consider about cpl_scalar.
@billsacks, @jedwards4b and @DeniseWorthen - it would be great to hear your thoughts.

[billsacks]

Thank you, everyone, for all of your thoughts here. I don't have any clear answers right now, but here are some thoughts:

First, I'm confused about the state of the share code within UFS. @uturuncoglu pointed to a directory with just a few modules, but there is also this subdirectory of CDEPS which contains nearly all of the contents of the CESM_share repository:

https://github.com/NOAA-EMC/CDEPS/tree/9f53664ef2e607ad25d6b6c939f2eac9ec818ee6/share

That is the one that I'm more concerned about.

I am open to limited use of #ifdefs, but agree with @mvertens that heavy use of them makes code hard to maintain. I see @uturuncoglu 's points about share code making things more challenging for components used in multiple modeling systems, but at the same time I see significant value in having a share code library in CESM, and I wouldn't want to give that up.

One possibility for components used in multiple modeling systems may be to introduce a thin layer between the component and the shared code. This thin layer could either have ifdefs or completely separate files that are built depending on the modeling system (with some logic in the build system). For example, one of the modules in the directory that @uturuncoglu pointed to is https://github.com/ufs-community/ufs-weather-model/blob/develop/CDEPS-interface/ufs/cdeps_share/shr_frz_mod.F90 . If a component (say, MOM) needs to use this, it would introduce its own intermediate module like frz_mod.F90. There would either be multiple versions of this file or a single file with ifdefs. Within CESM, this would merely dispatch to shr_frz_mod from the CESM_share code; within UFS it could either dispatch to a UFS-specific version, or it could have an inline implementation of these routines.

Specifically regarding the new water tracer code: I have been in some initial discussions with Sarah Lu about a project she's leading to integrate water isotopes in UFS. So I think we'll want CMEPS and CDEPS to handle water tracers / isotopes for both UFS and CESM. I'm not sure what that means, though, in terms of where this module should live.

[jedwards4b]

I hate having copies, it's far too error prone. My solution would be for everyone to use the cesm_share (would it help if we renamed it?) repository. I see from the link provided that NOAA also refuses to use the genf90 tool and instead make static copies of the post-processed files.

[uturuncoglu]

@billsacks Just to clarify little bit more. The UFS WM has their own copies because they do not want to use genf90 to create actual files from templates. They have lots of requirements that they need to follow from the operational system.

[jedwards4b]

@billsacks the problem with your proposed solution is NOAA's refusal to consider including the
https://github.com/ESCOMP/CESM_share repository in their build. I think your proposal would depend on overcoming that obstacle.