Previous year's biomass not correct

[andrew-edwards]

prev_bio_median_last_assess is 1.904 million t, but One-page summary from last year's assessment says 1,909,550 t (so not a rounding error).

Similarly, prev_bio_lower_last_assess to prev_bio_upper_last_assess is 0.760 to 5.429, but last year's one-page says 757,006 to 5,609,831.

The numbers I just quoted are the same as Chris's build from 12th Jan (that I kept for reference).

Not major differences but should be fixed. Not sure if related to #1105 or to do with that problem we had with exactly which model runs were used last year.

[cgrandin]

We have to put the rds file we used last year on the server. It currently has output from new code

[andrew-edwards]

I have the .rds. I'll test it now locally.

[andrew-edwards]

But I thought the structure had changed, which is why I originally got the new .rds from you. I'm leaving shortly and this will take a while to reload models, so won't get to it now, sorry. So I have 01-base.rds dated 16/2/23 from last year.

[cgrandin]

@andrew-edwards If the structure has changed enough that we can't load last year's, let me know and I will strip the parts off the old one and place those into the new structure so that it works and the values are correct.

[andrew-edwards]

Just noting that the numbers in Table 27 (showing last year's results) are slightly wrong also - which makes sense if it's not the same .rds file. In case anyone was looking at them. (I was to check if we can still say that 2014 cohort size has now stabilised, but it's a billion less fish than we thought last year, so that sort of sentence is not really valid any more).

[andrew-edwards]

Also med_est_2021_rec, see first comment added in 2e6d3ad. Can remove that when this issue is resolved.

[andrew-edwards]

Okay, so using the base-01.rds (dated 2023-02-16) I have from last year's assessment (I'll upload it somewhere and post in Slack). 004-load-project-variables.rmd fails, and I traced it down to L1088 (since d_obj_bridge_recdev from the bit before exists). Trying to run L1088 alone:

 iter <- 0
 d_obj_bridge_age1_index <- map2(bridge_models, bridge_models_names, ~{
    iter <<- iter + 1
   create_group_df_index(.x, .y,
                         survey_type = "age1")
 })

gives

Error in `map2()`:
ℹ In index: 1.
Caused by error in `map2()` at hake-assessment-2024/R/utils-extract-survey-index-fits.R:29:3:
ℹ In index: 1.
Caused by error in `UseMethod()`:
! no applicable method for 'filter' applied to an object of class "NULL"
Run `rlang::last_trace()` to see where the error occurred.
>

Am guessing it might be something to do with having no age-1 index value last year, but that's pure speculation. Expect thes ame might be true for the next bit of code regarding age-2 index (this is for setting up bridging models), but it looks like the rest of 004-load-project-variables.rmd should work. So over to Chris I think.

[cgrandin]

Thanks, that helps. If that’s all it is then it’s an easy fix. Until the next error crops up :) There is no end to debugging

[cgrandin]

I got this working fine with last year's actual file from your Google drive but the values are still what they were. i.e.

prev_bio_median_last_assess is 1.904 million t, but One-page summary from last year's >assessment says 1,909,550 t (so not a rounding error).

Similarly, prev_bio_lower_last_assess to prev_bio_upper_last_assess is 0.760 to 5.429, but >last year's one-page says 757,006 to 5,609,831.

Are still the same, not what it in last year's one-page summary. So I think the only explanation for that is that the RDS file you posted is not the one we built the final document with.

If you could check any RDS files you have by loading it with readRDS() and then check this value:

k <- readRDS("/srv/hake/models/2023/01-version/01-base-models/01-
base/01-base.rds")

k$mcmccalcs$smed[names(k$mcmccalcs$smed) == last_data_yr]

it should be the median 2023 biomass from the one-page summary. For your file it is 1.903915.

Also, we can't use the HTML comments to comment-out r objects, knitr still parses them on the first pass. I don't think we need those variables about probability that a given cohort is greater than the 2010 cohort anyway so we should just remove this commented section. https://github.com/pacific-hake/hake-assessment/blob/34f6d547a2a0659cfe19a5c24064b90d6eae8480/doc/004-load-project-variables.rmd#L756

[kellijohnson-NOAA]

If it helps I have an rds file from last year where

k$mcmccalcs$smed[names(k$mcmccalcs$smed) == last_data_yr] = 1.90955

The file was saved 02-08-2023 at 10:50 am. @cgrandin if you want me to put it on the server somewhere, just let me now where.

[aaronmberger-nwfsc]

Thanks Kelli. And interesting re Andy's 2023 base rds file because I have what he sent me back in Oct/Nov (recall I asked for it then when I noticed this discrepancy) and it has the correct values. I just forwarded that email with a link to the drive location that has the correct rds.

On a broader note, should we start labelling rds files with a time stamp or 'final' or something, such as 01-base-2024f.rds? I have too many 01-base.rds files floating around from multiple years.

[cgrandin]

@kellijohnson-NOAA , that's perfect. Can you put it in /srv/hake/models/2023/01-version/01-base-models/01-base - last year's base folder

Thanks!

[andrew-edwards]

I also have one from last year that I saved as 01-base-2023-02-09.rds on 13th Feb 2023. Sounds like it's the same as Kelli's. I just took the later saved one from my directory yesterday (but must have sent Aaron the earlier one). So let's try Kelli's first, which sounds like it should work.

[cgrandin]

This is done. I checked the values Andy mentioned above. Old RDS on server and has been fixed in structure to work with this year's document. Also reduced the size by 25 times. The Google drive will have the updated RDS at

/srv/hake/models/2023/01-version/01-base-models/01-base/01-base,rds