Error with setting of prigent streams when coupled with CAM

[ekluzek]

Brief summary of bug

F compsets with ctsm5.2.019 (with dust emissions for Leung_2023 in place) fail with an error.

This was originally noted by @fvitt here in CAM:

ESCOMP/CAM#1104 (comment)

General bug information

CTSM version you are using: ctsm5.2.019

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

Configurations affected: B and F compsets where CTSM is used coupled to CAM

Details of bug

This is with cam6_4_015-10-ge393c668 in CAM on @fvitt dust_emissions branch.

Important details of your setup / configuration so we can reproduce the bug

The problem is that the setting of use_prigent_roughness relies on knowing what dust_emis_method is. When LND_SETS_DUST_EMIS_DRV_FLDS is TRUE this is going to be known by CLM, but not when it's FALSE it needs to get it from CAM and not rely on it's own setting.

Important output or errors that show the problem

cime/scripts> ./create_test SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem -r . --walltime 00:20:00
Testnames: ['SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem']
Using project from .cesm_proj: P93300606
create_test will do up to 1 tasks simultaneously
create_test will use up to 160 cores simultaneously
Creating test directory /glade/derecho/scratch/erik/cam_dust_emis/cime/scripts/SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem.20240813_131716_ycbhi8
RUNNING TESTS:
  SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem
Starting CREATE_NEWCASE for test SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem with 1 procs
Finished CREATE_NEWCASE for test SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem in 9.195398 seconds (PASS)
Starting XML for test SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem with 1 procs
Finished XML for test SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem in 0.413804 seconds (PASS)
Starting SETUP for test SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem with 1 procs
Finished SETUP for test SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem in 4.892254 seconds (PASS)
Starting SHAREDLIB_BUILD for test SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem with 1 procs
Finished SHAREDLIB_BUILD for test SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem in 6.334215 seconds (FAIL). [COMPLETED 1 of 1]
    Case dir: /glade/derecho/scratch/erik/cam_dust_emis/cime/scripts/SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem.20240813_131716_ycbhi8
    Errors were:
        Building test for SMS in directory /glade/derecho/scratch/erik/cam_dust_emis/cime/scripts/SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem.20240813_131716_ycbhi8
        ERROR: Command /glade/derecho/scratch/erik/cam_dust_emis/components/clm/bld/build-namelist failed rc=255
        out=
        err=Warning : CLM build-namelist::CLMBuildNamelist::setup_logic_prigent_roughness() : use_prigent_roughness does NOT need to on without dust_emis_method being Leung_2023, it simply won't be used
         -- Add -ignore_warnings option to CLM_BLDNML_OPTS to ignore this warning

Waiting for tests to finish
FAIL SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem (phase SHAREDLIB_BUILD)
    Case dir: /glade/derecho/scratch/erik/cam_dust_emis/cime/scripts/SMS_Ln9.f19_f19_mg17.FHIST.derecho_intel.cam-outfrq9s_nochem.20240813_131716_ycbhi8
Due to presence of batch system, create_test will exit before tests are complete.
To force create_test to wait for full completion, use --wait
test-scheduler took 21.338916063308716 seconds

[ekluzek]

I think the way to fix this is for the prigent streams to also check LND_SETS_DUST_EMIS_DRV_FLDS and if it's FALSE, it then gets the drv_flds_in file from $CASEDIR/Buildconf/camconf/drv_flds_in and uses it. With it aborting if the file isn't found or if it isn't coupled to CAM.

I should be able to construct a test for this in the build-namelist unit tester.

I'm marking this as b4b since in terms of CTSM testing it'll be identical to baselines.

[ekluzek]

The problem with this solution is that it does mean the coupling here is closely tied with CAM and possibly changes in CAM around this might require synchronized changes in CTSM. But, likely that would be things like changing the drv_flds_in filename or contents and that would need to be synchronized anyway, as well as the Bouldconf/camconf subdirectory name -- but that would likely be across CESM as well. So the main downside is that it will be built in to assume that it's coupled to CAM and not another ATM. But, again that's an unlikely thing to be done anytime soon.

[ekluzek]

Fixed in ctsm5.2.027 but didn't autoclose.