fleet-specific F method

[k-doering-NOAA]

Imported from redmine, Issue #53098
Opened by @RickMethot on 2018-07-25
Status when imported: In Progress

It seems advantageous to allow fleet-specific F method so that only fleets with high F will need to use F as parameters

[k-doering-NOAA]

comment from @RickMethot on 2018-12-18:
it would be useful to have fleet-specific controls for F_method, starting F value, and starting phase.

The code seems amenable to allowing for some fleets to do F as parameters and other fleets as hybrid,
but probably easiest to define all fleets to have F as parameters and then to just be fleet-specific for the phase in which estimation switched from hybrid to F_as_parameter

because this would require I/O change, do it as F_method #4. The I/O already is conditional on F_method, so this is easy

[k-doering-NOAA]

comment from @RickMethot on 2019-02-20:
The internal method for conversion of a list of F_parms to Hrate(t,f) is quite flexible. So it seems quite feasible to create a new F_method that does F as parameters for only certain fleets. Or a F_method that only does F as parameter for (f,t) with input catch exceeding a user-specified threshold.
In execution, hybrid F would be used for all in the early phases and then the selected Hrate(f,t) would switch to parms at a specified phase.

[k-doering-NOAA]

comment from @RickMethot on 2020-04-09:
Fleet-specific F_Method
Motivation:

1. bycatch fleets must use F_Method=2 (parameters), so use of any bycatch fleet currently precludes use of hybrid F for other fleets
2. F as parameter is most needed for high F situations, so good if could be restricted to high F fleets
3. Extending that logic, might be desirable to have F as parameter only after some fleet-specific start year

Plan is to allow for a new option #4 which will allow for fleet-specific switch for the phase in which switch
from hybrid to parameter occurs

Aside from the I/O, there need to be changes in:
SS_proced.tpl
Here the change is for the population of the Hrate(f,t) matrix from the parameter vector - F_rate(g)
Need a smart way to do this in a fleet and phase specific way that does not involve IF statements

SS_popdyn.tpl
here Hrate(f,t) is always used as the basis for the calculations
the values for Hrate are created here if hybrid is used, or have already been assigned in SS_proced
so the decision to calc the value via hybrid now needs to be fleet-specific.
it already is fleet-specific conditioned on fleet_type==1 because bycatch and survey fleets cannot do hybrid
so can switch to conditioning on F_Method(f)==3 for fleet-specific use of hybrid

also need to deal with logic around F_Method_Use. This drives the CASE statement for F_Method,
so probably need to retain this so that if any fleet uses hybrid in current phase it will uses this pathway,
else do all fleets as parameters

[Rick-Methot-NOAA]

New thought:
The identifier fleet_type(f) is already fleet-specific.
fleet_type is closely associated with F_method as fleet_type=bycatch requires F_method=2, and fleet_type=3 (survey) requires no F_method.
Also, there is desire for fleet_type=4=predators which would have its own unique F_method.

SO:
rather than create fleet-specific I/O for F_method, instead elaborate fleet_type(f) to have these options:
3=survey
11=Pope's
12.XX=F parameter with hybrid for early phases (allows for hybrid to be invoked for all or none phases, with X being the phase)
13=predator

Because there is much switching already that uses fleet_type(f) it may be good to read the new approach into fleet_type_rd(f), then parse it into fleet_type(f) using the old 1,2,3 codes and a new F_method(f)
@nschindler-noaa Neal - do you have ideas about this restructuring?

Note that there also is F_Method_use that implements the switch from hybrid to param for Fmethod 2. But in ss_popdyn, there are still some switches beginning at line 1363 below that are incorrectly referring to F_method itself:
897 // SS_Label_Info_24.3.3 #Do fishing mortality using switch(F_method)
902 switch (F_Method_use)
905 case 3: // hybrid F_method
1037 } // end hybrid F_Method
1039 case 2: // continuous F_method
1079 case 1: // F_Method is Pope's approximation
1081 // SS_Label_Info_24.3.3.1 #Use F_Method=1 for Pope's approximation
1159 } // end F_Method switch
1363 if(F_Method==1)
1603 if(F_Method==1) // Pope's approx
1740 if(F_Method==1)
1776 if(F_Method>=2)
1793 else // F_method=1
1863 if(F_Method==1)

