search

DOI-USGS / streamMetabolizer

streamMetabolizer uses inverse modeling to estimate aquatic metabolism (photosynthesis and respiration) from time series data on dissolved oxygen, water temperature, depth, and light.
http://usgs-r.github.io/streamMetabolizer/
Other
37 stars 22 forks source link

revisit Kmodel structural options #208

Open aappling-usgs opened 8 years ago

aappling-usgs commented 8 years ago

Some macrophyte-influenced sites may need a seasonality*discharge term, and some large rivers could possibly need a wind speed term. This raises the question of whether this whole regression can look more like a standard R lm() rather than having prepackaged formulas and transforms.

And then comes the question of whether Bayesian models with K constraints can be similarly flexible, or at least more flexible than they currently are.

aappling-usgs commented 8 years ago

would also be nice if Kmodel were mostly parallel to linear/binned/etc. options for K pooling in Bayesian models

aappling-usgs commented 8 years ago

does get_params() make sense in Kmodel as a way of extracting predicted K600.daily values? predict_K600() would be a little more accurate. and a user might reasonably try get_params() hoping to see the daily K600 input data - that's what you do with an MLE or sim model with fixed K as an input. but i'd rather not introduce a new function unless it's absolutely necessary...hmm.

would also be nice to be able to get the params like mean, intercept and slope, etc. from the regression, etc. models. get_params(..., resolution='overall') could make sense for that. the 'overall' argument would then be appropriate for both the Kmodel and the hierarchical Bayesian models.

aappling-usgs commented 8 years ago

been chewing on it. I think get_params() does make sense if you're willing to think about get_params() as 'get me the usually-daily parameters that the model thinks are the best available parameters to use for predicting metabolism and DO'. the advantage of using the same function here as for other models is that it will probably be intuitive to want to retrieve and plot the output of get_params() for more or less the same reasons for Kmodel and other model types - to see what patterns the model comes up with for daily parameters.

if the user wants the input values of K600, they should use get_data_daily.

get_params(..., resolution='overall') is still a nice idea for down the road.

aappling-usgs commented 7 years ago

related to #289 (plots for hierarchical K fits) and #241 (extract binning & cutting code out of metab_bayes) and #239 (expand get_params to allow non-daily for hierarchical models)