Allow user to change drv_flds_in settings even if the relevent (--drydep, --megan, --fire-emiss) option isn't in CLM_BLDNML_OPTS

[ekluzek]

This is coming up in the context of #2699. And I think I'll likely need to change this behavior at least temporarily. The question is whether this change is a good long term change or not.

There are settings for fields that will go into drv_flds_in (that are needed by both CAM and CTSM) in CLM_BLDNML_OPTS (--drydep, --megan, or fire-emiss) that do these things:

1. Turn on these fields for testing in stand-alone CTSM (with somewhat arbitrary settings determined by CLM).
2. If off (--no-drydep, --no-megan, or --no-fire-emiss) -- don't allow the settings to be set in user_nl_clm.
3. NOTE: If you contradict yourself by setting them both in CAM and CTSM -- it'll die with an error on the contradiction

The first option is important so that we are testing them in stand-alone CTSM in our testing and so that simulations have output for these things that can be examined in the standalone context. The second one isn't strictly required because the 3rd one will ensure that you can't contradict yourself between CAM and CTSM.

My plan is to turn off "2" for now. But, after discussion we can either add it back in or leave it that way depending on what we think is the best way to handle this. Not hearing any dissent on this we will make this change without planning to change it back.

@fvitt

Definition of done:

• Change the ability in build-namelist to allow setting these in user_nl_clm even when the command line is for off
• Update build-namelist documentation for these fields
• Update User's Guide about the new behavior
• Talk about this in the ChangeLog to describe the change in behavior

[ekluzek]

Another important angle here, is that several of these do NOT work with FATES and that is a more important wrinkle than making sure CTSM doesn't set them. Since, when we start running FATES coupled to CAM, we'll want the user and CAM to know that setting megan, or dry-dep, or fire-emiss doesn't work. See these issues:

#2307 #2308 #1834 #1784 #1045

The current checking just makes sure that CTSM doesn't set anything that CAM might, but with FATES it would be good for CTSM to double check what CAM is trying to do to make sure CAM isn't asking for something that FATES can't provide. We can have the FORTRAN code shut it down at runtime (although I don't think we do currently), but it's always good to catch these things as soon as possible, and before submitting is better.

[ekluzek]

See this discussion here:

#2713 (comment)

We thought that having both CAM AND CLM decide on settings and to know about each other's settings is a bad idea.

I think what this means here is that we should have the FORTRAN code shut down if CAM is trying to tell FATES to do drydep, megan or fire-emiss and NOT worry about checking for this in the build-namelist code.

[ekluzek]

Fixed in ctsm5.2.027