Update the drv_flds namelist definition file in CTSM to work with latest CAM/cmeps

[ekluzek]

Brief summary of bug

I see this as a problem in trying SMS.f09_g17.2000_CAM%DEV_CLM51%SP_SICE_SOCN_MOSART_SGLC_SWAV.cheyenne_intel.clm-default
with ctsm5.1.dev125 (technically a ctsm5.2 branch of it, but shouldn't be relevant here).

General bug information

CTSM version you are using: ctsm5.1.dev125-384-gaa3c5cc8a

Does this bug cause significantly incorrect results in the model's science? No

Configurations affected: Some configurations with CAM

Details of bug

I'm not really sure why this isn't a problem all of the time. As cases with CAM obviously work. So why is this an issue in this case?

Important output or errors that show the problem

This is the error I see when running preview_namelists for the above test. It does fail at this point and doesn't populate CaseDocs with namelists...

Create namelist for component drv
   Calling /glade/work/erik/ctsm_worktrees/ctsm5.2.mksurfdata/components/cmeps/cime_config/buildnml
Writing nuopc_runconfig for components ['CPL', 'ATM', 'LND', 'ROF']
ERROR: Variable 'atm_provides_lightning' from file '/glade/work/erik/ctsm_worktrees/ctsm5.2.mksurfdata/cime/scripts/SMS.f09_g17.2000_CAM%DEV_CLM51%SP_SICE_SOCN_MOSART_SGLC_SWAV.cheyenne_intel.clm-default.C.20230925_160609_ag813w/Buildconf/camconf/drv_flds_in' is not in the namelist definition.

[ekluzek]

The missing parts from the CAM namelist definition file appear to be...

<!-- Ozone namelist variables shared between CAM and driver -->

<entry id="atm_ozone_frequency" type="char*64" category="ozone_coupling"
       group="ozone_coupling_nl" valid_values="subdaily,multiday_average">
Frequency of surface ozone field passed from CAM to surface components.
Surface ozone is passed every coupling interval, but this namelist flag
indicates whether the timestep-level values are interpolated from a
coarser temporal resolution.
Default: set by build-namelist.
</entry>

<entry id="atm_provides_lightning" type="logical" category="lightning_coupling"
       group="lightning_coupling_nl" valid_values="">
If TRUE atmosphere model will provide prognosed lightning flash frequency.
Default: FALSE
</entry>

Similarily in the CMEPS namelist definiton those two appear to be missing in CLM:

  <!-- ========================================================================================  -->
  <!-- Ozone control                                                                             -->
  <!-- ========================================================================================  -->

  <entry id="atm_ozone_frequency">
    <type>char</type>
    <category>ozone_coupling</category>
    <group>ozone_coupling_nl</group>
    <desc>
      Frequency of surface ozone field passed from CAM to surface components.
      Surface ozone is passed every coupling interval, but this namelist flag
      indicates whether the timestep-level values are interpolated from a
      coarser temporal resolution.
    </desc>
  </entry>

  <!-- ========================================================================================  -->
  <!-- Lightning                                                                                 -->
  <!-- ========================================================================================  -->

  <entry id="atm_provides_lightning">
    <type>logical</type>
    <category>lightning_coupling</category>
    <group>lightning_coupling_nl</group>
    <desc>
      If TRUE atmosphere model will provide prognosed lightning flash frequency (flashes per minute).
    </desc>
  </entry>

[wwieder]

@ekluzek what's the prioritization of this? Before or after the science capability code freeze July 31st?

[ekluzek]

@wwieder I put this as something to do by the answer changing freeze. There are two parts here, one has to do with Ozone and I wonder if it's going to interfere with #2496 and #2302 (especially the first)? The second part is about being able to use lightning from CAM. The second might be an experimental feature we get in as optional for CESM3, but isn't critical. But, it will also require changes to CTSM to take advantage of the new field, merely adding it to the namelist won't allow it to actually work.

[ekluzek]

The other thing that might make this one important is if it's interfering with tests and cases that CAM is running. And I'm not clear if that is the case or not, or what cases might be failing..

[ekluzek]

Turns out this is blocking my solution for #2687 in #2699

[ekluzek]

This was fixed in #2170 so closing...