getGridMET returns error when embedded within another function

[ryanrbart]

Hi Mike. Thanks for developing this package. It's fantastic.

I would like to embed some of the climateR functions within my workflows, so that I can more easily fetch the data that I want. Here is a simple example of what I want to do.

sb_county <- AOI::aoi_get(state = "CA", county = "Santa Barbara")

wrapper_function <- function(aoi, var_name, start_date, end_date){

  # My other code here

  climateR::getGridMET(AOI = aoi,
                       varname = var_name,
                       startDate = start_date,
                       endDate = end_date,
                       dryrun = TRUE)
}

wrapper_function(aoi = sb_county,
                 var_name = "pr",
                 start_date = "2000-01-01",
                 end_date = "2000-01-01")

#> Error in climater_dap("gridmet", call_aoi(as.list(match.call.defaults()[-1]), : object '"gridmet"' not found

Unfortunately, adding a wrapper around getGridMET generates an error. It seems to be related to the environment. In the following example, I define new variables in the global environment, but still pass the original variables to the function. The wrapper now works, but incorrectly by grabbing the variables from the global environment and not the variables being passed to the function.

var_name <- "tmmx"             # New met variable
start_date <- "2000-01-01"
end_date <- "2000-01-02"       # New end date

wrapper_function(aoi = sb_county,
                 var_name = "pr",               # Original met variable
                 start_date = "2000-01-01",
                 end_date = "2000-01-01")       # Original end date

#> source:   http://thredds.northwestknowledge.net:8080/thredds/dodsC/agg... 
#> varname(s):
#>    > daily_maximum_temperature [K] (tmmx)
#> ==================================================
#> diminsions:  12, 8, 2 (names: lon,lat,day)
#> resolution:  0.042, 0.042, 1 days
#> extent:      -86.87, -86.37, 38.55, 38.88 (xmin, xmax, ymin, ymax)
#> crs:         +proj=longlat +a=6378137 +f=0.00335281066474748 +p...
#> time:        2000-01-01 to 2000-01-02
#> ==================================================
#> values: 192 (vars*X*Y*T) 

Note that the output is daily maximum temperature and includes two dates, not one.

Any assistance is much appreciated.

Thanks, Ryan

[mikejohnson51]

Hi @ryanrbart! Thanks for the kind words and the interesting use case. This involved changing how environments were handled but resulted in a nice simplification! The following should now work if reinstalled:

library(climateR)

sb_county <- AOI::aoi_get(state = "CA", county = "Santa Barbara")

wrapper_function <- function(aoi, var_name, start_date, end_date){

  # My other code here

  climateR::getGridMET(AOI = aoi,
                       varname = var_name,
                       startDate = start_date,
                       endDate = end_date,
                       dryrun = FALSE)
}

wrapper_function(aoi = sb_county, var_name = "pr", start_date = "2010-01-01", end_date = NULL)
#> $precipitation_amount
#> class       : SpatRaster 
#> dimensions  : 42, 43, 1  (nrow, ncol, nlyr)
#> resolution  : 0.04166667, 0.04166667  (x, y)
#> extent      : -120.7458, -118.9542, 33.37917, 35.12917  (xmin, xmax, ymin, ymax)
#> coord. ref. : +proj=longlat +ellps=WGS84 +no_defs 
#> source(s)   : memory
#> name        : pr_2010-01-01 
#> min value   :             0 
#> max value   :             0 
#> unit        :            mm 
#> time        : 2010-01-01 UTC

wrapper_function(aoi = sb_county, var_name = "tmmx", start_date = "2020-01-01", end_date = NULL)
#> $daily_maximum_temperature
#> class       : SpatRaster 
#> dimensions  : 42, 43, 1  (nrow, ncol, nlyr)
#> resolution  : 0.04166667, 0.04166667  (x, y)
#> extent      : -120.7458, -118.9542, 33.37917, 35.12917  (xmin, xmax, ymin, ymax)
#> coord. ref. : +proj=longlat +ellps=WGS84 +no_defs 
#> source(s)   : memory
#> name        : tmmx_2020-01-01 
#> min value   :           282.2 
#> max value   :           293.8 
#> unit        :               K 
#> time        : 2020-01-01 UTC

^{Created on 2023-12-21 with reprex v2.0.2}

[ryanrbart]

@mikejohnson51, the simplification of the environments has fixed the issue. Everything is working properly on my end. Thanks for taking the time to quickly respond to the issue.