search

nmfs-ost / ss3-source-code

The source code for Stock Synthesis (SS3).
https://nmfs-ost.github.io/ss3-website/
Creative Commons Zero v1.0 Universal
38 stars 16 forks source link

Fishery length comp data needs full season expected value #99

Open Rick-Methot-NOAA opened 4 years ago

Rick-Methot-NOAA commented 4 years ago

SS produces ALK that are a snapshot in time. It uses the mean and sd of length-at-age at a particular time. This is appropriate for surveys that typically are about 1 month in duration and often display distinct length modes. Matching these length modes closely does, though, depend upon using accurate input of the mean month of the survey and using multiple subseasons so SS can produce an ALK for a subseason close to that month. In practice, SS is inhibited from achieving such a good match for two reasons:

  1. Variation in settlement timing - the exact date a cohort initiates growth is essentially a process error that affects the effective age of a cohort with respect to the growth curve. We approximate this effect by having higher sd for length-at-age of young fish. But this only masks the real issue. With this higher sd the model creates a distribution that is broader than the distribution seen in data for any particular year.
  2. Season-long fishery data - The fishery length data do not come from a snapshot in time. They are collected throughout the season. For young, fast-growing fish, this means that the fishery data show less distinct size modes because the position of the mode is moving within the time period.

The solution for issue 1 begs for settlement timing to be a random effect. I do not see feasibility of doing this in SS.

For issue 2, I think we can get a better approximation for the fishery length data by combining ALKs. Currently, SS uses the midseason ALK for fishery data. But the ALK for beginning of the season is also calculated. My proposal is to average the ALK for beg, mid, and end ALK where the end ALK is simply the ALK for the beginning of the next season. Currently SS calculates the mean size for the beginning of the next season while processing the current season, but it does not calculate that ALK until the beginning of the next season. So implementation of this proposal will take a modification to the timing of these operations.

Rick

Rick-Methot-NOAA commented 4 years ago

For issue 1, probably best to keep settlement date constant (nightmare to code if settlement date as RE jumped into another season). Instead, use existing ability to do random devs on the size-at-settlement.