streamMetabolizer icon indicating copy to clipboard operation
streamMetabolizer copied to clipboard

adjustments for gpp process error

Open aappling-usgs opened this issue 7 years ago • 2 comments

Based on discussion and tests of #376, I now have these tasks:

  • [x] rename "daytime process error" (pd) to "GPP process error" (pp) -> done
  • [x] disallow the intersection between light saturation (ps) and daytime process error (pp) -> done
  • [x] re-adopt the code that normalizes the GPP multiplier so that we will have GPP_daily == sum(GPP_inst) (see below) -> done
  • [x] get info from Charles on what variables are needed to be able to compute multivariate R2; make sure those variables are contained in the Stan code. "in stan all we have to keep track of is the coef_GPP estimates. Outside of stan, we can then calculate the variance in coef_GPP's for each day, during daylight hours (call that var_y) and the variance in difference between coef_GPP's and frac_GPP (again only during daylight hours - all this var_res) and we can then calculate a pseudo-R2 as 1-var_res/var_y. If frac_GPP is just a bunch of 1's and 0's this will yield an R2 of 0, and if light measurements explain most of the gpp patterns this should approach 1." -> note that what used to be frac_GPP is now named light_mult_GPP, and what used to be coef_GPP is now named pp_mult_GPP...but if nobody minds, I'll leave it out, because we can calculate the same daily pseudo R2s from GPP_inst_partial and GPP_inst as 1 - var(GPP_inst - GPP_inst_partial) / var(GPP_inst) instead. The values are different if you try to compute some global, multi-day pseudo r2, but we wouldn't do that, would we? And if we did, wouldn't we prefer the GPP_inst version anyway?
  • [x] decide how to name the error-adjusted and GPP_daily-only estimates of instantaneous GPP. Possibilities include GPP_adj and GPP_inst, respectively; or GPP_inst and GPP_pure, respectively. make both available in Stan and consider putting the adjusted version into default params_out -> decided to name the corrected GPP inst "GPP_inst" and the uncorrected version "GPP_inst_partial"; this naming scheme is parallel to dDOdt preds after and before process error correction
  • [x] double-check that GPP_daily == mean(GPP_inst) == mean(GPP_inst_partial) == GPP. This should be the case, but make sure. -> The first two equalities are true. There are small differences between the first three and GPP_mean, probably due to the difference between taking the median of hundreds of sums vs taking the sum of a bunch of medians. But we're talking <1% for the scenarios I've tested, and this difference exists for GPP and ER in any Bayesian model, so it's nothing new.
  • [x] make it so plot_distribs can handle the GPP process error multiplier distribution -> done

~~- [ ] adjust plot_DO_preds to do better than DO.pure for this and other process-error models?~~ -> see #294 . I'll do this someday.

code to re-adopt:

  for(i in 1:(n-1)) {
     mult_coef_GPP[i] = mult_GPP[i] .* frac_GPP[i]; 
     }
  mult_coef_GPP[n] = frac_GPP[n];
  for(j in 1:d) {
    mult_sum_coef_GPP[j] = sum(mult_coef_GPP[1:n,j])/n;
    }
  for(i in 1:n) {
    coef_GPP[i] = mult_coef_GPP[i] ./ mult_sum_coef_GPP[1:d];
    GPP_inst[i] = GPP_daily .* coef_GPP[i];

aappling-usgs avatar Nov 01 '18 22:11 aappling-usgs

Summary of the renaming I just did:

  • frac_GPP is now light_mult_GPP
  • frac_ER is now const_mult_ER
  • ~~coef_GPP is now pp_mult_GPP~~ it was briefly, but now it doesn't have its own Stan variable; see notes above about pseudo R2s
  • GPP_inst is the process-error-corrected instantaneous GPP for GPP process error models (pp)
  • GPP_inst_partial is the instantaneous GPP based on light only, again for pp models. For other linlight models, GPP_inst is the instantaneous GPP based on light only
  • the GPP process error models are mm_name('bayes', err_proc_GPP=TRUE) (and you may also want err_proc_iid=FALSE) and is pp in the shorthand model name, e.g., b_np_oipp_tr_plrckm.stan

aappling-usgs avatar Nov 19 '18 03:11 aappling-usgs

All this code is in #376 , which resolves this issue unless we notice something amiss in the next few days.

aappling-usgs avatar Nov 19 '18 04:11 aappling-usgs