Dynamically scale phenology, biomass, litter, and percent live based on climate

[kpalmqui]

This issue will serve as a workflow for implementating dynamic scaling of phenology, biomass, litter and percent live for each site based on current or future temperatures. The intent here is to break each of these steps into smaller more managable issues.

Step 1. Create a new input csv file within the inputs folder of rSFSTEP2 to hold the the reference growing season to be used for all sites. Set default values to March-October.

Step 2. Within Vegetation.R, after _calc_SiteClimate is called (which extracts mean monthly temperatures for each site-climate scenario), call the rSOILWAT2 function adjBiom_by_temp to derive the "target" growing season for that site-climate scenario. Here, we need to pass in the mean monthly temperatures, along with the reference growing season defined in Step 1.

This function also scales whatever is passed into it (e.g. litter, biomass) based on the derived "target" growing season. Thus, to derive biomass, litter, and % live, we need to call this function once to derive new biomass, litter, and % live values (held in sxw_prod.in). Phenological activity values sum to 1.0 (held in sxw_phen.in), thus, as @dschlaep suggested below, we need to call the functionality contained within adjBiom_by_temp to get initial phenological activity values that reflect the target growing season and then make additional adjustments to ensure that the values sum to 1.0 across all months for each functional type.

Step 3. After the new values are dervived for the site-climate scenario in question, we need to write those values to new sxw_phen.in and sxw_prod.in files within STEPWAT_DIST. They need to be labeled with the proper unique identifiers. This is similiar to the workflow we have for the space parameter and rgroup.in file.

Step 4. Add code in CallSTEPWAT2.R to copy the relevant files to the appropriate place within STEPWAT2 before executing. This is similiar to the workflow we have for the space parameter and rgroup.in file.

[kpalmqui]

@chaukap @dschlaep A rough outline of the workflow. Take a look and let me know if I missed anything or made any mistakes.

@dschlaep a question for you - 1) Phenological activity values much sum to 1.0 for each functional type. Do we need to introduce additional code into adjBiom_by_temp to deal with this?

[dschlaep]

• I suggest that functionality to meet specific additional criteria, e.g., sum(x) is 1, is separate from the task of phenological adjustments carried out by adjBiom_by_temp, because such criteria apply to some but not every variable on which adjBiom_by_temp is called. I suggest that code to meet these criteria is implemented by the code that calls adjBiom_by_temp and not by adjBiom_by_temp itself (via additional function parameters).

• We may call adjBiom_by_temp multiple times for the different variables/tables if that makes the code flow more naturally. However, the x argument of adjBiom_by_temp handles vectors, 2-dimensional objects, or a list of such objects, i.e., we could call adjBiom_by_temp just once with, e.g., adjBiom_by_temp(x = list(sxw_phen, sxw_prod_biomass, sxw_prod_pctlive, sxw_prod_litter), ...): example to illustrate how adjBiom_by_temp works on a list of data.frames and vectors with different numbers of columns/variables:

sw_in <- rSOILWAT2::sw_exampleData # branch feature_biomassphenology
biomass_reference <- swProd_MonProd_grass(sw_in)[, 2:3]
biomass_adj <- adjBiom_by_temp(
    x = list(
        sxw_phen = biomass_reference, 
        sxw_prod_litter = biomass_reference[, 1],
        sxw_prod_biomass = cbind(biomass_reference, biomass_reference)),
    mean_monthly_temp_C = c(rep(10, 6), rep(0, 4), rep(10, 2)))

[kpalmqui]

@dschlaep thanks for the clarification on calling adjBiom_by_temp multiple times - I do now see how it will work for litter and biomass simulatenously, despite biomass being functional type specific and phenology not being functional type specific.

I will edit the workflow above to include your suggestions for phenology, which sums to 1.0. Many thanks!

[chaukap]

Since we are implementing this new code inside of Vegetation.R, and Vegetation.R is a function, I think we should add the default growing seasons as a parameter:

estimate_STEPWAT_relativeVegAbundance <- function(sw_weatherList, defaultGrowingSeason,
  site_latitude = 90)

That way we do not have to rely on any specific global variable to exist inside Main.R. Then, we could return the relative vegetation abundance and phenology as a single vector and process them in Main.R:

