Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error with plotDurationUncertainty() function #8

Open
michaelstrupler opened this issue Jun 26, 2024 · 3 comments
Open

Error with plotDurationUncertainty() function #8

michaelstrupler opened this issue Jun 26, 2024 · 3 comments

Comments

@michaelstrupler
Copy link

If I use the function "plotDurationUncertainty()" for another gas than the standard (which is CO2), I get the follwoing error (below), which I don't understand, because the "by" argument in the sequence is positive and between min and max. Please find a MWE attached.

MWE_plotDurationUncertainty.R.zip


Error in `map()`:
ℹ In index: 3.
Caused by error in `seq.default()`:
! wrong sign in 'by' argument
Run `rlang::last_trace()` to see where the error occurred.
> rlang::last_trace()
<error/purrr_error_indexed>
Error in `map()`:
ℹ In index: 3.
Caused by error in `seq.default()`:
! wrong sign in 'by' argument
---
Backtrace:
     ▆
  1. └─RespChamberProc::plotDurationUncertainty(...)
  2.   ├─base::suppressWarnings(...)
  3.   │ └─base::withCallingHandlers(...)
  4.   ├─dplyr::bind_rows(...)
  5.   │ └─rlang::list2(...)
  6.   └─purrr::map_df(...)
  7.     └─purrr::map(.x, .f, ...)
  8.       └─purrr:::map_("list", .x, .f, ..., .progress = .progress)
  9.         ├─purrr:::with_indexed_errors(...)
 10.         │ └─base::withCallingHandlers(...)
 11.         ├─purrr:::call_with_cleanup(...)
 12.         └─RespChamberProc (local) .f(.x[[i]], ...)
 13.           └─RespChamberProc::calcClosedChamberFlux(...)
 14.             └─RespChamberProc::sigmaBootLeverage(...)
 15.               ├─base::seq(max(15, length(conc) - 40), length(conc), 1)
 16.               └─base::seq.default(max(15, length(conc) - 40), length(conc), 1)
 17.                 └─base::stop("wrong sign in 'by' argument")
Run rlang::last_trace(drop = FALSE) to see 4 hidden frames.
@bgctw
Copy link
Member

bgctw commented Jul 5, 2024

I urge you to come up with a truly minimal example next time.

It caused so much hassle to make gdal work on my unbuntu and to install terra and all the other dependencies of your ChamberProc master branch. You have to invest the work to reduce your example that does require to install all those dependencies.
Similar as we discussed in #6, you can do after you created your dataset, you save it an provide it to download.
saveRDS(df,"inst/genData/issue8_duration.rds").
I provide this file with branch durationplot2 of the RespChamberProc package, so that the following MWE can be used:

library(RespChamberProc)
df <- readRDS(url("https://github.com/bgctw/RespChamberProc/raw/d6f28ce0f9fe2e4fec93d1928ff98962c302f792/inst/genData/issue8_duration.rds?raw=TRUE"),"rb")

chamberVol = 0.4*0.4*0.4		# define here chamber volume and surface area
surfaceArea = 0.4*0.4
# reproduces the error
resDur_H2O <- plotDurationUncertainty( df
                                       ,colTime = "TIMESTAMP"
                                       ,colConc = "H2Oppt"
                                       ,colTemp="AirTemp"
                                       ,volume = chamberVol
                                       , durations = seq(124,404,by=5)
)

The problem with the example is that with the specified minimum duration (124) there are not enough records to determine the leverage of influencial records at the start (after tLag) or at the end (in function sigmaBootLeverage) .
It only occurs with H20 fluxes, because the estimated lagtime is larger (hence shorter period until minimum duration).

I updated RespChamberProc in branch durationplot to deliver a better error message, and adapted the default argument of durations. Please, test it with installing RespChamberProc from this branch, e.g. using
devtools::install_github("bgctw/RespChamberProc", ref="durationplot2")

With using the default (adapted in durationplot2) it avoids the error:

# using default durations
resDur_H2O <- plotDurationUncertainty( df
                                       ,colTime = "TIMESTAMP"
                                       ,colConc = "H2Oppt"
                                       ,colTemp="AirTemp"
                                       ,volume = chamberVol
                                       ,nDur = 5
)

# the first duration is the minimum with enough records to inspect
# as inferred by the default
resDur_H2O$statAll[[1]]$duration

@michaelstrupler
Copy link
Author

Thanks a lot.

I am trying to adapt the function plotDurationUncertainty() for use with multiple chunks and to use the Coefficient of Variance (CV = sd/mean) instead of the sd as criterium to define the optimal measurement time window.

If I run this adapted function with the sample data provided here:

https://github.com/michaelstrupler/ChamberProc/blob/master/inst/genData/issue8_duration.rds

I get the following error:
Error in nest():
! Can't supply .by when .data is a grouped data frame.

Backtrace:

  1. ├─global plotDurationUncertaintyRelSDforChunks(...)
  2. │ └─RespChamberProc::calcClosedChamberFluxForChunkSpecs(...) at inst/plotDurationUncertaintyRelSDforChunks.R:16:3
  3. │ └─dsChunk %>% nest(.by = c(iChunk, collar))
  4. ├─tidyr::nest(., .by = c(iChunk, collar))
  5. └─tidyr:::nest.grouped_df(., .by = c(iChunk, collar))
  6. └─cli::cli_abort("Can't supply {.arg .by} when {.arg .data} is a grouped data frame.")
  7. └─rlang::abort(...)
    

it seems that the error occurs because the data.frame in the function "calcClosedChamberFluxForChunkSpecs" is nested.
However, this nesting seems to be necessary for that function.

Please find the MWE (with the function included in the R-File) here:
https://github.com/michaelstrupler/ChamberProc/blob/master/inst/Issue8_duration.R

Thanks for your help!

@michaelstrupler
Copy link
Author

I found the solution, forgot to add "ungroup()" at the end of dsChunk creation....all ok now :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants