Move the dust emission source function and global tuning factor from CAM to CTSM

[dmleung]

Issue Type

Code Clean-up

Issue Description

Hi this is Danny, a PhD student at UCLA and NCAR working with @jfkok and @dlawrenncar on CTSM dust modeling development. Here we request to move the CAM dust soil erodibility map and global tuning factor for the dust scheme previously read in and manipulated in CAM to CTSM. This issue is also posted on CTSM github ESCOMP/CTSM#1836.

In issue ESCOMP/CTSM#1604 we proposed to add a new dust emission scheme improving the dust mobilization parameterizations in CLM. Although a new scheme will be added as in PR ESCOMP/CTSM#1712, CLM people decided to keep the existing emission scheme by Zender (2003). One issue is that the (time-independent) soil erodibility source function employed by Zender's scheme has always been read in and applied to the CAM emission flux instead of to the CLM emission flux, likely due to historical reasons. However, conceptually, how soil erodibility and land-surface characteristics affect the emission strength should be part of the land processes, and we believe it should be read in and applied in CLM instead of CAM. CLM has a variable for the Zender source function called mbl_bsn_fct, but it has always been set as 1 as a place holder and it is conceptually the same variable as the soil_erod in CAM. Here we request moving the soil erodibility map from CAM to CLM into mbl_bsn_fct, coming as part of either the surface dataset or the stream file.

This small modification will make the CLM dust emission scheme more conceptually complete, and eliminate conceptually overlapping variables among CLM and CAM.

Also, there is a global tuning factor (with CAM namelist variable dust_emis_fact) that controls the magnitude of the global total dust emission. Due to the same reason we think it should also be moved to CLM.

In CAM, we would like to modify the atm dust module and the namelist definition/defaults. Several Fortran variables, namelist variables, and output fields are proposed to be removed.

@dmleung proposed the modification. @dlawrenncar, @lkemmons, @L3atm, and software engineers including @ekluzek and @fvitt agreed about the decision.
@dmleung will work on this issue in both CLM and CAM with help from @ekluzek and @fvitt.

I know CAM people will tune aerosols (including dust) often when they have new CAM versions. They might need to hereafter tune it in CLM instead of CAM. @cecilehannay is informed.

Thank you,
Danny

Files to be changed:
clm/src/biogeochem/DUSTMod.F90
clm/bld/namelist_files/namelist_defaults_ctsm.xml
clm/bld/namelist_files/namelist_definition_ctsm.xml
cam/bld/namelist_files/namelist_defaults_cam.xml
cam/bld/namelist_files/namelist_definitions.xml
cam/src/chemistry/modal_aero/dust_model.F90
cam/src/chemistry/aerosol/soil_erod_mod.F90
Some of the below CLM files will also be changed for adding the namelist variables and reading in the soil erodibility dataset:
clm/src/biogeophys/SoilStateType.F90
clm/src/biogeophys/SoilStateInitTimeConstMod.F90
clm/src/main/controlMod.F90
clm/src/main/clm_varctl.F90

P.S.

