Projections: Catch data

[lentinj]

• [ ] Add a g3_if_projecting(catchability_a, catchability_b) wrapper around an if-statement, living in a projection_utils.R?

• [ ] Take g3a_predate_catchability_hockeyfleet() out of g3experiments, use this as the example option in vignettes.

• Also needs an hcr() style assesment & application timestep: 2 year time lag is very common

• In an ideal world, what would happen would be

  • gadget3 itself forecasts ahead 2 years, and uses this to define the catch (i.e. being both the operating model and assessment model)
  • hockeyfleet() cheats, and assumes it's constant and relies on the advice error to produce a useful forecast

[lentinj]

For "forecasts ahead 2 years", we could just run ourselves, but project_years is set to 2 more years. Obviously very wasteful though. OTOH, if we could have a "restartable model", feeding in the current environment as the state, we could carry on from where we left off.

[lentinj]

@bthe I've been looking at g3a_predate_catchability_hockeyfleet, and trying to pick apart what it does that's different to g3a_predate_catchability_hcr. They're not equivalent, but clearly trying to solve the same problem.

Reducing down g3a_predate_catchability_hockeyfleet to pseudo-code, it's:

biomass < sum(stock__num * stock__wgt * stock__suit)
# NB: The hcr/catchability split is mostly to make the comparison below work
hcr <- hr * pmin(sum(biomass)/btrigger, 1) * stock_ss(stock__predby_predstock)
catchability <- hcr * E * cur_step_size

• biomass is approximately the trigger_fs = list(ling_imm = g3a_hcr_biomass_weighted(0,0,0), ling_mat = g3a_hcr_biomass_weighted(0,0,1)) argument of g3a_hcr_assess. g3a_hcr_biomass_weighted essentially being a hard-coded suitability
• hcr is a simpler form of g3a_hcr_tac_singletrigger, but
  • It does stock_ss(hcr__trigger) - trigger (hcr__trigger being the gathered biomass), not sum(biomass)/btrigger.
  • It does stock_ss(hcr__fishable) (i.e. the sum of biomass found by fishable_fs), not stock_ss(stock__predby_predstock) (the biomass caught by predator), but maybe a similar idea, sorta?

Do you remember the history here? What differences in the above are critical?

EDIT: I'm not sure how much either of these have been used. It could well be - trigger vs / trigger is a bug more than anything else.

[bthe]

The idea behind g3a_predate_catchability_hcr was to mimic gadget2's prognosis likelihood functionality. But I don't think I ever tested this function properly and I'm not entirely convinced about the code either.

The main idea behind the HCR function was to:

• Calculate the value of a reference biomass
  • This is independent from the fleets harvesting the fish
• Apply a harvest rate multiplier to the reference biomass.
  • This multiplier is essentially a function of SSB and the Btrigger value(s)
• Catch set for a future time-period (typically a year) as the refbio times HR

This is different from the hockeyfleet as there you are apply a constant effort to the catch period, not total catch.

[lentinj]

Okay, the main thing confusing me at this point is hockeyfleet is quota_f * E * cur_step_size * stock_ss(stock__predby_predstock) which would apply the quota to the previous step's catch.

I think what this really wants to be is quota_f * E * cur_step_size * stock_ss(predprey__suit), and then is identical to linearfleet/effortfleet, but also applying the quota.