afsc-gap-products / model-based-indices Goto Github PK

-index

1984 - 2021
VAST v3.6.1
cpp VAST_v12_0_0
Matrix: 1.2.18
TMB: 1.7.18
750 knots
extrapolation grid < 700 m
ObsModel = c(2,1)
bias corrected
knot_method = 'grid'
fine scale = TRUE
anisotropy on

1996 - 2021
VAST v3.6.1
cpp VAST_v12_0_0
Matrix: 1.2.18
TMB: 1.7.18
750 knots
extrapolation grid < 700 m
ObsModel = c(2,1)
bias corrected
knot_method = 'grid'
fine scale = TRUE
anisotropy on

-index and regional allocation

Hi @Lewis-Barnett-NOAA, @coleary-noaa, @EmilyMarkowitz-NOAA, @sowasser

I created a space in the gap_products Github repo to reproduce and compare the 1982-2022 Bering Sea (EBS and NBS) YFS and PCod wCPUE, nCPUE, and age cpue datasets pulled using sumfish vs gapindex. I think I remember Sophia and Lewis in the past saying that pollock has a separate workflow so I did not include pollock in this exercise. I also created a template Bering Sea gapindex data pull that we can work with and put it in the R/ folder.

Summary of the scripts used to perform bridging

• EBS_VAST_Bridging_gapindex.R produces these data via gapindex
• EBS_VAST_Bridging_sumfish.R produces these data using sumfish. Follows the Prepare_EBS_NBS_Data.R script
• EBS_VAST_Index_Bridging.R compares the two sources

Summary of the gapindex-sumfish bridging of VAST data pulling

Weight catch and effort data for biomass index: no difference between the sumfish and gapindex data pulls for YFS and PCod. Yay.

Numerical catch and effort data for abundance index. There are a handful of hauls where a positive weight was recorded but numbers were not collected. The sumfish version of the dataset assumes these values as zero whereas these hauls are removed in the gapindex version. The number of hauls with this discrepancy is 9 for YFS and 7 for PCod. This doesn’t affect the YFS workflow because numbers are not modelled.

Age CPUE: In addition to the hauls identified previously, there are a larger handful of hauls where there are positive weights and numbers data but no associated length information (115 total YFS hauls and 40 PCod hauls). The sumfish version of the age cpue dataset assumes these hauls to have 0 cpue whereas these hauls are removed from the gapindex version.

Jason mentioned this in issue #32 and I also noticed that there are some data complications when partitioning unsexed individuals (SEX = 3) in the sizecomp data across ages when the alks are often created with individuals that are sexed. SEX = 3 individuals have their own ALK in our workflow whereas in the design-based composition production, the SEX = 3 ALK is created using all sexes combined. Doing it the latter way may help account for all of the unsexed length individuals but I don't want to propose prioritizing this change given the software bridging that we are doing this year.

Let me know if you want to see any details about this exercise, I just wanted to start with the main points.

Please pull the relevant updated VAST methods text from here: https://docs.google.com/document/d/13gPz3NjhH7p3jVvhfQPzGknY2vsHyYzCZ65viK7ImYc/edit?usp=sharing

-index

Hey Folks,

Many of us had problems logging into our VMs this week. IT says that one issue is that we need to specify the remote machine not by the IP address, but by the name of the machine: AKC0SS-VU-200 (where the last three digits are the same as the last 3 of the IP address).

Once that is done, when you hit connect, make sure that it using your correct credentials (the right CAC card cert).

Lewis

Working on /R/prepare_EBS_NBS_data.R

I am starting this issue to document the sensitivity of the estimated age comps to bias correction (bias.correct argument in FishStatusUtils::make_settings)

1984 - 2021
VAST v3.6.1
cpp VAST_v12_0_0
Matrix: 1.2.18
TMB: 1.7.18
750 knots
extrapolation grid < 700 m
ObsModel = c(2,1)
bias corrected
knot_method = 'grid'
fine scale = TRUE
anisotropy on

Hey @Lewis-Barnett-NOAA ,

Can you look at the EBS/NBS data pull script and confirm for me that when we create the NBS alk for VAST modsquad purposes, we are including all years except for the 2018 NBS survey. I want to make sure that was intentional so I can configure gapindex to do the same.

Thanks,
Zack

2021 collected otoliths for agecomp species should be updated prior to 2022 SAFE production runs of VAST.

Lines of communication:

• Survey Supervisors
• [email protected] (RACE database manager)
• [email protected] (Age & Growth data manager)

1984 - 2021
VAST v3.6.1
cpp VAST_v12_0_0
Matrix: 1.2.18
TMB: 1.7.18
750 knots
extrapolation grid < 700 m
ObsModel = c(2,1)
bias corrected
knot_method = 'grid'
fine scale = TRUE
anisotropy on

New installations of INLA:
install.packages("INLA",repos=c(getOption("repos"),INLA="https://inla.r-inla-download.org/R/stable"), dep=TRUE)

