Update fragmentation_scaler calculation to use HLM moisture and temperature

[glemieux]

Description:

This PR addresses #699 by pulling in the host land model moisture and temperature scalar inputs as boundary conditions for the fragmentation_scalar calculation.

This PR is coordinated with CTSM PR #1180

Collaborators:

@ckoven @jkshuman

Expectation of Answer Changes:

Yes answers are expected to change as there is difference between the HLM and FATES natively calculated temperature and moisture scalars. This will change the result of ag_cwd_frag, bg_cwd_frag, leaf_fines_frag, and root_fines_frag directly.

Checklist:

• My change requires a change to the documentation.
• I have updated the in-code documentation .AND. (the technical note .OR. the wiki) accordingly.
• I have read the CONTRIBUTING document.
• FATES PASS/FAIL regression tests were run
• If answers were expected to change, evaluation was performed and provided

Test Results:

CTSM (or) E3SM (specify which) test hash-tag:

CTSM (or) E3SM (specify which) baseline hash-tag:

FATES baseline hash-tag:

Test Output:
TBD

[glemieux]

@ckoven plot results of a quick 5-year f45 test compared using pyferret against the current fates baseline are found here: https://drive.google.com/drive/folders/1L88cfTQCj31VRnWyzxVekm4u-AB2qvxa?usp=sharing

[jkshuman]

@glemieux list of params to investigate with this change:
direct impact of these changes on: FRAGMENTATION_SCALER, SUM_FUEL
with longterm carry over impacts on: FIRE_FUEL_MEF, FIRE_FUEL_BULKD, FIRE_FUEL_EFF_MOIST, FIRE_FUEL_SAV, FIRE_INTENSITY

We can get extra information with a regional test. The default param values for max_decomp that interact with the changes you made are set from tropical references, so will be interesting to see global application. @ckoven has values for California. Hopefully this change will make it easier to use globally.

[glemieux]

@jkshuman @ckoven I've created a jupyter notebook to collect the output plots and just added the fire variable suggestions. The data include is based off of a 10 year long f45 gridded run: https://github.com/glemieux/fates-jupyter/blob/master/fragmentation/fragmentation_update-base_compare.ipynb

Please, let me know if there are particular plots that you want me to focus on for better viewing/detail.

[glemieux]

All expected tests passed b4b, with the exception of DIFFs on SUM_FUEL_BY_PATCH_AGE in the FatesAllVars and FatesPRT tests:

/glade/u/home/glemieux/scratch/clmed-tests/pr705.fates-sci.1.42.0_api.14.0.0-ctsm1.0.dev105-Cf6123355-F8dd2a2f3

Not sure why that variable isn't resulting in b4b yet...

[glemieux]

All expected tests passed b4b, with the exception of DIFFs on SUM_FUEL_BY_PATCH_AGE in the FatesAllVars and FatesPRT tests:

/glade/u/home/glemieux/scratch/clmed-tests/pr705.fates-sci.1.42.0_api.14.0.0-ctsm1.0.dev105-Cf6123355-F8dd2a2f3

Not sure why that variable isn't resulting in b4b yet...

I see why now: looking at the output with pyferret I was seeing a clear order of magnitude difference between this and sci.1.42.4_api.14.0.0 baseline I compared against. I forgot that my branch was created off of tag sci.1.42.0_api.14.0.0 which didn't include the unit error fix to this variable from 5072fe7 in PR #694.

[glemieux]

@ckoven @jkshuman 4x5 global run plots have been updated. This data should reflect the correct frag scalar calculation after Jackie found my typo: https://github.com/glemieux/fates-jupyter/blob/master/fragmentation/fragmentation_update-base_compare.ipynb

The data looks not a subtle as before, particularly in the above ground leaf fines. The increase seems pretty dramatic to me. The fuel moisture history variable change seems reasonable, yes? Particularly in the drop around the Sahara?

[rgknox]

Does E3SM provide the temperature and water scalars needed here? If not, or if we can't create that feature easily, we will need code logic in place to swap algorithms dependent on the HLM used.

Here is an example of where we evaluate which HLM we are using inside FATES:

https://github.com/NGEET/fates/blob/master/main/FatesInterfaceMod.F90#L1424

[ckoven]

@rgknox yes it does. We just need to make a modification analogous to the CTSM one but sending to FATES as input boundary conditions the t_scalar and w_scalars that are in this data type: https://github.com/E3SM-Project/E3SM/blob/master/components/elm/src/data_types/ColumnDataType.F90#L513-L514

[jkshuman]

@glemieux thank you for putting together the jupyter notebook with output. Things are very much related and connected throughout the fire routine, but the changes are in line with how they should respond. With the inclusion of the w_scaler we do get larger increases in overall fuels in places with more moisture, and that makes sense.

[jkshuman]

@glemieux was thinking about this last night, and added a few suggestions to hopefully anticipate user changes.

[rgknox]

looks good

[glemieux]

After a chat with @rgknox, I decided to run the fates test suite with use_hlm_soil_scalar = .true. to make sure the code didn't break the different test variations. DIFFs appears to be as expected:

/glade/u/home/glemieux/scratch/clmed-tests/basegen.fates-sci.1.43.0_api.14.1.0-ctsm1.0.dev105-Cf6123355-F19702e37