Another point: need to deal with the I/O for input of of F_setup and F_setup2 which are detailed F inputs, etc.

[nschindler-noaa]

My thoughts aside from this being an input/output change To allow for greatest flexibility, use different digits for different purposes. First digit for the type of fleet and second for the method: e.g. 13 would be a fishing fleet using the hybrid method, 40 would be a predator with its unique method. Some combinations would not be allowed, so some checks would be needed. That way you can add fleet types and methods without needing to rewrite anything (except how to handle the new values). I think this would be simpler for the users as well.

On Mon, Jun 28, 2021 at 11:16 AM Richard Methot ***@***.***> wrote: New thought: The identifier fleet_type(f) is already fleet-specific. fleet_type is closely associated with F_method as fleet_type=bycatch requires F_method=2, and fleet_type=3 (survey) requires no F_method. Also, there is desire for fleet_type=4=predators which would have its own unique F_method. SO: rather than create fleet-specific I/O for F_method, instead elaborate fleet_type(f) to have these options: 3=survey 11=Pope's 12.XX=F parameter with hybrid for early phases (allows for hybrid to be invoked for all or none phases, with X being the phase) 13=predator Because there is much switching already that uses fleet_type(f) it may be good to read the new approach into fleet_type_rd(f), then parse it into fleet_type(f) using the old 1,2,3 codes and a new F_method(f) @nschindler-noaa <https://github.com/nschindler-noaa> Neal - do you have ideas about this restructuring? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#33 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARUZACRSVTUWENT24D6JF23TVC36HANCNFSM4TLVK7QA> .

-- Neal Schindler Programmer Analyst, Caelum NWFSC (206) 860-3407 cell (206) 909-0505

=(((`< >=(((`< >=(((`<

=(((`<

[Rick-Methot-NOAA]

Good suggestion Neal. Better than mine.

On further thought, I think it best to keep F_method consolidated in control file, so F_Method scalar input = 9 will then invoke fleet-specific F_method.
Noting that F_Method=1 must be applied to all or no fishing fleets, so this new flexibility will just apply to the fleets with F_method=2, 3, or predator

[Rick-Methot-NOAA]

A substantial revision to everything about Fparms and their indexing has been pushed.
Do not do a pull request yet.
It works for an example that uses Fmethod=2 and has a bycatch fleet (using cobia example)
lots of extra cout statements still need cleaning up.
Next step is to finish implementation of Fmethod 4 which will use the revised innards to allow for fleet-specific Fmethod.

[Rick-Methot-NOAA]

Got it.
Syntax looks like this to get F_Method 4, which I now consider a preferred option over 2 and 3.

4 # F_Method:  1=Pope; 2=instan. F; 3=hybrid; 4=fleet-specific parm/hybrid (#4 is recommended)
2.9 # max F or harvest rate, depends on F_Method
# for Fmethod 1; no additional F input needed
# for Fmethod=2; read overall start F value; overall phase; N detailed inputs to read
# for Fmethod=3; read N iterations for tuning for Fmethod 3
# for Fmethod=4; read list of fleets needing parameters; syntax is:  fleet, F_starting_value (if start_PH=1), first PH for parms (99 to stay in hybrid)
# for Fmethod=4; then read N tuning loops for hybrid fleets 2-3 normally enough
#Fleet start_F first_parm_phase
 1 0.05 2
 2 0.05 99
 3 0.05 1
 -9999 1 1
4 #_number of tuning loops for hybrid fleets; 4 good; 3 faster

It works well for a model (cobia) that once was Fmethod=2 for all fleets, one of which was a bycatch fleet.

[Rick-Methot-NOAA]

Realizing that the previous F_Detail feature should be retained for F_Method_4. It will be straightforward to allow it for F_Method 4.
Also note that the F_Detail feature reads yr, seas and if yr is negative it fills forward for all remaining years. But it does so for just that season, not all seasons. A user can compensate by doing Nseas entries to cover all of the seasons. While a -season entry might be used to invoke filling all seasons, I think I will leave it as is and document the current situation.

[k-doering-NOAA]

@Rick-Methot-NOAA , I hope you don't mind I edited your comment! adding three backticks before and after the input marks it as code, which means github markdown formatting won't be automatically be applied (the pound sign indicates a heading, the same as an h1 html tag).

Also, do you expect estimated F values to change for models using F methods 1-3 ?