return_val <- c(relative_veg_abundance, phenology)

return_val

This wouldn't modify the workflow at all, it would just be good coding practice.

@kpalmqui Does this sound good?

[chaukap]

@kpalmqui I realized as I was programming step 2 that the tables we are trying to modify, sxwphen.in and sxwprod.in, are in a location that neither Main.R nor Vegetation.R know anything about. This means we either have to a) Supply the path to the sxw inputs to Vegetation.R, then read sxwphen.in and sxwprod.in inside Vegetation.R or b) Read sxwphen.in and sxwprod.in in Main.R and pass the derived information to Vegetation.R as parameters.

a) is the path of least resistance, so I'll start there. However, it will be extremely easy to switch to b) if we choose.

[kpalmqui]

@chaukap one concern I see with this implementation is that we would not have the option to scale phenology/biomass based on temperature but turn off scaling of space based on climate. This is because of the rescale_space flag. When set to T, it would always scale phenology/biomass and space. Correct me if I am wrong here.

What about adding a second function to Vegetation.R that could be called independently of whatever we are doing with space?

[kpalmqui]

@chaukap with regard to

b) Read sxwphen.in and sxwprod.in in Main.R and pass the derived information to Vegetation.R as parameters.

Do you mean create two input csv files to hold sxw_phen and sxw_prod? I'm not sure it would make sense to provide those tables as .in files and read them, as the rest of the inputs to rSFSTEP2 are in csv files. Thoughts?

[chaukap]

@kpalmqui It would make sense to provide them as CSV files. I was under the impression that we wanted to read the default sxwphen.in and sxwprod.in files from the testing.sagebrush.master/Stepwat_Inputs/Input/sxw folder and scale them, but it does make sense to add them as csv files so the user can change them more easily.

We could even make a single csv file called InputData_SXW.csv and populate it with the information from sxwprod.in, sxwphen.in, and the default growing season.

As to adding a function to Vegetation.R I like that idea as well. I'll open a new issue and get a start on it.

[kpalmqui]

@chaukap Sounds good. I agree that input csv files for sxw_phen.in and sxw_prod.in makes sense. I am fine with putting them all in the same input file - the only issue I see is that currently the litter values in sxw_prod.in are not functional type specific - we use the same values for each functional type. All of the other values are provided for each functional type. I guess we could just repeat those values for each functional type?

[chaukap]

@kpalmqui I'll do some experimenting with R and read.csv to see what it allows us to do. Worst case scenario we can of course repeat the values for all groups. Best case scenario we can define it once then replicate is as necessary in the program.

[chaukap]

@kpalmqui I believe that the main objective of this milestone is complete. We now generate the new files and swap them into STEPWAT for the corresponding climate scenario. If you get a chance could you confirm on your local machine? You can also take a look at the new phen and prod files which are stored in the DIST directory.

I still have to do some code clean up, like deleting variables once they are no longer necessary, but the phenology scaling feature should be ready to use.

[kpalmqui]

@chaukap @dschlaep I ran a set of test runs using our new dynamic scaling algorithm for 7 big sagebrush sites that do a pretty good job of representing the climate space of these ecosystems (cold,wet to warm,dry, high to low summer PPT).

The results for scaled phenological activity values for the most part look great. I notice a few small isues with phenological activity values for a.cool.grass (cheatgrass). For 2 of the 7 sites for some to most climate scenarios, the values often increased and decreased only to increase again in consecutive months.

This behavior is exhibited by sxwphen.hybrid-delta-3mod.d50yrs.RCP45.FGOALS-s2.in (red upside down triangle) and sxwphen.hybrid-delta-3mod.d50yrs.RCP45.FGOALS-g2.in (green diamond) for Site 876 (Colorado Plateau, warm site, MAT = 13.7 degrees C) shown here:

And also for Site 21 (Great Plains, MAT = 6.8 degrees C) for most climate scenarios shown here:

This only ever seemed to occur for a.cool.grasses. Could this be due to the default phenological activity values (shown in blue in the Figures)? Perhaps a slight adjustment upward for the month of April might help resolve this issue?

@dschlaep what do you think?

[kpalmqui]

This larger issue has been resolved by the subsequent smaller issues that were created on this branch/milestone. Thus, I am closing the issue.