fail on MRAN 4.0.2 whether using the default or user library.

1990 - 2021
VAST v3.6.1
cpp VAST_v12_0_0
Matrix: 1.2.18
TMB: 1.7.18
750 knots, also tested 500 knots for backwards comparison
extrapolation grid < 700 m
ObsModel = c(2,1)
bias corrected
knot_method = 'grid'
fine scale = TRUE
anisotropy on

1984 - 2021
VAST v3.6.1
cpp VAST_v12_0_0
Matrix: 1.2.18
TMB: 1.7.18
750 knots
extrapolation grid < 700 m
ObsModel = c(2,1)
bias corrected
knot_method = 'grid'
fine scale = TRUE
anisotropy on

Hi @coleary-noaa, @MargaretSiple-NOAA, @Lewis-Barnett-NOAA

Check that the data input that comes from gapindex to what was produced historically for modsquad.

I compared the data inputs from gapindex to those that were uploaded to the modsquad folder before the 2023 modsquad production run. That script lives here. The script uses an excel spreadsheet that holds the googledrive ids for each GOA dataset. If you want to recreate the comparison and clone the gap_products repo, they both are here. I couldn't detect a difference but it might still be useful to do a quick check for our respective species when we're doing the vast-sdmtmb bridging.

Create a vignette/piece of code that GOA folks can use to do their data pulls like R/Prepare_GOA_data.R.

We can work off of this template. I think going forward we should include HAULJOIN in the input to make it easier to track even though we don't use it in the models. @coleary-noaa, can you check that this piece of code works and maybe you can update the Prepare_GOA_data.R script.

## Import gapindex package. Installation functions are provided below. 
## library(devtools)
## devtools::devtools::install_github("afsc-gap-products/gapindex")
library(gapindex)

## Connect to Oracle. Make sure you are on the NOAA internal network or VPN
sql_channel <- gapindex::get_connected()

## Set constants, adjust for the request. You can also specify a species 
## complex via a dataframe. See gapindex::get_data() or the example commented
## out below for dusky rockfish. 
years <- 1990:2023
species_code <- 21720
# species_code <- data.frame(SPECIES_CODE = c(30152, 30150), 
#                            GROUP = c(30152, 30152))

## Pull catch and haul data. `pull_lengths` = F speeds up the function by not
## pulling lengths/specimen data. By default, only hauls with ABUNDANCE_HAUL == 
## 'Y' are filtered.
gapindex_data <- gapindex::get_data(survey_set = "GOA",
                                    year_set = years,
                                    spp_codes = species_code,
                                    pull_lengths = FALSE,
                                    sql_channel = sql_channel)

## Calculate weight and numerical CPUE and zero-fill hauls
gapindex_cpue <- gapindex::calc_cpue(racebase_tables = gapindex_data)

## Format catch and effort data for VAST. Note: The `AreaSwept_km2` field set 
## to 1 when using CPUE in the `Catch_KG` field.
data_geostat <- with(gapindex_cpue, data.frame(year = YEAR,
                                               hauljoin = HAULJOIN,
                                               vessel = "missing",
                                               lat = LATITUDE_DD_START,
                                               lon = LONGITUDE_DD_START,
                                               catch_kg = CPUE_KGKM2,
                                               Area_swept_km2 = 1,
                                               pass = 0) )

## Save output...

-index

data west of 140 deg W lon

1984 - 2021
VAST v3.6.1
cpp VAST_v12_0_0
Matrix: 1.2.18
TMB: 1.7.18
750 knots
extrapolation grid < 700 m
ObsModel = c(2,1)
bias corrected
knot_method = 'grid'
fine scale = TRUE
anisotropy on

-index
-COG & area occupied on rotated axis

data west of 140 deg W lon
rotated axis -pi/8 (slightly clockwise)

1984 - 2021
VAST v3.6.1
cpp VAST_v12_0_0
Matrix: 1.2.18
TMB: 1.7.18
750 knots
extrapolation grid < 700 m
ObsModel = c(2,1)
bias corrected
knot_method = 'grid'
fine scale = TRUE
anisotropy on

1984 - 2021
VAST v3.6.1
cpp VAST_v12_0_0
Matrix: 1.2.18
TMB: 1.7.18
750 knots
extrapolation grid < 700 m
ObsModel = c(2,1)
bias corrected
knot_method = 'grid'
fine scale = TRUE
anisotropy on

data west of 140 deg W lon
rotated axis -pi/8 (slightly clockwise)

1984 - 2021
VAST v3.6.1
cpp VAST_v12_0_0
Matrix: 1.2.18
TMB: 1.7.18
750 knots
extrapolation grid < 700 m
ObsModel = c(2,1)
bias corrected
knot_method = 'grid'
fine scale = TRUE
anisotropy on

@EmilyMarkowitz-NOAA @Lewis-Barnett-NOAA @coleary-noaa

