PecanProject / pecan

The Predictive Ecosystem Analyzer (PEcAn) is an integrated ecological bioinformatics toolbox.
www.pecanproject.org
Other
203 stars 235 forks source link

met.process error: no package called PEcAn.data.atmosphere #918

Closed dlebauer closed 8 years ago

dlebauer commented 8 years ago

given this file met.process_error.xml

The following code throws an error on ebi-forecast but not on the VM:

library(PEcAn.all)
settings <- read.settings('met.process_error.xml')
result <- met.process(
  site       = settings$run$site, 
  input_met  = settings$run$inputs$met,
  start_date = settings$run$start.date,
  end_date   = settings$run$end.date,
  model      = settings$model$type,
  host       = settings$host,
  dbparms    = settings$database$bety, 
  dir        = settings$database$dbfiles,
  browndog   = settings$browndog)

Here is the error:

2016-07-20 17:03:03 WARN   [browndog.met] : 
   Could not process model BIOCRO 
  scale format.id           format.name      format.mimetype format.inputtype
1  site        38 AmeriFlux.level2.h.nc application/x-netcdf    ameriflux.zip
[1] "start CHECK"
[1] "end CHECK"
data frame with 0 columns and 0 rows

R version 3.2.3 (2015-12-10) -- "Wooden Christmas-Tree"
Copyright (C) 2015 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> remotefunc <- function() {
+ PEcAn.data.atmosphere::download.Ameriflux('Bondville (companion site) (US-Bo2)','/home/dlebauer/.pecan/dbfiles/Ameriflux_site_1-138','2005-03-26 19:00:00','2005-10-15 22:00:00')
+ }
> remoteout <- remotefunc()
Error in loadNamespace(name) : 
  there is no package called ‘PEcAn.data.atmosphere’
Calls: remotefunc ... tryCatch -> tryCatchList -> tryCatchOne -> <Anonymous>
Execution halted
[1] 1
Error in new.files$file : $ operator is invalid for atomic vectors

It seems to restart R in the middle of the call. Is this expected?

robkooper commented 8 years ago

Yes it always runs R in a new process, not sure I remember why it was implemented that way. We could just as easily run the R command inside the same R interpreter if it is local. https://github.com/PecanProject/pecan/blob/master/utils/R/remote.R#L180

As a side node, we should update this function to be similar as the others, getting passed in host so we can leverage of the tunnel if it exists.

dlebauer commented 8 years ago

Thanks I'll keep this open for the side note On Thu, Jul 21, 2016 at 12:26 AM Rob Kooper notifications@github.com wrote:

Yes it always runs R in a new process, not sure I remember why it was implemented that way. We could just as easily run the R command inside the same R interpreter if it is local. https://github.com/PecanProject/pecan/blob/master/utils/R/remote.R#L180

As a side node, we should update this function to be similar as the others, getting passed in host so we can leverage of the tunnel if it exists.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/PecanProject/pecan/issues/918#issuecomment-234160232, or mute the thread https://github.com/notifications/unsubscribe-auth/AAcX5wRWOnpQKYfPMUHSYUdAXEp012dGks5qXwMegaJpZM4JRQ4G .

mdietze commented 8 years ago

Moving tunnel issue to a new issue.

I suspect that the fail to find PEcAn.data.atmosphere in the new shell may have to do with where libraries are installed (e.g. by default RStudio and R put R libraries in different folders)

Running in a new shell (not a restart) was done to simplify met.process and convert.inputs -- it runs the same exact things in both environments (local vs remote), thus avoiding the need to maintain two parallel versions of the same commands, which we worried would lead to code divergence and difficulties with maintenance and debugging (remote is pretty hard to debug, but is simpler if you know the local code is exactly the same)