bering juvenile/adult expansion

[pete-hulson]

Question

Would it be possible to get pointed to the functions that do the length frequency juvenile/adult expansion in the bering? These would be the functions that provide the length frequencies (e.g., in the AKFIN_LENGTH table) that are then subsequently used in the gapindex::calc_sizecomp_stratum() fcn. Thanks much!

[zoyafuso-NOAA]

Hi Pete,

Looping @ChrisAnderson-NOAA in this issue as he deals with our Oracle tables on a deeper level and because I can't fully explain how the juvenile expansions are done in the Bering especially wrt splits in the catch processing. Chris, do you know where this code lives and/or generally how those length records are created in RACEBASE.LENGTH?

Thanks,
Zack

[ChrisAnderson-NOAA]

Hey you two,

This process occurs during our data finalization. While finalizing the data, a PLSQL package written by a past staff member (Heather? Possibly Allison?) executes and completes this length frequency juvenile/adult expansion and outputs the results to the RACEBASE table. To my knowledge, the AKFIN tables just pull these RACEBASE lengths and reports those, with no further editing (besides those made for readability). I would have to dig into with package explicitly does this (as the data finalization process executes MANY packages and I don't know which one contains the relevant code).

[pete-hulson]

Thanks Chris and Zack - appreciate the speedy responses. Oof, diggin into PLSQL doesn't sound that fun... Been there, done that

K, reason I'm poking around with this is we've got a package that is using bootstrap to esitmate uncertainty in our comp data. This is the last remaining peice to include, but, my intuition is that the change to uncertainty will be very minimal and not worth the time suck it'd be to ID where that is happening in the PLSQL code and then transferring that to R. The additional issue is that the package would then need access to the rawest of rawest data, right now we're running it off of the AKFIN data products y'all are providing (and I'm good with that).

Final question... One of the outputs of the package is a file that compares the input sample size (result of the bootstrap) with the sample size that was collected. This is where this particular issue came up during this past assessment season - Jim noticed that the length sample sizes were through the roof (200k plus), which is a result of the juvenile/adult expansion. Is there a dataframe somewhere that has the pre-expanded samples to be able to get the 'actual' number of lengths sampled? Alternatively, I could just make a note for bering assessment authors that the sample size is post-expansion, or just not show them at all...

[zoyafuso-NOAA]

Chris can help me out with this one but the raw lengths are contained within the RACE_DATA.LENGTHS table, but I believe those length records only go back to 2005. I'm not sure where the raw length data live prior to 2005 outside of the actual physical data sheets. If a partial dataset will suffice, we have some code that links the RACE_DATA.LENGTHS tables with the other tables in RACE_DATA to produce a non-expanded length table in a format similar to what is in RACEBASE.LENGTH/AKFIN_LENGTH.

Slight tangent: we've been trying to work on a view table in GAP_PRODUCTS that tabulates how many otoliths, read otoliths, and lengths were recorded for each region/year/species as well as how many hauls those three data types were taken. We came across the same error with the Bering Sea expanded lengths with pollock and cod and couldn't reconcile the error given the truncated year set. All that to say, we've also come across this issue with not a path forward yet.

[pete-hulson]

Thanks much for all this, and interesting to see we've come across the same thing. For our purposes, I just made a note in our package that these are expanded for some of the bering stocks (this output is merely used for comparison anyway), not really feeling the need/desire to add queries to our data calls (and have to switch from AKFIN to AFSC in the middle of it).

That view table would be super helpful, even if (in my opinion) it was only a partial time series in the bering.

Thanks again for the input fellas - appreciate it