how to modify custom extrapolation grid to prevent deparse_unit error?

[sgaichas]

I am updating a previously fitted model that uses a modified extrapolation grid based on northwest_atlantic_grid with an additional strata set. This model and grid were created prior to the Feb 4 2023 release of FishStatsUtils.

The model runs, creates a parameter file output, then fails prior to producing the fit object:

### Applying faster epsilon bias-correction estimator
Error in deparse_unit(extrapolation_list$Area_km2[1]) : 
  inherits(x, "units") is not TRUE

I believe it is hanging up here https://github.com/James-Thorson-NOAA/FishStatsUtils/blame/6f600332c377f783533b1be5a4c355fb3dd9031a/R/amend_output.R#L170

I can run models without issue using the unmodified northwest_atlantic_grid in the current VAST/FishStatsUtils versions.

I cannot see any structural difference between the custom grid I create and the northwest_atlantic_grid in VAST that would cause one to work and the other to fail.

Is there a way to assign units to the Area_km_x field in the custom grid to prevent this error?

Thanks for any thoughts, --Sarah

> packageVersion("VAST")
[1] ‘3.11.2’
> packageVersion("FishStatsUtils")
[1] ‘2.13.1’
> sessionInfo()
R version 4.4.1 (2024-06-14)
Platform: x86_64-apple-darwin20
Running under: macOS Big Sur 11.7.10

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/lib/libRlapack.dylib;  LAPACK version 3.12.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/New_York
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] INLA_24.06.27          sp_2.1-4               Matrix_1.7-0           VAST_3.11.2            FishStatsUtils_2.13.1 
 [6] marginaleffects_0.22.0 units_0.8-5            TMB_1.9.15             dplyr_1.1.4            here_1.0.1            

loaded via a namespace (and not attached):
 [1] utf8_1.2.4              generics_0.1.3          class_7.3-22            fmesher_0.1.7           KernSmooth_2.23-24     
 [6] lattice_0.22-6          magrittr_2.0.3          grid_4.4.1              rnaturalearth_1.0.1     rprojroot_2.0.4        
[11] jsonlite_1.8.8          e1071_1.7-14            DBI_1.2.3               httr_1.4.7              fansi_1.0.6            
[16] codetools_0.2-20        abind_1.4-8             cli_3.6.3               rlang_1.1.4             TMBhelper_1.4.0        
[21] splines_4.4.1           withr_3.0.1             RANN_2.6.2              tools_4.4.1             parallel_4.4.1         
[26] vctrs_0.6.5             R6_2.5.1                proxy_0.4-27            lifecycle_1.0.4         classInt_0.4-10        
[31] pkgconfig_2.0.3         ThorsonUtilities_1.0    terra_1.7-78            pillar_1.9.0            data.table_1.16.0      
[36] glue_1.7.0              Rcpp_1.0.13             sf_1.0-17               rnaturalearthdata_1.0.0 splancs_2.01-45        
[41] tibble_3.2.1            tidyselect_1.2.1        rstudioapi_0.16.0       compiler_4.4.1    

[James-Thorson-NOAA]

Thanks for flagging it, and sorry to hear about the difficulty! VAST had units built in to match SS3 inputs (back in 2015 or something), and I added explicit units to avoid confusion when generalizing it later. obviously tinyVAST / sdmTMB assume that the user can manage them, and therefore have less code-entropy about it.

Well brainstorming here ... there's several avenues:

• you could look at your previous output and just use the reposited semantic-version for FishStatsUtils and VAST without changing code from the previous run ... I'm not aware of any bugs that demand updating
• I could edit the dev branch to edit amend_output to have some default when a_x has no units
• you could edit your workflow to make extrapolation_list, then assign units extrapolation_list$Area_km2 = as_units(extrapolation_list$Area_km2, "km2"), and then pass it back fit_model( ..., extrapolation_list = extrapolation_list)

Any thoughts on which you'd prefer? #1 might be the smoothest workflow.

[sgaichas]

Thanks Jim, exactly what I was looking for. I edited the workflow to modify the custom extrapolation list with one new line of code (option 3) and it all runs now. Much appreciated!