Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plan to phase out LND_SETS_DUST_EMIS_DRV_FLDS #2713

Open
2 of 9 tasks
ekluzek opened this issue Aug 19, 2024 · 4 comments
Open
2 of 9 tasks

Plan to phase out LND_SETS_DUST_EMIS_DRV_FLDS #2713

ekluzek opened this issue Aug 19, 2024 · 4 comments
Assignees
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

Comments

@ekluzek
Copy link
Collaborator

ekluzek commented Aug 19, 2024

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:

  • CTSM tag with short term fix
  • CAM tag with short term fix
  • Think about the dust scaling knob (should it be in CTSM or CAM?) What should it look like? If in CAM you can have one knob for Zender and another for Leung and at runtime the appropriate one used. But, that means the user will have to realize which one to use, which isn't ideal. But, also this will likely need to be tuned for different physics, and chemistry options in CAM.
  • CTSM side, when coupled to CAM we need to set: --no-megan, --no-drydep --no-fire_emiss,. Also add a tuning flag inside of CTSM for scaling dust emissions from Leung.
  • In CAM we need to turn off reading in Zender soil erod source files and use them from CTSM (so zender_soil_erod_source = 'lnd'). This will need to be tested to make sure it's correct.
  • Add an abort to CMEPS if the CLM and CAM drv_flds_in namelists are in conflict (identical or merge is OK).
  • CAM tag where LND_SETS_DUST_EMIS_DRV_FLDS==TRUE, and isn't allowed to be FALSE, as well as NOT allowing CAM to set dust_emis_method nor zender_soil_erod_source.
  • CTSM tag where LND_SETS_DUST_EMIS_DRV_FLDS is removed and remove the read of the CAM drv_flds_in namelist
  • CAM tag where LND_SETS_DUST_EMIS_DRV_FLDS is removed
@ekluzek ekluzek added code health improving internal code structure to make easier to maintain (sustainability) next this should get some attention in the next week or two. Normally each Thursday SE meeting. usability Improve or clarify user-facing options labels Aug 19, 2024
@ekluzek ekluzek added this to the ctsm6.0.0 (code freeze) milestone Aug 19, 2024
@ekluzek ekluzek self-assigned this Aug 19, 2024
@ekluzek
Copy link
Collaborator Author

ekluzek commented Aug 19, 2024

The short term fix I plan to make is for CTSM to read in the $CASEDIR/Buildconf/camconf/drv_flds_in file when LND_SETS_DUST_EMIS_DRV_FLDS==FALSE (and fail if that file is not found) for all the drv_flds_in field settings similar to the user_nl_clm file.

Since it's reading in the whole file -- I need to handle #2712 as well. An alternative would be to JUST read in the two dust emissions namelist settings -- but this would require special handling for just those rather than the use of the general method to read in namelist files.

Note, that having CTSM ALWAYS read in CAM's drv_flds_in namelist file -- also might be a good thing to do as discussed here: #2712 (comment). So the transition plan could be that LND_SETS_DUST_EMIS_DRV_FLDS is removed -- but the CAM drv_flds_in file is still read in. Or that it's removed AND the CAM drv_flds_in file is no longer read in as well.

@ekluzek
Copy link
Collaborator Author

ekluzek commented Aug 21, 2024

In talking with @adrifoster I realized this all makes the most sense if CTSM sets dust emissions type and CAM only listens to what CTSM decide to do. So I am now planning on going that direction.

This means that the read for CAM's drv_flds_in namelist will be removed as part of this.

@wwieder
Copy link
Contributor

wwieder commented Aug 21, 2024

+1 CAM should listen to CTSM more often :)

@ekluzek
Copy link
Collaborator Author

ekluzek commented Aug 23, 2024

@fvitt and I went over the plan together. We did realize that because of complexity with CAM chemistry, CAM should be the expert in deciding megan, drydep, and fire-emission. It's also likely that CAM should be the expert in setting dust tuning scaling factors that will be implemented as part of tuning dust in CAM/CTSM for the Leung scheme. So this aspect needs to be thought about more.

@samsrabin samsrabin added external issue needs to be addressed elsewhere (submodule); issue here for the sake of project tracking and removed next this should get some attention in the next week or two. Normally each Thursday SE meeting. labels Sep 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Development

No branches or pull requests

3 participants