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.

EDIT: This is silly, we changed stock_ss(stock__predby_predstock) to stock_ss(predprey__suit) as part of __cons, it's just old code.

[lentinj]

I think the way forward here is to something very similar to g3_param_project, and define a timeseries vector in the model that we populate with the quota. Then multi-year lags between assessment and implementation are a non-issue.

It would also make it a lot easier to apply a single quota across several fleets, with something like:

quota <- g3_quota(g3_quota_hockeyfleet(
        list(lln1, lln2),
        output_ratios = c(lln1 = 0.25, lln2 = 0.75)),
    lag_steps = 6,  # Implement in 1.5 years' time
    run_step = 2 )
actions <- list(
    g3a_predate(
        lln,
        list(ling_imm, ling_mat),
        catchability_f = g3a_predate_quota(quota),
        suitabilities = g3_suitability_exponentiall50(by_stock = 'species') )
    g3a_predate(
        lln2,
        list(ling_imm, ling_mat),
        catchability_f = g3a_predate_quota(quota),
        suitabilities = g3_suitability_exponentiall50(by_stock = 'species') )
    NULL)

Presumably we have a similar problem with the multivariate case for g3_param_project, that we'd want to go beyond output_ratios at some point and have a quota method define the quota for multiple fleets in one go.

EDIT: Having a multi-fleet quota is fine actually, we already have stock dimensions from dealing with multi-stock likelihood components. We just use those. The Linf/K is problematic because we have no way of automatically knowing which you're intending to use.