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
36 stars 22 forks source link

issue with get_units, new user #352

Closed akdodd closed 6 years ago

akdodd commented 7 years ago

Am I incorrect in only altering certain functions and not every single script? I have walked through all of the scripts in the package, and it did not seem that they all needed to be altered or even used, but my lack of experience leaves me ignorant here. The "getting started" vignette was helpful, and assisted me in figuring out which functions to start with in terms of customizing the code to my data, but I ran into problems with the data_metab function. I am told function "get_units" cannot be found. In the attached scripts, the function data_metab is renamed "mydatametab". I reran Bob's example data, which ran fine. I decided to go "back to the drawing board", so to speak, and save my example data under the name you used for Bob's data, "french" (I, of course, renamed Bob's example data). I did not even alter the code to fit this data at all, I just wanted to see what it would do- I know how silly this probably is, but the error saying the function "get_units" could not be found came up again. I realize I have a lot of work left to do becoming more proficient with this package, but this has me at a stand still right now. Any guidance would be greatly appreciated. DoddstreamMet.zip Thank you so much!

aappling-usgs commented 7 years ago

The code files in streamMetabolizer are package components rather than scripts; they look like scripts but usually only work when called as package functions. It's the difference between library(streamMetabolizer); mm_name(...) and source('my/path/to/streamMetabolizer/R/mm_name.R'); mm_name(...), where you shouldn't ever need the latter. In fact, even though it's possible to look at the package source, you shouldn't need to inspect or copy any of the code files to use the package effectively; instead, use install.packages to download the code and then treat streamMetabolizer as a collection of functions, just like other packages such as dplyr or lme4.

Rather than adapting existing code files from the streamMetabolizer package, make it your first goal to use R (base, dplyr, etc., and just a touch of streamMetabolizer) to get your data into the required format (6 columns having the correct contents and names, as described in ?streamMetabolizer::metab). There's no need for you to write or modify a data_metab function. Next run mm_name, specs, and metab as functions (not scripts) to fit your model.

Units are optional; it's essential that the numbers in your data are in the correct units and therefore have the correct scale, but you can pass in a regular data.frame without using the unitted package, which is where the get_units function resides. If you prefer to attach units to your data.frame, simply call library(unitted) before using the functions u, get_units, v, etc. You have this package already because it was installed when you installed streamMetabolizer.

Data preparation is its own beast, and one that streamMetabolizer can only ease a little. You'll need to identify most of the data preparation steps based on your knowledge of R and your understanding of your own dataset. Some preliminary, non-exhaustive observations for the dataset you've shared:

  1. You'll need to convert your character date-time values, e.g., '6/10/2015 0:00', into R's POSIXct format. The code you shared, starting with this line, won't do it (at least with the version of your data that you shared):

    exampledata$local.time <- lubridate::with_tz(as.POSIXct(paste(exampledata$date, exampledata$time), format="%m/%d/%Y %H:%M:%S", tz="America/Chicago"), tz_exampledata) # original is in CDT

    because the format of your date-time strings is not "%m/%d/%Y %H:%M:%S". See ?as.POSIXct (a base R function) for more on how to identify the proper format code for your data.

  2. The light data you've shared is a bunch of 0s and 1000s. streamMetabolizer models won't like this; a smooth curve as light increases and decreases each day is important. Were your light data corrupted? If those are your best available empirical data, modeled light might indeed be better. As explored in your example script (mydatametab.R), you can use the streamMetabolizer functions convert_SW_to_PAR and calc_solar_insolation to model cloud-free, shade-free light curves. See also the newer calc_light (description at ?calc_light) which provides a simpler interface to those functions. Cloud-free and shade-free are not optimal but are better than 0s and 1000s.

Hope this helps you get started, Alison