Move most code from cesm/nuopc_cap_share into a subdirectory of the CESM_share repository

[billsacks]

There is currently a confusing situation in terms of where Fortran code lives that is shared between multiple CESM components: this code can live in either https://github.com/ESCOMP/CESM_share or in the cesm/nuopc_cap_share directory of CMEPS. Adding to the complications here, in a CESM build, nuopc_cap_share is pulled in as part of the CESM_share library build rather than being built as part of CMEPS. (These same things apply to NorESM as well, since NorESM uses both CESM_share and cesm/nuopc_cap_share.)

In talking with @mvertens about this, we propose:

• Moving most of the contents of cesm/nuopc_cap_share into a subdirectory of the CESM_share repository
• However, driver_pio_mod should be kept with the CMEPS driver code, since it doesn't appear to be used by anything else
• Also, we should be able to stop including flux_atmocn in the share code build, instead including it in the CMEPS build (apparently it used to be used by CICE, but that is no longer the case, so it can be kept local to CMEPS now)

This would help address (at least partially) the following issues:

• Prefer the "shr_" prefix naming convention for the cesm/nuopc_cap_share directory #400
• Standalone build and ESMX compatibility ... #402
• Add unit-testers for FORTRAN code in CMEPS #458
• how to build stand alone library of cmeps? #465

@jedwards4b - do you have any thoughts here? In particular, are there any gotchas you can think of?

@fischer-ncar - also looping you in because you were instrumental in the splitting of CIME, so you may have thoughts or experiences worth sharing here.

If others agree with this plan, I can take this on at some point, though not immediately.

[ekluzek]

i certainly like the idea of bringing in more organization and making it clear where things go. The one thought I have though about moving these to cesm_share is that most of the files in nuopc_cap_share are files handling the drv_flds_in namelist -- which is specific to the CMEPS driver. So it feels a little out of place to put them in cesm_share. But, even then I can still see doing this. When you move them though -- I'd want them to be a subdirectory of cesm_share that makes it clear that are nuopc_cap modules or that they are for drv_flds.

I also like that doing this helps with several existing issues that feels like a good thing to do. So general thumbs up from me.

[ekluzek]

I take it that driver_pio_mod.F90 would be moved to the cesm/driver directory, and the rest (insluding esm_utils_mod.F90 and glc_elevclass_mod.F90) would go under cesm_share in something like a nuopc_cap subdirectory of src?

[billsacks]

Thanks for your thoughts, @ekluzek . Good point about many of these handling drv_flds_in. Yes, we'd definitely have a subdirectory to hold these things that are specific to nuopc_cap and/or drv_flds... exact organization TBD.

I take it that driver_pio_mod.F90 would be moved to the cesm/driver directory, and the rest (insluding esm_utils_mod.F90 and glc_elevclass_mod.F90) would go under cesm_share in something like a nuopc_cap subdirectory of src?

Yes, exactly.

Also, I was thinking about a possible downside of this reorganization: Many of these modules require a call from the driver to initialize some data in the module. This means that introducing a new module would require a small, coordinated change in CMEPS. To avoid this need for a coordinated change, we may want a new, small module in share that calls all of the necessary initialization methods for various modules. Then there could be a single, stable call from the driver to this one shr_init routine. (It's possible, though, that this initialization needs to happen in a few different places rather than all at once in the driver initialization. My hope is still that we could have just a few shr_init calls rather than a separate call from CMEPS to the share code for every new shr module. I'll need to look at this more, but just wanted to note this idea.)

[jedwards4b]

I think that there are some subtle complications that will make this proposal difficult to achieve. However I applaud your desire to make the build less complicated and reduce the amount of repeated code. We will need our partners in NOAA to assure that we don't break anything for them.

[DeniseWorthen]

@jedwards4b Thanks for raising the point. I completely agree that reducing repeated code is a worthy goal but it has to work for both CESM and UFS.

[mvertens]

@jedwards4b - can you point out what these subtle complications are? From what I could see - none of the code in cesm/nuopc_cap_share was used by UFS - and I didn't see why most of it could not be moved to share/src/xxx_nuopc_xxx dir without any complications. What am I missing?

[jedwards4b]

I could be wrong. It could be that we decided on this structure initially because cesm_share was still also used by mct and we didn't want any esmf code there. In fact that may be the reason it was done this way, and that reason is no longer relevant.

[billsacks]

It could be that we decided on this structure initially because cesm_share was still also used by mct and we didn't want any esmf code there.

That was the main reason I could think of / remember for why we set things up this way, though I also remember that there were various ideal things that were harder-than-expected to achieve when we (especially @fischer-ncar) did the CIME split, so I couldn't remember if there were other factors here.

@DeniseWorthen - Is it safe to assume that things in the cesm/nuopc_cap_share directory are not used by UFS and so we're free to move that stuff around, or are there some subtleties that make that more complicated?

[jedwards4b]

I think that is correct - if it's under the cesm directory it's not used by UFS.

[DeniseWorthen]

@billsacks Yes, if it is in the cesm sub-dir, it should have no impact on UFS.

That was my initial thought when seeing this issue, but as the conversation progressed I wasn't completely confident that other things weren't under discussion.