{"action":"closed","issue":{"url":"https://api.github.com/repos/USGS-R/mda.streams/issues/135","labels_url":"https://api.github.com/repos/USGS-R/mda.streams/issues/135/labels{/name}","comments_url":"https://api.github.com/repos/USGS-R/mda.streams/issues/135/comments","events_url":"https://api.github.com/repos/USGS-R/mda.streams/issues/135/events","html_url":"https://github.com/USGS-R/mda.streams/issues/135","id":96162936,"number":135,"title":"plan for posting metab_ts results from many model runs","user":{"login":"aappling-usgs","id":12039957,"avatar_url":"https://avatars.githubusercontent.com/u/12039957?v=3","gravatar_id":"","url":"https://api.github.com/users/aappling-usgs","html_url":"https://github.com/aappling-usgs","followers_url":"https://api.github.com/users/aappling-usgs/followers","following_url":"https://api.github.com/users/aappling-usgs/following{/other_user}","gists_url":"https://api.github.com/users/aappling-usgs/gists{/gist_id}","starred_url":"https://api.github.com/users/aappling-usgs/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/aappling-usgs/subscriptions","organizations_url":"https://api.github.com/users/aappling-usgs/orgs","repos_url":"https://api.github.com/users/aappling-usgs/repos","events_url":"https://api.github.com/users/aappling-usgs/events{/privacy}","received_events_url":"https://api.github.com/users/aappling-usgs/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-07-20T21:20:47Z","updated_at":"2015-08-12T18:08:15Z","closed_at":"2015-08-12T18:08:15Z","body":"It would be useful to have more than 1 time series of GPP/ER/K estimates posted to SB for a site. This would let us compare model outputs using Jordan's nifty shiny app and would generally facilitate comparisons among model runs within a site.\r\n\r\nIt's getting ridiculous to think of encoding all important model specifications in the ts var_src label - for example, I just actually entertained the idea of posting a ts named `K600_estBayPRKPHmPRKtP`. So let's not. \r\n\r\nOne possibility is to tag a metab_ts with its config file tag (e.g., 0.1.4) and row number (e.g., 198) to produce labels such as GPP_est0.1.4.198, ER_est0.1.4.198, and K600_est0.1.4.198. This would be nice because you could go look up the row in the config file and have ALL the details right away. And including the row number means you could use the same config file to model one site in several ways. \r\n\r\nBut this would be horrible because we'd have to either (1) add ~3 rows to var_src_codes.tsv for every config row, which would get out of control quickly, or (2) change the posting, finding, and verifying of ts files so that nothing breaks when we refer to a ts src by a variant of est0.1.4.198 that's not in var_src_codes.tsv, which would be a major refactoring effort.\r\n\r\nWe could just use the config tag number, which would reduce the complexity, but we'd have to make sure that each site only appears once per config file.\r\n\r\nOr we could write new plotters & accessors to pull ts data from the Metab_runs folder instead of needing it to be posted within a specific site folder.\r\n\r\nHmm.\r\n\r\nThe original plan Jordan & I discussed was to have just one ts per metab variable per site that's actually posted in the site folder. I'd drifted away from that because Bob & I were hoping to let people compare results across modeling approaches, and Jordan's shiny ts app is so cool and easy, but now I'm thinking it might not be the right tool for this job.\r\n\r\nSo maybe I'm back to planning for one ts per var per site, e.g., K600_estBest, augmented by a function something like `download_metab_ts(var='K600', tag='0.1.4', row=198)` or even \r\n```r\r\ndownload_metab_run(mytitle, myfolder)\r\nconfig <- read.table(file=file.path(myfolder,\"config.tsv\"), sep=\"\\t\", header=T, colClasses=\"character\")\r\nall_out <- load(file.path(myfolder,\"all_out.RData\")\r\nconfig_row <- which(config$row==\"198\") # or which(config$site==\"nwis_44\"), etc.\r\nGPP.mean <- predict_metab(all_out[config_row])$GPP.mean\r\n```\r\nwhich isn't *that* bad, is it?"}}