Starting an issue to track our progress on this.

I mistakenly started running the production age comp model using data from 1982-2022. Starting a new run with specimen data from 1982-2022 and letting the global ALK fill in the VAST age data inputs for 2023. I didn't know/forgot that this was our process for the Fall production run. I apologize again for the misinterpretation of our workflow. We will run at least two versions of this model with different values for newton steps.

@zoyafuso-NOAA (Virtual Machine 151): fit_model(..., newtonsteps = 0)
@EmilyMarkowitz-NOAA (Virtual Machine 152): fit_model(..., newtonsteps = 1)

@EmilyMarkowitz-NOAA: the script for this was pushed yesterday and the data are located here. Doublecheck before you run anything that there are 2023 data.

note: I assume newtonsteps = 0 is a valid choice but I noticed in FishStatsUtils::fit_model() that the default choice for newtonsteps is 1.

The punchline is that we will be late on delivering the agecomps for YFS (October 15th is the deadline for NBS/EBS products).

1984 - 2021
VAST v3.6.1
cpp VAST_v12_0_0
Matrix: 1.2.18
TMB: 1.7.18
750 knots, also tested 500 knots for backwards comparison
extrapolation grid < 700 m
ObsModel = c(2,1)
bias corrected
knot_method = 'grid'
fine scale = TRUE
anisotropy on

-COG & area occupied on rotated axis

-COG & area occupied

Topic for research in 2023: currently, ages are assigned to lengths by sex-specific ALKs then pooled for Pcod (et al.). Usually, sex is identified for juvenile age specimens, so these wont match up to the sizecomps in the survey. What is the best approach for generating agecomps for these categories?

Updated versions of packages and using:
MRAN 4.0.2
TMB 1.7.22
VAST(dev) 3.9.0
VAST cpp v14_0_0
FishStatsUtils(dev) 2.11.0

Pacific cod code from the index in 2021 fails to compile the TMB object.

Making TMB object

"C:/rtools40/mingw64/bin/"g++ -std=gnu++11 -m64 -I"C:/PROGRA1/MICROS2/ROPEN1/R-401.2/include" -DNDEBUG -I"C:/Users/JASON1.CON/AppData/Local/R/R-401.2/library/TMB/include" -I"C:/Users/JASON1.CON/AppData/Local/R/R-401.2/library/RCPPEI1/include" -DTMB_SAFEBOUNDS -DLIB_UNLOAD=R_unload_VAST_v14_0_0 -DTMB_LIB_INIT=R_init_VAST_v14_0_0 -I"C:/a/w/1/s/vendor/extsoft/include" -Wno-ignored-attributes -O2 -mfpmath=sse -msse2 -mstackrealign -c VAST_v14_0_0.cpp -o VAST_v14_0_0.o
VAST_v14_0_0.cpp: In member function 'Type objective_function::operator()()':
VAST_v14_0_0.cpp:2124:13: error: 'newton' has not been declared
S = newton::Tag( Index_ctl(c,t,l) ); // Set lowrank tag on S = sum(exp(x))
^~~~~~
make: *** [C:/PROGRA1/MICROS2/ROPEN1/R-40~1.2/etc/x64/Makeconf:229: VAST_v14_0_0.o] Error 1
Error in TMB::compile(file = paste0(Version, ".cpp"), flags = "-Wno-ignored-attributes -O2 -mfpmath=sse -msse2 -mstackrealign") :
Compilation failed

It looks like it is still trying to compile/write in the protected MRAN directory. Adding the "CompileDir" argument to fit_model() does not change this.

I just received this important message from Jim Thorson, about how our meshes may differ if built in earlier vs more recent versions of INLA. Read below and check which version of INLA you are using. Ideally, each of you would update INLA and verify and document what if any changes the new version produces in the model output (compared to prior hindcast, using data only through 2022). Alternatively, you can continue to use the older INLA version for 2023 production estimates to maintain internal consistency with the hindcast. Let me know if you have questions and what version you have currently installed. Thanks!

From Jim:
"
As I mentioned, I've been working to eliminate INLA as dependency from VAST (with experimental approach now on VAST and FishStatsUtils dev branches).

However, when running CI tests for backwards compatibility, I found that results changed for a few tests. Long story short (and a full day later), I find that the change occurs between INLA release 23.4.24 and 23.9.9 (and not due to any change in VAST/FishStatsUtils), where the mesh constructed for the eastern Bering Sea is different for identical VAST and FishStatsUtils but using these different INLA releases.
"

The good news is that VAST will be updated soon and when we make the switch for next year's estimates, INLA will no longer be a dependency thanks to Jim's changes.

1996 - 2021
VAST v3.6.1
cpp VAST_v12_0_0
Matrix: 1.2.18
TMB: 1.7.18
750 knots
extrapolation grid < 700 m
ObsModel = c(2,1)
bias corrected
knot_method = 'grid'
fine scale = TRUE
anisotropy on