ctsm lilac should use old shr_pio_mod.F90

[jedwards4b]

The new version of shr_pio_mod.F90 used in cmeps uses NUOPC. Lilac does not use nuopc and
needs to continue to use the older version. This can be done by changing the line
https://github.com/ESCOMP/CESM_share/blob/main/buildlib.csm_share#L60 to be after line 71 iff lilac. That is if you are doing a lilac build you want share/src in the Filepath before components/cmeps/cesm/nuopc_cap_share.
But if you are doing a cmeps build you do not want this.

[billsacks]

Thank you @jedwards4b ! I really appreciate your looking into this.

@jedwards4b @ekluzek - We can distinguish a LILAC build based on the case's value of the xml variable LILAC_MODE (which is defined in CTSM's config_component.xml). It will have a value of "on" if building for LILAC, and will either be "off" or absent otherwise.

It is admittedly a bit of a hack that we build a LILAC case by piggy-backing on a nuopc/cmeps build, since we don't actually need cmeps for LILAC – but that seemed easier than introducing a completely new driver option, at least at the time. But that means that we periodically run into things like this, since the LILAC build acts like a nuopc build in some respects but not in others.

[billsacks]

I'm returning to this issue. @jedwards4b your suggestion of changing the Filepath makes sense to me – thanks again for the suggestion. Before I do that, though, I want to better understand if this is a reasonable long-term solution, or if we'll need something else long-term.

Specifically: What is the vision for the version of shr_pio_mod.F90 in the share code? I imagine that currently its main use is to support cases with MCT. But what will happen when we drop MCT? Is the plan that this share code version of shr_pio_mod.F90 will be dropped at that point, or can you see maintaining that version indefinitely? Basically I'm wondering: If we tie the LILAC build to that version, are we just going to need to fix things again in a few months when that version is removed or no longer maintained?

@mvertens I want to bring you into the loop here, too.

[jedwards4b]

I would imagine that that version gets dropped when mct is dropped. I think that for lilac it may be easiest not to use shr_pio at all and just write calls directly to pio.

[billsacks]

Thanks for these thoughts, @jedwards4b . Based on your input, I am going to try for a plan that won't involve any changes to the CESM_share repository. I am going to close this issue here and move further discussion back to ESCOMP/CTSM#1759, where I'll welcome input on my proposed plan.

[billsacks]

I realized that my proposed plan won't work (see ESCOMP/CTSM#1759 (comment)), so I think I'll need to do what @jedwards4b suggested initially.

This means that we'll need to maintain shr_pio_mod in the share repository just for the sake of LILAC even when MCT goes away, unless we can somehow change LILAC and/or the CMEPS version of shr_pio_mod so that those two can work together.

[billsacks]

The CESM_share piece of this fix came in with #34