nmfs-ost/ss3-source-code

[Feature]: Add 2-parm catchability (Q) option with offset and slope

Rick-Methot-NOAA opened this issue · 2 comments

Rick-Methot-NOAA commented

Describe the solution you would like.

When an environmental index is used to compare to a dev vector, including recruitment devs, there is a need for an offset parameter as well as the existing slope parameter.
This will be a step in implementation of #5

Input looks like:

#_Q_setup for fleets with cpue or survey data
#_1:  fleet number
#_2:  link type: 1=simple q; 2=mirror; 3=power (+1 parm); 4=mirror with rescale (+1p); 5=offset (+1p); 6=offset & power (+2p)
#_3:  extra input for link, i.e. mirror fleet# or dev index number
#_4:  0/1 to select extra sd parameter
#_5:  0/1 for biasadj or not
#_6:  0/1 to float
#_   fleet      link link_info  extra_se   biasadj     float  #  fleetname
         2         1         0         0         0         0  #  Survey
         3         5         0         0         0         0  #  env
-9999 0 0 0 0 0
#
#_Q_parameters
#_          LO            HI          INIT         PRIOR         PR_SD       PR_type      PHASE    env-var    use_dev   dev_mnyr   dev_mxyr     dev_PH      Block    Blk_Fxn  #  parm_name
           -20            20             0             0            99             0          3          0          0          0          0          0          0          0  #  LnQ_base_Survey(2)
         0.001            20             1             0            99             0          2          0          0          0          0          0          0          0  #  Q_base_env(3)
            -1             1             0             0            99             0          2          0          0          0          0          0          0          0  #  Q_offset_env(3)

Note that this new parameter is now labelled Q_offset. Previously the Q parameter associated with option 3 (mirror +) was called Q_offset. That is renamed to Q_scale because it is principally used to scale a CPUE to the relative area it represents.

Describe alternatives you have considered

force users to remember to zero-center their env data, but even zero-centering is an incomplete alternative to allowing for an offset parameter.

Statistical validity, if applicable

bias will be created if a non-zero centered env index is used

Describe if this is needed for a management application

bias will be created if a non-zero centered env index is used

Additional context

No response

iantaylor-NOAA commented

Good to see this moving forward.

I wanted to note that I think the alternative of zero-centering the env data isn't necessarily a comparable solution anyway because the period of devs that are being informed by the index might not be zero-centered themselves. That is, you might have an index of recruitment deviations which you believe provides information on the relative strength of individual cohorts. If it's applied to a recent period where the other data sources suggest that recruitment was below average, a zero-centered index will pull them up if there's not an offset parameter available to make the scale of observed and expected line up. In some cases, we may want that pulling effect, in which case the offset could be fixed at 0.