Grazing

[ckoven]

An initial implementation to allow herbivores to graze and browse plants, with different grazing rates on different land use classes.

Description:

This PR adds the basic capability to have grazers and browsers eat plants. The basic idea is to specify this as a rate of consumption in units of 1/time. I.e. grazers and browsers eat X% of all accessible leaves of edible plants per day on columns of land-use type Y, as controlled by the parameter fates_landuse_grazing_rate(fates_landuseclass). The specification of what is considered edible plants is parametric and controlled by a PFT-level trait fates_landuse_grazing_palatability(fates_pft), so e.g. this can be specified to include grazers (who eat herbaceous plants only) and/or browsers (who eat the leaves of woody plants). And then all leaves of that PFT on columns of that land use type that are below a height of parameter fates_landuse_grazing_maxheight can be subject to herbivory.

The fate of the eaten material is controlled by three "use-efficiency" parameters: fates_landuse_grazing_carbon_use_eff', fates_landuse_grazing_nitrogen_use_eff, 'fates_landuse_grazing_phosphorus_use_eff'. So some mass can be lost from the ecosystem and some can be added to the litter pools via manure (and, I suppose, mortality of grazers).

Default parameter values that are there now (all of which extremely subject to change) are to make this only apply on pasture and rangeland, with a rate of 4% per day based on https://doi.org/10.5194/gmd-11-815-2018 by @samsrabin et al., and currently only grazers (i.e. only applies to nonwoody PFTs). I couldn't find a whole lot of data on the use-efficiency parameters, but those shouldn't be too important until we are running nutrient cycles at large scale under transient change.

fixes #936

Collaborators:

Expectation of Answer Changes:

This will be answer changing if the parameters are set to allow grazing.

Checklist

If this is your first time contributing, please read the CONTRIBUTING document.

All checklist items must be checked to enable merging this pull request:

Contributor

• The in-code documentation has been updated with descriptive comments
• The documentation has been assessed to determine if updates are necessary

Integrator

• FATES PASS/FAIL regression tests were run
• Evaluation of test results for answer changes was performed and results provided

Documentation

• Technical Note update:
• User's Guide update:

Test Results:

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

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

FATES baseline hash-tag:

Test Output:

[samsrabin]

Not sure if this was actually ready for review, as it has the "draft" tag but isn't a Draft in the Github sense. Anyway, I've made some (initial?) comments. Also: Where are the new parameters actually read?

[samsrabin]

I'm guessing herbivory_flux_out is actually sent to the atmosphere by the HLM, right?

[samsrabin]

In fact it looks identical, aside from herbivory replacing burned. Could these be replaced with a single function? Named, e.g., GetDisturbed.

[samsrabin]

consumed_mass should presumably be herbivore_consumed_mass?

[ckoven]

Not sure if this was actually ready for review, as it has the "draft" tag but isn't a Draft in the Github sense. Anyway, I've made some (initial?) comments. Also: Where are the new parameters actually read?

Thanks @samsrabin! Yes, this is draft in the sense that it wasn't done or tested. And yes, one of the things that isn't done yet is the code to actually read the new parameters. But better to get eyes on it sooner rather than later.

[rgknox]

We need to bump this value up to something bigger, we are hitting our limit on maximum parameters already:

https://github.com/NGEET/fates/blob/main/main/FatesParametersInterface.F90#L12

Maybe 400?