Plan to phase out LND_SETS_DUST_EMIS_DRV_FLDS #2713
Labels
code health
improving internal code structure to make easier to maintain (sustainability)
external
issue needs to be addressed elsewhere (submodule); issue here for the sake of project tracking
usability
Improve or clarify user-facing options
Milestone
LND_SETS_DUST_EMIS_DRV_FLDS was added to ctsm5.2.019 as a way to bridge between how dust emissions are currently handled between CAM and CTSM to a future way we want to handle it. Right now we want CAM to be able to act in a backwards compatible way and have control, until we can move the control all the way over to CTSM. Longer term CTSM should have control and CAM listens to it (with the ability for CAM users to change it if they need to).
The way it's working now in #2699 is that for CTSM standalone LND_SETS_DUST_EMIS_DRV_FLDS is set to TRUE and controlled by CTSM. When coupled to CAM (as in ESCOMP/CAM#1104). It's set to FALSE and CAM controls it. However, when CAM is controlling it the CTSM namelist still needs to know what it's set to so that the Prigent streams can be appropriately set (#2687). Which means CTSM needs to read in the drv_flds_in settings (at least for dust_emis_method and zender_soil_erod_source) from the CAM namelist. This CAN be done -- but it relies on the fact that the CAM namelist is set first, and it relies on assuming the CAM namelist is going to be accessible from $CASEDIR/Buildconf/camconf/drv_flds_in. If any of this changes because of an update to CAM -- it'll break. Since, this has been stable over the last decade or so -- this might be acceptable though. But, in order to remove this dependence I think it would be good to phase this feature out.
There's a couple different paths that could be done to achieve this, but here I'll list what I plan to do for now. We should have a few people discuss this to decide on the best path forward especially for the longer term solution.
@fvitt
Definition of done:
The text was updated successfully, but these errors were encountered: