ss3-source-code
ss3-source-code copied to clipboard
create comprehensive approach for survey Q and parm dev link functions
Imported from redmine, Issue #12352 Opened by @RickMethot on 2015-10-08 Status when imported: Under Review
Have already changed specification of special selectivities (e.g. len selex=30 to 37) from the len selex input section to the survey units section of the data file.
Next need to modify the Q_power option to be a entry point for entering a variety of link functions
Need to decide whether to require 3 parameters (intercept, slope, power) for all link functions, or to make the N parameters specific to the requested function.
proposed set of links is: Code Function 1 Y=qX 2 Y=a+qX 3 Y=a+q*(X^(1+c)) 4 ln(Y)=ln(q)+ln(X) 5 ln(Y)=ln(q)+(1+c)ln(X) 6 Y=q(X-Xbar) 7 Y=a+q*(X/Xbar)^(1+c) 8 Y=qX/(a+X) 9 Y=a/(1+exp(-q(X-Xbar)) 10 Y=a+b*ln(X)
comment from @RickMethot on 2016-04-20: From Rick:
matrix Q_setup(1,Nfleet,1,5) 1 do power, 2 env-var, 3 extra sd, 4 devtype(<0=mirror, 0=float_nobiasadj 1=float_biasadj, 2=parm_nobiasadj, 3=rand, 4=randwalk, 5=set parameter equal to the scaling coefficient so can then have a prior) 5 Q offset fundamentally, do power and devtype could be replaced by a link designator; and the Q offset need not be mandatory; instead it is just one possible added parameter depending on the link function that is chosen
Proposaed New Q_setup 1: fleet index number - by specifying this we do not need input for all fleets, only those that have survey data 2: link type 3: 0/1 to select extra sd parameter 4: 0/1 for biasadj or not 5: 0/1/2 to float q: where 0 means not float (old option 2), 1 means float in phase 1 only, 2 means float continuously (old option 5)
So, the q parameter will always show up in the list of parameters as long parameter lines As a long parameter, it can invoke additional parameters to implement: block/trend, env linkage, and mean-reverting random walk (invokes 2 parameters for the stddev of q and rho for autocorrelation)
The family of possible link functions needs flexibility because the survey obs could be a time series of an environmental index, which could have + and - values and not be linear in relation to the model factor which could be abundance, dev vector, or a derived process parameter Link types, where "x" is a model quantity as selected by Svy_units: <=-1: mirror 1: proportional - y=qx 2: proportional with offset - y=q(x-a) 3: proportional with offset and power: y=q*(x-a)^c 4: logistic
QUESTIONS:
-
can q use any of the time-varying options and also float? I think it can if the time-varying component of q is separated from the component that can float or have a prior. e.g. y = q1q2x where q1 can float or have a prior and q2 starts with a value of 1.0 in the first year and can be time-varying after that
-
Is it feasible to allow the non-q parameters, e.g. a and c in list above or the env link parameter, to be time-varyin
comment from @RickMethot on 2016-04-22: progress on conversion of Q parms
- test with Q as parm, Qlink as power fxn, and float Q
- still need to test with env effect on Q, and to test mirror
- random devs approach currently is disabled
- still need to update ss_write.tpl to output the new format
- the new approach will create a q for any fleet with survey obs, even with the float option
- still need to revise ss_readctl_330 to be able to read the new format
- then need to create block/trend approach and dev approach like that for mgparm and selparm
New format is: //Q_setup for 3.30 // 1: link type // 2: extra input for link, i.e. mirror fleet // 3: 0/1 to select extra sd parameter // 4: 0/1 for biasadj or not // 5: 0/1 to float
but need to add another field with fleet id so that not all fleets will need to be read
the above info populates a fleet x 5 matrix with parameter index for each type of parameter needed Q_setup_parms(1,Nfleet,1,5) // index of first parameter for: 1=base q; 2=env; 3=block/trend; 4=dev; 5=extrastd;
current link functions are: // Link types // 1 simple q, 1 parm // 2 mirror simple q, 1 mirrored parameter // 3 q and power, 2 parm
comment from @RickMethot on 2020-08-25: consolidate and rename this issue