calculated variables

[wwieder]

From our call today let's go ahead and provide standardized calculations for common results we'd like to see in the tarball.
When these are already provided in the database let's use the orig. value, We need to avoid dividing by zeros but otherwise they can be calculated like this:

• [ ] lyr_c_to_n_calc = lyr_soc / lyr_n
• [ ] layer_mid_calc = (layer_bot + layer_top) / 2
• [ ] layer_thick_calc = layer_bot - layer_top
• [ ] lyr_soc_stock_calc = lyr_soc bd_samp layer_thick
• [ ] lyr_n_tot_stock_calc = lyr_n_tot bd_samp layer_thick
• [ ] lit_cn_calc = lit_c / lit_n
• [ ] bgb_cn_calc = bgb_c / bgb_n
• [ ] wood_lit_cn_calc = wood_lit_c / wood_lit_n These are duplicated because of the different ways you can report raw values, but all are uncommon and may not even be worth reporting?
• [ ] mb_cn_calc = mbc_raw / mbn_raw
• [ ] mb_cn_calc = mbc_raw_trans / mbn_raw_trans
• [ ] mb_cp_calc = mbc_raw / mbp_raw
• [ ] mb_cp_calc = mbc_raw_trans / mbp_raw_trans
• [ ] mb_np_calc = mbn_raw / mbp_raw
• [ ] mb_np_calc = mbn_raw_trans / mbp_raw_trans

Can you think of others?

[wwieder]

connected to https://github.com/lter/lterwg-som/issues/61

[srearl]

Will - I addressed some of these in an updated tarball (2019-09-28) but note that I uploaded it to the project directory but not yet to Shiny as i wanted to check with you on these first. Per your email, instead of creating new variables with _calc, I simply updated the existing variable as appropriate (e.g. missing lyr_c_to_n values were updated from lyr_soc / lyr_n if available & if lyr_c_to_n was not provided by the data provider). Of course this means that the user will not know if the CN value is derived. The exception to this is layer_thick_calc - here I did calculate a new variable since there is not already a variable pertaining to thickness. Please verify what we want to do with soc and soc_stock, these are a bit confusing so want to be sure that I get those correct.

tarball: https://drive.google.com/open?id=1rnmePE5YQdFKTr22fsBSSN2ng06MiKHa

tarball edits: https://github.com/lter/lterwg-som/blob/master/data-aggregation/harvest_HMGZD_local.R#L168

• lyr_c_to_n_calc = lyr_soc / lyr_n
  • included derived values where lyr_c_to_n not present
  • existing lyr_c_to_n updated, new var with _calc not created
• layer_mid_calc = (layer_bot + layer_top) / 2
  • included derived values where layer_mid not present
  • existing layer_mid updated, new var with _calc not created
• layer_thick_calc = layer_bot - layer_top
  • calculated as layer_thick_calc since this is a new var
  • seems that the meaning of top and bottom are reversed in some data sets so I used the absolute of the derived value to account for negative values
• lyr_soc_stock_calc = lyr_soc bd_samp layer_thick
  • nothing done here, want to verify soc vs soc_stock
• lyr_n_tot_stock_calc = lyr_n_tot bd_samp layer_thick
  • nothing done here
• lit_cn_calc = lit_c / lit_n
  • included derived values where lit_cn not present
  • existing lit_cn updated, new var with _calc not created
• bgb_cn_calc = bgb_c / bgb_n
  • included derived values where bgb_cn not present
  • existing bgb_cn updated, new var with _calc not created
• wood_lit_cn_calc = wood_lit_c / wood_lit_n
  • not enough data to make this calculation

cc @piersond

[wwieder]

Thanks for getting started on this @srearl! I'm not really clear what the confusing is here on soc vs. soc_stock? Are some of these data not necessarily provided as expected? The calculation should be done as in the R script I provided soc_stock = lyr_soc thickness lyr_bd * 100 (to go from %C to g/m2, our target units?). Given the complications & potential for confusion, however, I wonder if we should provide the new _stock_calc fields on this one?

Your note on layer_thick is a little confusing. There are some datasets that use -1 or -10 to indicate the top of organic horizons. This should be OK. If these the meaning of layer_top and _bottom are swapped in other datasets (and this is done consistently) it makes me wonder if we should correct values in the key-key, instead of using the abs value?

My last questions is if we can put the latest tarball up on the shiny server? I'm curious if we're ending up with calculated values that are are obviously not realistic (my guess is yes), but wonder if the information that these were calculated by us vs. provided in a dataset would make any difference in how users ultimately use the data in the tarball?

Lots here, I'll be in a little later this AM, but happy to talk if it's helpful. Will

[wwieder]

let's also calculate soil texture where only 2 of 3 variables are provided silt = 100-(clay+sand) clay = 100-(silt + sand) sand = 100-(clay + silt)

[srearl]

not much to calculate here, only a few values for silt but the calcs are now added so we will have them for future data