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

g->pr does not reflect "extra" resources #329

Closed
kpalmqui opened this issue Jun 26, 2019 · 3 comments
Closed

g->pr does not reflect "extra" resources #329

kpalmqui opened this issue Jun 26, 2019 · 3 comments
Assignees
Milestone

Comments

@kpalmqui
Copy link
Member

g->pr is a parameter calculated at the functional group level in rgroup_PartResources that reflects whether a functional group is resource limited or not:

/* Calculate PR at the functional group level: resources required/resources available */
        g->pr = ZRO(g->res_avail) ? 0. : g->res_required / g->res_avail;

Values > 1 indicate resource limitation for the functional group. It is then utilized within the mortality due to resource limitation implementation:


/* kill plants if low resources for consecutive years */
    /* increment yrs_neg_pr if pr > 1, else zero it. */
    /* one good year cancels all previous bad years. */
    if ( GT(g->pr, 1.0) ) {
       if (++g->yrs_neg_pr >= g->max_stretch)
          _no_resources( rg);

    } else {
      g->yrs_neg_pr = 0;
    }

g->pr is set every year based on "normal" resource partitioning - i.e. how much each functional group receives based on root-water matching and space. However, it does not reflect additional "extra" resources that a functional group receives if there are remaining resources left over after "normal" resource partitioning (see _res_part_extra and rgroup_ResPartIndiv). Thus, this could occasionally potentially kill individuals within a functional group that is not resource limited.

Simple solution:

  1. incorporate g->res_extra into g->res_avail and then re-calculate g->pr
  2. move the calculation of g->pr from line 103 of ST_resgroups.c to line 149 of ST_mortality.c right before the parameter is used (this is the only place it is actually used and there is no need to calculate it twice unnecessarily)
@kpalmqui kpalmqui added this to the feature_space milestone Jun 26, 2019
@kpalmqui kpalmqui self-assigned this Jun 26, 2019
@kpalmqui
Copy link
Member Author

I did some testing with the above solution implemented and made some comparison figures to the old implementation. I did this for one site with specific climate and climate-specific space parameters.

This issue does impact mortality, particularly for sagebrush. With the fix implemented, fewer individuals are killed when they are young and more individuals approach their maximum age before killing.

Figures here (1ter and 100 iters results shown, old = black, new = yellow):

Site868.mort.sagebrush.pcoolgrass.pdf
Site868.mort.pwarmgrass.pforb.pdf

The outcome is increases in big sagebrush biomass and density. Impacts on perennial grasses and perennial forbs is minimal.

Figures here (1ter and 100 iters results shown on each panel, old = black, new = blue):
SIte868.sagebrush.pcoolgrass.pdf
Site868.pwarmgrass.pforb.pdf

@dschlaep

kpalmqui added a commit that referenced this issue Jun 27, 2019
This commit:
-updates res_avail to include res_extra
-moves the calculation of g->pr to right before it is used and after res_extra is determined.
@dschlaep
Copy link
Member

That looks very promising! The old sagebrush individuals are getting heavier too.

@kpalmqui
Copy link
Member Author

kpalmqui commented Jul 8, 2019

resolved by f9264f3

@kpalmqui kpalmqui closed this as completed Jul 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants