Problems estimating GPP and ER in artifical, non-mixing containers #378
Comments
|
Hi Moritz,
consecutive days don't matter, but when you model a greater total number of days at once, that can improve the model's estimation of the distribution of K600 values, error magnitudes, and other parameters. If you expect that K600 is varying over time in these tanks (due to changing wind speeds, or periods when macrophytes greatly reduce circulation, maybe?), you might want to use a pooling approach other than Kn, which assumes there is some fixed distribution that applies to all time. I think the piecewise-linear approach (Kb) could be adapted to relate K to some other parameter such as mean daily wind speed, plant biomass, or even date if desired.
I know you've found that effect, and it continues to impress and surprise me, though I can't yet explain it. streamMetabolizer does not support different values of day_start and day_end on different days within the same model. One solution would be to run a different model for each unique set of values of day_start and day_end that you want to use. Another might be to change the solar.time stamps on your data, falsifying them so that the 24-hour windows you actually want always have the same series of time labels. streamMetabolizer only uses the solar.time column to identify the chunk of data appropriate to each date, so you wouldn't be messing up the modeling by doing this.
For an inverse approach alone to be able to tease apart ER and bubbles, we'd need some information on how the temporal patterns in those two variables differed - and they would need to differ enough for the model to be able to distinguish them. However, you might be able to use field measurements to trap bubbles and estimate their abundance and contribution, after which you could simply subtract that contribution from the "ER" estimated by the model if it's safe to assume that both processes are reasonably constant over each 24-hour period.
Yes, I think the model can probably provide accurate GPP estimates even when the ER estimates are contaminated, as long as the contamination (bubbles in this case) is constant throughout the day and night. |
I actually would not expect K600 to vary all that much. it has been shown that the ponds are relatively stratified, with only very little mixing from wind etc.. maybe there is a way to completely fix k600?
yes, that's what I thought as well. I will try with different windows sizes and compare the results. what do you think a sensible minimum window-size would be - something like 3 days?
here I would simply align a solar.time stamp with the sunrise and make that estimating bubble dynamics won't work for this data set, we don't have the capacity to do that at the moment. but I think this is a really important point for future work using ecosystems in tank: in all experiments I have done so far there was pronounced supersaturation that led to weird patterns |
We designed the Bayesian models with a strong focus on supporting estimation rather than fixing of K. But you can get pretty close by using the Kn0 specification (pool_K600='normal_sdzero'), like so:
Sure, if you want the start and end times to drift slowly over time, a moving window of 3 consecutive days at a time sounds like a fine thing to try. There's no particular need to make them be consecutive days except to the extent that those three days are likely to have similar magnitudes of errors and metabolism.
I think we're talking about the same thing, yes. For a very simple example, suppose you have observations on the hour every hour, and you want day 1 to run from 4 am to 4 am, day 2 to run from 5 am to 5am, and day 3 to run from 6 am to 6 am. You could use day_start = 4, day_end=28, and then adjust the solar times as follows: library(tidyverse)
day_start = 4
day_end = 28
dat <-
tibble(
obs.id = 1:75,
true.solar.time = seq(as.POSIXct('2019-02-12 04:00'), as.POSIXct('2019-02-15 06:00'), by=as.difftime(1, units='hours')),
date.id = c(rep(1, 24), NA, rep(2, 24), NA, rep(3, 25))) %>%
filter(!is.na(date.id)) %>%
group_by(date.id) %>%
mutate(new.solar.time = as.POSIXct('2019-02-11 00:00') +
as.difftime(date.id*24 + seq(day_start, by=1, length.out=n()), units='hours')) %>%
ungroup() %>%
mutate(date.id = factor(date.id))
attr(dat$true.solar.time, 'tzone') <- NULL
dat %>%
gather(time.type, solar.time, true.solar.time, new.solar.time) %>%
ggplot(aes(x=obs.id, y=solar.time, color=time.type, shape=date.id)) +
geom_point() +
theme_bw()
Thus, the timestamps on day 2 are moved back by 1 hour, and the timestamps on day 3 are moved back by 2 hours.
👍 |
Dear Allison and Bob,
last year I asked you for some help regarding estimating metabolism in replicated cattle tank [1000l] ecosystems (#367). With your help I was able to resolve most of the problems I had with these short timeseries.
However, I have just started to work on data from bigger ponds [15000l], where the timeseries are considerably longer (150-200 days), but with similar data structure (15 min resolution, measurements of O2 concentration and saturation, temperature and light).
As last time, I have smoothed my data (temp, O2, and light with a loess smoother, 1 day window size), but I am running similar issues as last time: positive ER estimates and "chopped off peaks" in the DO predictions (see plots below). Looking at the DO predictions, the results are not terrible, but I really don't get the positive ER estimates. So, there are some specific questions I have:
day_startandday_endI specify will differ for a lot of my days. why is this parameter so important (has a big effect on the model estimates), and, is there a way to specify it dynamically (or chop up the timeseries)?do you think there is a way to calculate this gas transfer from my data?
Below is my model output, and the plotted metabolism estimates. I realize that this is a pretty specific problem, and not a bug or generalizeable issue and you probably cannot spend a lot of time on it. Any thoughts are highly appreciated - thanks for your help!
mod.data.1.txt
The text was updated successfully, but these errors were encountered: