CTSM5.3.04X: MEGAN coefs fix, answer changes for MEGAN

[fvitt]

Description of changes

Corrections on how MEGAN coefficients are applied.

Depends on ESCOMP/CMEPS#557

Specific notes

Contributors other than yourself, if any:

CTSM Issues Fixed (include github issue #):
Fixes #3016
Fixes #2710

Are answers expected to change (and if so in what way)? Yes, for MEGAN fields

Any User Interface Changes (namelist or namelist defaults changes)? No

Does this create a need to change or add documentation? Did you do so? No

Testing performed, if any: scientific testing is underway

[wwieder]

@ekluzek is this something your can review and merge?

@fvitt what timeline is this needed on the for the CAM-Chem group?

[wwieder]

Seems like lots of trailing white space cleanup with a few answer changing modifications. Thanks for opening up this PR.

[wwieder]

One more question, in #3016 there was a suggestion to set gamma_sm = 1., but I asked for one more science test to evaluate BVOC emissions with an updated CLM parameter file that reduces water stress in tropical forests.

A few questions / options to consider:

• Do we want to add as a namelist option for this to be under user control at run time? Alternatively,
• Should we go ahead and manually turn off the soil moisture control on isoprene emissions with this PR?
• Should either option above be linked with this PR to make a single MEGAN_updates tag?

@tilmes, @HuiWangWanderInGitHub, @lkemmons, @rosiealice can you weigh in here?

[ekluzek]

@wwieder yes, I'm planning on doing the testing and the merge, when we get the go ahead from @fvitt and Simone and Louisa.

[lkemmons]

I think it would be great to have the soil moisture (drought) impact on MEGAN emissions be a namelist option (on/off).
Maybe also with the option to provide an overall scaling factor to the new gamma_sm calculation, which I think Rosie suggested.

[wwieder]

I like that Idea too, @lkemmons, but would ask if @fvitt could create this capability, either on this PR or by opening a new one when it's ready?

[fvitt]

I like that Idea too, @lkemmons, but would ask if @fvitt could create this capability, either on this PR or by opening a new one when it's ready?

I will look into it.

[fvitt]

I think it would be great to have the soil moisture (drought) impact on MEGAN emissions be a namelist option (on/off). Maybe also with the option to provide an overall scaling factor to the new gamma_sm calculation, which I think Rosie suggested.

@lkemmons Do you have source mods where these changes at least hacked in?

[lkemmons]

No, sorry, I have not implemented a namelist option.

…

On Tue, Apr 15, 2025 at 4:16 PM Francis Vitt ***@***.***> wrote: I think it would be great to have the soil moisture (drought) impact on MEGAN emissions be a namelist option (on/off). Maybe also with the option to provide an overall scaling factor to the new gamma_sm calculation, which I think Rosie suggested. @lkemmons <https://github.com/lkemmons> Do you have source mods where these changes at least hacked in? — Reply to this email directly, view it on GitHub <#3065 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH5BH7O35PL5WSQHCXEHVID2ZWANJAVCNFSM6AAAAAB24YUFXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBXGY2TENZWHE> . You are receiving this because you were mentioned.Message ID: ***@***.***> *fvitt* left a comment (ESCOMP/CTSM#3065) <#3065 (comment)> I think it would be great to have the soil moisture (drought) impact on MEGAN emissions be a namelist option (on/off). Maybe also with the option to provide an overall scaling factor to the new gamma_sm calculation, which I think Rosie suggested. @lkemmons <https://github.com/lkemmons> Do you have source mods where these changes at least hacked in? — Reply to this email directly, view it on GitHub <#3065 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH5BH7O35PL5WSQHCXEHVID2ZWANJAVCNFSM6AAAAAB24YUFXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBXGY2TENZWHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[fvitt]

No, sorry, I have not implemented a namelist option.

I was referring to changes to the code for "the soil moisture (drought) impact on MEGAN emissions" and "overall scaling factor to the new gamma_sm calculation"

[lkemmons]

The new code for gamma_sm is already in. We want to include the option to have that be =1, or use the new calculation. An overall scale factor would also have to be added.

…

On Tue, Apr 15, 2025 at 4:36 PM Francis Vitt ***@***.***> wrote: No, sorry, I have not implemented a namelist option. I was referring to changes to the code for "the soil moisture (drought) impact on MEGAN emissions" and "overall scaling factor to the new gamma_sm calculation" — Reply to this email directly, view it on GitHub <#3065 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH5BH7LRAZV5NEQU24RKKWD2ZWCWXAVCNFSM6AAAAAB24YUFXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBXGY4DIMZYGA> . You are receiving this because you were mentioned.Message ID: ***@***.***> *fvitt* left a comment (ESCOMP/CTSM#3065) <#3065 (comment)> No, sorry, I have not implemented a namelist option. I was referring to changes to the code for "the soil moisture (drought) impact on MEGAN emissions" and "overall scaling factor to the new gamma_sm calculation" — Reply to this email directly, view it on GitHub <#3065 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH5BH7LRAZV5NEQU24RKKWD2ZWCWXAVCNFSM6AAAAAB24YUFXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBXGY4DIMZYGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[wwieder]

As @HuiWangWanderInGitHub noted in #3016 around line 568 in clm/src/biogeochem/VOCEmissionMod.F90

if (use_megan_gamma_sm = true):
    gamma_sm = get_gamma_SM(btran(p)) 
else:
   gamma_sm = 1.0_r8.

where use_megan_gamma_sm is a namelist parameter.

I'm less confident in how to apply the idea of gamma_sm_scale_factor, but suggest this could be handled in the get_gamma_SM subroutine? Maybe @HuiWangWanderInGitHub or @rosiealice has an idea here? Simple ideas are below:

• blue = default parameterization for gamma_sm
• orange = add a min. value to gamma_sm (here 0.6 for example).
• green = modify the parameter values some other way, (here with btran_threshold) con: this changes the shape of the function.

If we add a modifier into gamma_sm I suggest it go on the CLM parameter file.

my hacky python code for this example is below:

# Default parameterization
a1 = -7.4463
b1 = 3.2552
btran_threshold = 0.2
btran_in = np.arange(0, 1.01, 0.01)
get_gamma_SM = 1. / (1. + b1**(a1 * (btran_in - btran_threshold)))
plt.plot(btran_in, get_gamma_SM, label='btran_threshold = 0.2')

# add a min value, keep function the same
get_gamma_SM = np.where(get_gamma_SM>0.6,get_gamma_SM,0.6)
plt.plot(btran_in, get_gamma_SM, label='gamma_SM min = 0.6')

# modify the function, here with btran_threshold = 0.1
btran_threshold = 0.1
get_gamma_SM = 1. / (1. + b1**(a1 * (btran_in - btran_threshold)))
plt.plot(btran_in, get_gamma_SM, label = 'btran_threshold = 0.1')
plt.xlabel('soil moisture (btran)')
plt.ylabel('gamma SM')
plt.legend()

Hope this helps.

[wwieder]

I guess if we like the used of min_megan_gamma_sm (orange line above) this could be the single namelist change that goes into the get_gamma_SM function, where min_megan_gamm_sm = 1 effectively shuts off gamma_sm and no changes to the paramter file needs to occur? e.g.

get_gamma_SM = max(get_gamma_SM, min_megan_gamma_sm)

[HuiWangWanderInGitHub]

@wwieder Thanks for putting this together! I think the idea of using a lower threshold makes more sense to me since it simply postpones the impact of drought on isoprene by increasing the drought severity threshold. Besides that, I think adding a namelist option to turn off the drought impact could be helpful if drought conditions are not of interest in users' simulations. "min_megan_gamma_sm" is also an interesting idea, but it doesn't seem scientifically reasonable because isoprene emissions would shut down under severe drought conditions.

[fvitt]

In sandbox:

/glade/work/fvitt/cesm/cesm3_0_alpha06e_megan_fix

I have implemented these namelist options:

+  <entry id="megan_use_gamma_sm"
+        type="logical"
+        category="drv_physics"
+        group="megan_emis_nl" >
+      If TRUE, activity factor for soil moisture of isoprene is used in MEGAN emissions.
+  </entry>
+
+  <entry id="megan_min_gamma_sm"
+        type="real"
+        category="drv_physics"
+        group="megan_emis_nl" >
+       Minimum activity factor for soil moisture of isoprene is used in MEGAN emissions.
+  </entry>

Do we want to keep the megan_use_gamma_sm option? As pointed out by @wwieder , megan_use_gamma_sm = 1.0, effectively turns off SM gamma factor.

These options can be set in user_nl_clm.

Perhaps, @lkemmons or @tilmes can test these changes.

[wwieder]

I think my preference would be to just use megan_min_gamma_sm and drop the redundant megan_use_gamma_sm.

I think that was your question, Francis?
What do others think?

[ekluzek]

@fvitt we'd like to do this in small steps. So we'll bring this in as is. But, then there will be a follow on PR that includes the namelist changes verified as a bit-for-bit, and a final change that changes the namelist defaults.

So we end up with 2 tags. This isolates the b4b part and ensures that it doesn't change answers. And isolates the answer changing parts to small changes that can be easily examined.

1. Bring this one as is as an answer changing tag -- Erik will do this
2. Create a PR that adds the namelist variable changes
3. We'll run a baseline at this point to verify that answers are identical
4. An answer changing commit that just changes namelist options to what we want in the end
5. Erik then runs testing baselines and brings that PR to master

Does this all make sense? We should probably chat about this a bit.

By, doing "1" now we get the most important part ASAP.

[ekluzek]

OK, it's passing testing as expected in aux_clm on both Derecho and Izumi, with answers identical. So I'll now try some testing with updated megan namelists where we'll expect answers to change.

[ekluzek]

OK, the puzzles are all solved now. From two tests one Derecho and one on Izumi I now see differences in VOC's for one of the VOC fields in the cpl log file:

60BgcCrop.izumi_nag.clm-cropMonthOutput--clm-RxCropCalsAdaptGGCMI.GC.ctsm5341megcime6167izlist.cpl.hi.1850-03-07-00000.nc.cprnc.out
 RMS lndImp_Fall_voc15                1.1684E-09            NORMALIZED  2.7804E+00

[ekluzek]

In the CTSM SE meeting we decided we would update cmeps and cime and revert the st_archive change. And this will go into b4b-dev as well.

[ekluzek]

OK, with the updated cime, I'm having some tests hanging on Derecho, and mpi-serial tests fail to build on Izumi. I think this probably means to get things to work, we'd need to update ccs_config as well. But, there is an answer changing tag in ccs_config, so I don't want to bring that in right now.

I think the solution is to go back to the earlier version of cime that I saw working, and bring that on master. And they'll be separate work on b4b-dev and master to bring in other submodule updates.

Here are the tests hanging and failing to build...

ERS_D_Ld5_Mmpi-serial.1x1_mexicocityMEX.I1PtClm60SpRs.derecho_gnu.clm-CLM1PTStartDate		
ERS_D_Ld7_Mmpi-serial.1x1_smallvilleIA.IHistClm50BgcCropRs.derecho_intel.clm-decStart1851_noinitial		
ERS_D_Mmpi-serial_Ld5.5x5_amazon.I2000Clm50FatesRs.derecho_gnu.clm-FatesCold		
ERS_D_Mmpi-serial_Ld5.5x5_amazon.I2000Clm60FatesRs.derecho_intel.clm-FatesCold		
ERS_Ld1640_Mmpi-serial.1x1_numaIA.I2000Clm50BgcCrop.derecho_intel.clm-ciso_monthly_matrixcn_spinup		
ERS_Ld600_Mmpi-serial.1x1_smallvilleIA.I1850Clm50BgcCrop.derecho_gnu.clm-cropMonthlyNoinitial		
ERS_Ly5_Mmpi-serial.1x1_smallvilleIA.I1850Clm50BgcCrop.derecho_gnu.clm-ciso_monthly		
ERS_Ly5_Mmpi-serial.1x1_smallvilleIA.I1850Clm50BgcCrop.derecho_gnu.clm-ciso_monthly--clm-matrixcnOn		
SMS_D.1x1_brazil.I1850Clm60BgcCrop.derecho_gnu.clm-mimics_matrixcn		
SMS_D.1x1_brazil.I2000Clm60FatesSpCruRsGs.derecho_gnu.clm-FatesColdDryDepSatPhen		
SMS_D.1x1_brazil.I2000Clm60FatesSpCruRsGs.derecho_gnu.clm-FatesColdMeganSatPhen		
SMS_D_Mmpi-serial_Ld5.5x5_amazon.I2000Clm60Bgc.derecho_gnu.clm-HillslopeC		
SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Bgc.derecho_gnu.clm-NEON-MOAB--clm-PRISM		EXPECTED (SHAREDLIB_BUILD RUN)
SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Bgc.derecho_gnu.clm-default--clm-NEON-HARV		EXPECTED (SHAREDLIB_BUILD)
SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Bgc.derecho_gnu.clm-default--clm-NEON-HARV--clm-matrixcnOn		
SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Fates.derecho_gnu.clm-FatesPRISM--clm-NEON-FATES-YELL		EXPECTED (SHAREDLIB_BUILD RUN)
SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Fates.derecho_intel.clm-FatesFireLightningPopDens--clm-NEON-FATES-NIWO		EXPECTED (SHAREDLIB_BUILD RUN)
SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60SpRs.derecho_intel.clm-default--clm-NEON-TOOL		
SMS_Ld12_Mmpi-serial.1x1_vancouverCAN.I1PtClm60SpRs.derecho_gnu.clm-output_sp_highfreq		
SMS_Ld5_Mmpi-serial.1x1_brazil.IHistClm60Bgc.derecho_gnu.clm-mimics		
SMS_Ly1_Mmpi-serial.1x1_brazil.IHistClm60BgcQianRs.derecho_intel.clm-output_bgc_highfreq		
SMS_Ly5_Mmpi-serial.1x1_smallvilleIA.IHistClm60BgcCropQianRs.derecho_gnu.clm-gregorian_cropMonthOutput
ERS_D_Ld5_Mmpi-serial.1x1_vancouverCAN.I1PtClm50SpRs.izumi_nag.clm-CLM1PTStartDate	(SHAREDLIB_BUILD NLCOMP)		
ERS_D_Mmpi-serial_Ld5.1x1_brazil.I2000Clm50FatesRs.izumi_nag.clm-FatesCold	(SHAREDLIB_BUILD NLCOMP)		
SMS_D_Ld1_Mmpi-serial.f45_f45_mg37.I2000Clm50SpRs.izumi_nag.clm-ptsRLA	(SHAREDLIB_BUILD NLCOMP)		
SMS_D_Mmpi-serial_Ld5.5x5_amazon.I2000Clm60FatesCrujraRs.izumi_nag.clm-FatesCold	(SHAREDLIB_BUILD NLCOMP)		
SMS_D_Mmpi-serial_Ld5.5x5_amazon.I2000Clm60FatesRs.izumi_nag.clm-FatesCold	(SHAREDLIB_BUILD NLCOMP)		
SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Bgc.izumi_nag.clm-NEON-MOAB--clm-PRISM	(SHAREDLIB_BUILD NLCOMP)		EXPECTED (SHAREDLIB_BUILD RUN)
SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Bgc.izumi_nag.clm-default--clm-NEON-HARV	(SHAREDLIB_BUILD NLCOMP)		EXPECTED (RUN)
SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Bgc.izumi_nag.clm-default--clm-NEON-HARV--clm-matrixcnOn	(SHAREDLIB_BUILD NLCOMP)		EXPECTED (RUN)
SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Fates.izumi_nag.clm-FatesFireLightningPopDens--clm-NEON-FATES-NIWO	(SHAREDLIB_BUILD NLCOMP)		EXPECTED (SHAREDLIB_BUILD RUN)
SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Fates.izumi_nag.clm-FatesPRISM--clm-NEON-FATES-YELL	(SHAREDLIB_BUILD NLCOMP)		EXPECTED (SHAREDLIB_BUILD RUN)
SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60SpRs.izumi_nag.clm-default--clm-NEON-TOOL	(SHAREDLIB_BUILD NLCOMP)

[ekluzek]

OK, dependency issue came in. The CMEPS tag that includes the MEGAN change, also brought in st_archiver changes that don't work without the updated cime tag.

So I'm going to do some testing outside this branch to find out what submodules work together and don't. And will bring in some other PR's to either b4b-dev, or master (that I likely will merge in with this one) so I can figure out steps of what all works together.

[wwieder]

Hey @ekluzek, I'm wondering where we are on the timing of merging this PR?

[ekluzek]

Hey @ekluzek, I'm wondering where we are on the timing of merging this PR?

In the post above I talk about dependency issues and abstractly talk about some steps in other PR's. At this point the steps are well defined and progress has been made.

These are the things I'm viewing as requirements to bring this in:

• Fix the st_archive issue (I'm concerned that it won't work for productive sims) st_archive issues in ctsm5.3.041 with our testing #3098
• Update to the latest submodules (required because of the CMEPS update)
• Updating submodules probably means refixing the st_archive issue
• Submodule update means fixing the derecho_gnu mpi-serial DEBUG issue
• Submodule update means derecho_intel changes answers, test to make sure that's the only change in answers

So these are the steps I'm working on:

1. Fix the st_archive problem on b4b-dev
2. Update submodules on b4b-dev to just before the answer changing one
3. Figure out the derecho_gnu issue
4. Make a PR fixing the derecho_gnu issue and bringing in the answer changing ccs_config update Bring in the answer changing (for derecho_intel) ccs_config update #3111
5. PR to ccs_config to fix the derecho_gnu issue
6. Have Jim merge and tag 5
7. Make a PR to show that starting from 3 and bringing in submodule updates to beta06 work and is b4b to 3 (refix the st_archive issue here) (also uses the ccs_config in 6)
8. Bring in this PR using submodules proven in step 7