1. Subsequently, some CAM output fields, e.g., LND_MBL (Zender's source function) and DSTSFMBL (emission flux) will be cleared up. For instance, LND_MBL might become a CLM output instead of CAM output.
2. Path of the original soil erodibility data read in by CAM: soil_erod_file='/glade/p/cesmdata/cseg/inputdata/atm/cam/dst/dst_source2x2tunedcam6-2x2-04062017.nc'
3. The CAM soil erodibility file is 2x2 and is interpolated in CAM using the function lininterp to other resolutions. CLM will thus need to do the same (a stream file might be more capable of performing the interpolation).

Will this change answers?

Yes

Will you be implementing this yourself?

Yes

[adamrher]

I welcome this development! I have two questions ... (1) can we deprecate any subroutines or modules in cam/src/chemistry after this move? (2) What is the purpose of cam/src/chemistry/modal_aero/dust_model.F90 anymore?

More broadly, can we not eliminate code because we need to retain this old dust functionality for running older cam physics packages?

[ekluzek]

Since, this needs to go in both CTSM and CAM, we will need to coordinate both set of changes. Possibly the best way to do it initially is to have a namelist toggle that allows it to be done the old way (inside of CAM) or the new way (inside of CTSM). A namelist toggle would need to be inside both components. The default could be for the current behavior, but then when we have both in place, we can change the default be to have it in CTSM. Sometime later after that the old option could be removed as a code cleanup step. So that suggests a sequence something like this:

• Add a namelist option to remove doing it in CAM, but default is current behavior
• Update to the CTSM version that has a namelist option to handle it inside of CTSM
• A tag to change the defaults in both CAM and CTSM to make the default to handle inside of CTSM (will also be coordinated with a CESM tag)
• A tag to remove the current behavior in both CAM and CTSM (could be two tags)

I suggest that @fvitt will be responsible for this coming into CAM, after @dmleung gets the initial PR ready to go. The other tags could be done by others as they are far simpler, but @fvitt will likely coordinate.

@cacraigucar @gold2718 @fischer-ncar and @fvitt does the above plan sound acceptable to all? Should we meet to discuss or is it outlined well enough that you see what needs to happen?

[ekluzek]

@adamrher above I suggested a plan where the last step would be to remove the current way of doing things. Your second question/point about older versions suggests that we should probably NOT do that step, and keep the namelist trigger around.

[ekluzek]

@dmleung and all, note that this will have a quantitative change in answers (because the interpolation method will be different). But, qualitatively we expect answers to be very close without a significant change. It's possible it will just be a roundoff difference, but may be larger than that -- but certainly NOT a bit-for-bit change. We should edit the top box to show this is the case.

[dmleung]

Hi @adamrher thanks for the questions!

(1) currently I have no plan to deprecate any subroutines/modules but will do so if we finally see some of them are clearly not doing anything anymore.
(2) this is related to (1), and I see that dust_model.F90 still serves several other important purposes, such as processing the dust emission flux from the coupler and saving it in a way that CAM likes. For now I don't see a clear path to eliminate the module, or a lot more work might be required.

I think the final question is important, thanks for asking! I primarily see this change to apply to CAM6 and CAM7, but if people want to use CAM4 or CAM5 we might need to add a namelist option to trigger the namelist variables for CAM4/5 and turn them off for CAM6/7. The same thing applies if someone wants to use bulk aerosol instead of modal aerosol. I will discuss this with the software engineers.

[dmleung]

@ekluzek I changed it in the top box.

[adamrher]

I think that the unavoidable truth is that we probably should retain the old dust emissions workflow, as much as I wish we didn't have to. We can't avoid that CAM has been retaining partial ownership of the dust emissions up until this point. If we want to be able to run CLM5+CAM6 on the latest cesm tags, there's just no way around it.

However ...

I would be perfectly fine with not being so evangelical about retaining old versions on the latest tags ... For example, if we throw all the dust workflow into clm and I run with -phys cam6, and clm runs with the old zender emission algorithm, I'm perfectly fine calling that CAM6 physics.

But what about if I wanted to run an older version of the clm "physics" like CLM4, on the latest tag ... would that still be expecting the soil erodibility factors to be coming from CAM?

[ekluzek]

Right now you can only flip between clm physics for: clm4_5, clm5_0, and clm5_1. So clm4_0 is NOT available. And we'll be adding clm5_2, and possibly other incremental clm5 physics options. I think we are going to make the dust namelist option in the CTSM side so that it can be on or off for ANY of the physics options. We just need the defaults for CTSM to align with what CAM makes it's defaults for different CAM versions.

So if the compsets for CAM4 and CAM5 use clm4_5 or clm5_0, and they expect dust emissions inside of CAM -- we'll make clm4_5 and clm5_0 by default have it turned off. For CAM6 and CAM7 maybe we do the opposite of that and have it turned off in CAM, but on in the clm5_1, clm5_2, and following CLM physics options.

The problem with that is that you can mix and match things with long compset names. So we might either need the defaults to be one way or the other and not dependent on the physics versions. Or we need a way to ensure that the user can't screw it up and have it either off in both CTSM and CAM or on in both CTSM and CAM, as that would apply the same thing twice.

Possibly this means that instead of having a namelist option in both components that we have a single one in the drv_flds_in namelist and/or in the XML for the compset. Both CAM and CTSM would listen to this single source and you couldn't set it up wrongly.

[swrneale]

If the functionality of being able to tune based on the same variables is maintained then I don't see a problem. I think CAM4 had prescribed dust, but I can't quite remember and we used the tuning a lot for CAM5. Although it maybe that we get rid of CAM5 and keep CAM4 in the development branch, not clear at this point. For CAM6 it is nice to keep that physics capability on the development trunk for now but dust does have an impact on radiative and ice nucleation processes so it could lead to important differences. Out of interest what are the different characteristics of dust emission with the Zender and the new schemes?

[adamrher]

Good point, I recall that dust_emis_fact is used a lot for tuning. This will be switched to a clm namelist with the new workflow. We will just have to adapt.

If we run CAM5 with the old zender code, but with the new workflow, is it still CAM5? There will be answer changes due to different interpolations/other workflow differences as Erik describes, but it may be that it doesn't change the climate. In which case I would still call that CAM5.

[ekluzek]

@adamrher I think the answer is Yes both for CAM and CLM. We have older physics options, but they do have answer differences greater than roundoff from the original release of CAM5. If you want the original CAM5 answers you have to run the older version. Usually these changes are small bug-fixes that should still give the same qualitative results. But, strictly speaking they are going to be answer changing from the original release.

So for example for clm5_0 physics in the latest CTSM ctsm5.1.dev106 , we know that's going to give different answers from release-clm5.0.34 and greater than roundoff different. But, we don't expect it to be a significantly different climate. There were some significant bug fixes that are in the latest development code that do make the changes significant, but we still think it's useful to label it clm5_0 physics. I expect these changes we are talking about here for dust, to be much less significant than those other bug fixes we have in clm5_0 physics. It's possible the difference will only be a roundoff level change which for practical purposes of computing is identical. If the larger bug-fixes are deemed acceptable this change certainly should be as well.

[dmleung]

Hi @swrneale,
-I believe CESM1/CAM4 has active dust per Albani 2014 and Kok 2014, but feel free to correct me if I was mistaken.
-Yes, it will have certain consequences to the radiative effect and ice nucleation process, and I am evaluating them in CAM6. A majority of radiative effect evaluations are out in Longlei Li's paper given he's using the same base scheme as I do (Kok 2014).
-I have some slides that summarize the differences between our scheme and Zender's scheme. In short, it is mainly (1) the shift from Zender to Kok's scheme, as well as, on top of Kok, the inclusions of (2) effect of wind drag partition effect due to rocks and vegetation presenting on deserts, and (3) effect of boundary-layer turbulence on sub-hourly wind fluctuations.

In the future versions of CLM, I believe the default emission scheme will be the new one but we will also keep Zender's scheme since I believe the CAM community will love that alternative namelist option. To avoid automatically imposing the Zender source function to our new CLM dust emissions, we thus need to do something to the CAM dust module.

[dmleung]

@adamrher
yes so we hope to moving the &dust_nl to CLM, so CAM people might need to tune things in the CLM namelist in the future...
Again, I have no intention to touch anything in CAM5, so you won't see new workflow in CAM5. Our changes will only be in CAM6 and CAM7. Like Erik said, it will only be problematic when someone is specifying to use CLM4.5-CAM6 or CLM5.2-CAM5. We will try to avoid it from happening.

[adamrher]

@tilmes would you mind elaborating on the dust changes you plan to implement? I wanted to make you aware of this separate dust work that is coming in as well (see also accompanying CTSM issue), to make sure if it's not inconsistent with your planned mods.

@wwieder

[wwieder]

Thanks for starting this discussion, @adamrher. Yes, clarity here would be helpful @tilmes, as @dmleung and @ekluzek are working with seems like parallel effort. Are there efforts that need to be coordinated here?

[tilmes]

@adamrher @wwieder I am not implementing any dust changes or perform a parallel effort. The updates in MAM4 bin widths for the coarse mode (equivalent to MAM5 using chemistry) complement the work Danny is doing.

[wwieder]

Thanks for clarifying, @tilmes. To circle back to the question I was asking at co-chairs, @JulioTBacmeister, are the dust emission changes that @dmleung is making in CTSM critical for your next phase of of CAM development and testing?

[tilmes]

It would be good to have most of the changes in that influence aerosols they in particular influence clouds and any tuning will have to be redone if we leave it for later.

[adamrher]

Julio's out for the rest of the week, and so am I. But I would says it's ideal to get these mods in at some point in the 2023 development cycle, for the reasons Simone says. The earlier the better, and indeed if it takes to long, it may be too late, and after the code freeze. What seems like a reasonable target date to complete this work? AMP SE resources are going to be severely limited in the first half of 2023 owing to the focus on CCPP ... so keep that in mind if it contains significant CAM work.

[wwieder]

OK, thanks for this guidance, Adam. @dmleung and @ekluzek how is progress moving along in the CTSM PR #1897? Does it seem reasonable to wrap this up the CLM-side work in the first quarter of 2023, or is more like likely needed?

[ekluzek]

@wwieder it takes some effort to make estimates. And because we don't do it often, we aren't good at it. I am meeting with @dmleung Friday and we can start assessing that. And then early January we can do more work on figuring this out. @dmleung is close to graduating and we do hope to have this finished before he's done. There's work that we need @dmleung to do for sure, but then there's work like this particular PR that could be done by someone else.

@adamrher and @tilmes from the description it sounds like the change in MAM5 is the bin sizes for dust. Does that mean there will be a different number of dust bins and the sizes will be different? I would think that would need to be accounted for in CLM. But, other than this part of removing the dust emission source inside of CAM, that's all on the CLM side of things. So I don't think we need much in the way of CAM resources, unless it turns out we need someone from CAM to do this specific task.

[tilmes]

@ekluzek we are only changing the size for the coarse mode dust bin for CAM with simple chemistry. This is going back to CAM5 and since we did not change anything between CAM5 and CAM6 it should not be needed here as well. However, I am planning to look into the land and ocean fluxes of dust and BC from the atmosphere next week. We may have to revisit this. Please note, the mode 5 only exists for runs with interactive stratospheric chemistry, so here, maybe we have to also consider the 5th mode for the land. I am not sure.

[dmleung]

Hi all, thanks for the questions. Per @ekluzek I think the main task left for ESCOMP/CTSM#1897 is mainly to transform the roughness length dataset required by the dust emission scheme from a surface dataset format to a stream file format. I am figuring out how stream files work, although on the first impression it appears not very complicated. However, the dust emission code for reading a fsurdat type of roughness dataset is readily available in ESCOMP/CTSM#1897 for the latest CTSM version. @ekluzek and I tested it and it works well in an F compset setting. I do think @tilmes can use it if Simone wants some testings for the ocean in the following week, although Simone told me she does not mind to wait till the updates are on the trunk. Everyone else can use the code in that PR too when they need to do testings.
@tilmes I am curious, what do you mean when you say you "have to also consider the 5th mode for the land"? Do you mean when, for example, in a configuration where we have both CTSM and CAM, even if there is no stratosphere you will make a 5th mode in CAM? Also, could you clarify on why, when there are changes in the dust emission scheme, you may have to also consider the 5th mode for the land? Thanks.
@tilmes @wwieder @adamrher @JulioTBacmeister I didn't know there are many people waiting for using the updates for testings. It would be great if you could tell me all of your deadlines, so @ekluzek and I could try to plan accordingly.
@wwieder I do think the first quarter of 2023 sounds very reasonable, but @ekluzek will know much better than I do. I will talk to Erik on Friday and see if we come up with our deadline. If so, I will give an update to you all.

[wwieder]

Hi All, Dust in CAM6 was mentioned again at the co-chair's meeting. @dmleung I'm also assuming that you're trying to graduate (maybe as early as May)? How close to you think we are to having this ready to merge on the CTSM side? It will help us prioritize this PR as we plan out SE resources over the next few weeks to months.

[ekluzek]

@wwieder I'll let @dmleung answer some of this for sure. But, indeed he is in the midst of graduating this spring. His main efforts are in working on his dust parameterization within CTSM. That's the part that we need him to accomplish. The specific task in this issue is something we could have someone else do. This is a software infrastructure change that we possibly should assign someone else to do. I think we need to get a group of CAM and CTSM and CTSM-Chem people together to talk about this. We need project leads to understand the big picture of what is going on, and who's working on it, and then some specific workers to understand the details. I am continuing to meet with @dmleung weekly and keep the CTSM Dust project page updated (https://github.com/ESCOMP/CTSM/projects/38).

[dmleung]

Hi @wwieder, I think this issue on moving the Zender source function needs to be done right after my work on the dust parameterization is on the master branch. Without moving the source function away, my scheme will be masked by this CAM source function and the simulations will go wrong. That's why this issue is raised so that users still access the source function in CTSM when the older (Zender's) scheme is chosen in CTSM. I think it will be great to have someone take care of this issue on moving the source function. If not, I will work on this after ESCOMP/CTSM#1897 is nearly finished. Erik will have a much better understanding on the timeline and the remaining tasks in 1897 and Project#38 (@ekluzek, how many tasks left after coding up the streams capability? Are we close to done?) Also, Erik will know better about how the roughness streams files I am working on in 1897 can benefit the the implmenetation of the source function into CTSM, but I suppose they will use the same setup here (/glade/u/home/dleung/CESM2/ctsm_dustemis_dev/PrigentRoughnessStreamType.F90). So, working on this issue when 1897 is about done makes a lot of sense, at least to me.
(P.S. UCLA is following a quarter system so I should graduate sometime before Aug, hopefully... )

