Model helper functions

[bthe]

Tossing around a list of functions that would be nice to have/should be implemented. These would broadly fall into the following categories:

• Model manipulators:
  • locate_g3_actions, finds the position certain action in a model
  • update and discard actions, akin to gadget_update
• Initial conditions:
  • g3_mean_length_vonB, implement initial mean length at as Von Bertalanffy growth curve
  • g3_initial_numbers_by_age, initial number at age, one parameter per cohort, discounted by M and initial fishing mortality
  • g3_initial_numbers_constant, initial number at age, assuming constant recruitment, discounted by M and init F.
  • g3_initial_prop_at_age, logistic function by age indicating the initial proportion mature
  • g3_std_dev_length, parametric standard deviation in size at age.
• Model skeletons (is this a good idea? ):
  • g3_single_stock, define a single stock with all the "usual" bells and whistles
  • g3_two_stocks, define a immature and mature stocks with all the "usual" bells and whistles
• Projection functions:
  • manipulate recruitment/define spawning
  • projections fleet need to be defined
  • set up time projections
• Gadget fit

[lentinj]

Model skeletons (is this a good idea? )

I think so. At very least it'll become obvious quickly if they're too annoying :)

manipulate recruitment/define spawning

I'm still reasonably convinced that most actions should be considering projections out-the-box, and something that you set up when configuring the rest of the model. Manipulating already-existing models to bodge recruitment to keep working sounds like a pretty perilous approach IMO.

[bthe]

I'm still reasonably convinced that most actions should be considering projections out-the-box, and something that you set up when configuring the rest of the model. Manipulating already-existing models to bodge recruitment to keep working sounds like a pretty perilous approach IMO.

Yes, this is definitively something to think about, and the default should be to use random effects for all time-varying processes to base the projection.

The standard process is to fit model first, follow the big ICES rule book and determine the breakpoint in the hockey-stick function. Then use two or more spawning functions to run 1000+ projections some years into the future. In this case one could just estimate the parameters of the spawning functions, treating the deviations as random effects. This would actually solve two problems as it would also give you the error distribution for the projections.

[willbutler42]

For actions to consider projections out-of-the-box, perhaps having cur_year_projection defined if project_years = 0L would help? For instance, a spawning action could be incorporated into a non-projecting model and subsequently activated for projections using run_f = cur_year_projection... I assume this could be done by removing if (have_projection_years) on line 59 of action_time?

[lentinj]

@willbutler42 correct on all counts, removed the if statement.

[lentinj]

Remaining bits now in the issues above