[wwieder]

Thanks for this input Danny and Erik,
I suggest that you both spend your time focusing on the CTSM side of this PR. I'd like to ask @cacraigucar or another CAM-SE to handle the CAM side changes that need to happen once the land dust sources are improved with @dmleung's new parameterization.

[tilmes]

@dmleung A quick answer to the MAM5 implementation. For dust, there will actually be no change in the number of notes, we still have dst_a1, dst_a2, dst_a3. The only change that is already implemented in the development version is #664 is the sigma range of dst_a3 from 1.2 back to 1.6 as it was in CAM5. This should improve / change dust emissions. @wwieder who is working on the CAM side of the problem?

[adamrher]

who is working on the CAM side of the problem?

No one is working on the CAM side, which based on my understanding amounts to deactivating using the dust source function in CAM to enable use of the source function now in CTSM.

[fvitt]

I assigned myself to this issue.
See also #141

[ekluzek]

Note the dust work is being kept track of in this project for CTSM:

https://github.com/ESCOMP/CTSM/projects/38

I've updated that project board to say that Francis will take care of this task. By the way @fvitt thanks for volunteering!

[dmleung]

Thank you very much @fvitt!

[fvitt]

See PR #748

[ekluzek]

We decided in a meeting to leave the global tuning factor in CAM. So the only thing that moves is the soil erodibility file. See this discussion:

ESCOMP/CTSM#1967 (comment)

[ekluzek]

I put together a design document to lay out how to do this here:

https://docs.google.com/document/d/18nZ3LJF5W-YF9iBhqed6s_NWeKOvSSL2-k0Lye1nnLg

@fvitt please add comments or suggestions to that document. Happy to discuss further if needed...