Timing of calculations and data availability in FIMS

[ChristineStawitz-NOAA]

In the Yellowtail Flounder case study, @cmlegault calls out that calculating index and SSB calculations and weights at mid-year intervals is needed for consistency with the ASAP model

Describe the solution you would like.

Flexibility to use timing beyond doing all calculations at the start of the year

Describe alternatives you have considered

We could do somewhat fuzzy timesteps e.g. placing things within a quarter of the year rather than a user-specified fraction.

[iantaylor-NOAA]

SS3 has lots of flexibility on timing, with options for seasons and subseasons and different settings for timing of surveys at a single point in the year and fisheries as potential continuous. See https://nmfs-ost.github.io/ss3-doc/SS330_User_Manual_release.html#subseasons-and-timing-of-events for some info.

Casal2 likewise appears to be quite flexible as illustrated in this figure from the Casal2 Age-based User Manual: https://github.com/NIWAFisheriesModelling/CASAL2/raw/master/Documentation/UserManual/CASAL2_Age.pdf

However, I'm not yet convinced that the benefits of that flexibility offset the potential confusion associated with what those options do. For instance, how much does it help to allow 75% of mortality to occur prior to calculating the expected value of an index if the associated expected age or length composition doesn't align with that point in time? If you're also updating the expected numbers at age then you might as well just have a quarterly time step.

A simpler approach that we could consider would be as follows:

• associated all calculations with only the beginning or middle of each time step (typically 1 year)
  • this would facilitate comparison with ASAP and SS3 and any other platform with mid-year calculations
• be flexible on how many time steps occur within the year so that stocks with faster dynamics can have shorter time steps
  • there has been discussion within FIMS about allowing a mixture of time steps within a model (e.g. annual steps at the beginning and quarterly or monthly for periods in recent years when the data are better)

If there are studies supporting more complex timing setups, I'm happy to change my mind. We could also conduct new research if needed to inform these questions, but if that's the case, I would suggest that FIMS starts with simple on timing and adds complexity when it is clearly justified.

[cmlegault]

Here in the Northeast, we have a long history of using timing within the year to reflect changes in the population. This is probably due to the large changes in fishing mortality rate that have been seen within the time series of many assessments (order of magnitude changes). So we tend to focus on the timing of the surveys when fitting them and the timing of SSB when calculating it. We do use quarterly or half-year age-length keys when deriving the catch at age, but then combine the catch over the year instead of breaking it out into timesteps within the year. This probably has more to do with historical precedence than an actual argument that annual time steps are better than shorter time steps.

I would put it back to @iantaylor-NOAA , why not allow the timing of surveys and calculation of SSB to be at any user input time of year? It is an easy calculation, easy to explain, and addresses one source of potential bias when F varies considerably during the time series. I agree that adding the complexity of within-year time steps creates a lot of added burden on data compilation and model definition that may not be warranted.

[msupernaw]

I recall before we started coding anything in FIMS, we had a timing toy example. I'll see if I can dig it up, it may be useful here.

[msupernaw]

Not sure, but this <https://github.com/NOAA-FIMS/m1-prototypes/blob/main/fims_indexing.cpp> may have been the timing example from a few years ago.

[iantaylor-NOAA]

@cmlegault, I think you're suggesting that instead of beginning and middle of the year or time step (e.g. Jan 1 and July 1) for all the calculations as I suggested, the user could specify for example SSB calculated on Feb 1 and survey biomass on Aug 1 if that provides a better match to the biology and survey timing. That seems reasonable to me. We just need to be explicit about what calculations incorporate that timing and which, if any, don't. Or if we make all the calculations having flexible timing, it would be good to explore better the tradeoffs of calculating values at many times of the year vs keeping things simpler.

My concern is about both the potential computational burden (having to calculate and keep track of numbers-at-age and/or the distribution of length-at-age at many different points in the year) or the potential conceptual mismatch (having users believe that the input for survey timing accounts for growth within the year when in fact the same weight-at-age or length distribution is used regardless of the input value).

[msupernaw]

Good points Ian. Not sure if it helps, but in MAS we had scalar values like survey_fraction_year, catch_fraction_year, and a few others. We interpolated the empirical weight at age data to match the all necessary fractions of the year and carried out the calculations and used those results as the model timestep derived value. So the calculation was carried out at the fraction of the year and stored at the general model timestep index, if that makes any sense. Those fractions could all be different and any calculation using the weight at age data used the appropriate whole number age plus the fractional age amount which was stored in a hash table with a key equal to whole number age plus the fractional age. Of course, MAS also accepted fractional ages as input, but it was never tested that way except maybe the first age group being 0.1 rather than zero. This method seemed to work fine without the computational burden you mentioned above. I'm sure there are trade offs though, but this seemed to alleviate the need for any complicated bookkeeping.

[cmlegault]

Thanks @iantaylor-NOAA, your summary captures my point more clearly. We input multiple weight at age matrices to allow for the different timing of event during the year. This is similar to what @msupernaw suggested, but puts the onus on the user to determine the appropriate weights at age for the different timings. Having the user enter different weights at age matrices makes it quite clear that growth differences can/should be accounted for when using the different timings.

[JonBrodziak]

Seasonal differences in mean weights at age can be readily accounted for in annual models. I suggest we move forward with a simple approach for M2, providing for an annual within-year mortality adjustment for observations. As suggested, this is not really that complicated to code. More detailed observations for seasonal model structures could be developed for future milestones.

[iantaylor-NOAA]

Discussion during seaside chat today agreed that there would be value in doing some simulation analyses with existing platforms to explore the benefits and impacts of different options for timing and seasons. Existing platforms may not be able to provide useful information on the speed/efficiency of these features in FIMS, but they could show us the impacts of finer or courser timing of calculations for mortality, weight-at-age, or growth modeling.

[Rick-Methot-NOAA]

Detailed timing is most important when:
(a) short duration, high F fishery happening shortly before a survey
(b) model is using length data for a fast-growing fish so the time of year at which the model length-at-age is evaluated becomes very important to get the modes to line up.
SS3 put a lot of coding into version 3.30 to achieve better capability for (b). This included introduction of a subseason concept so that the growth could be evaluated only when needed. With 2 subseasons, growth was evaluated at the beginning and midpoint of each season. With more subseasons there was potential for more growth evaluations, but only if there was a survey that occurred close to that point in time in that year. For example, 12 subseasons in an annual model would allow for calculation of growth every month, but would only do so if some survey had an observation that month. Even so, with time-varying growth interacting with detailed seasonal timing there will be high computation load.
SS3 reads survey observation timing as year, real_month. Then interpolates that point in time to a particular season and subseason when it reads the input. This provides much more flexibility than reading year, season as the timing for a survey.

[ChristineStawitz-NOAA]

This simulation analyses could be a good project for the FIMS R&D contract hire. We need to decide before that is included if we want to make any progress on this in M2.

[Rick-Methot-NOAA]

Back to Ian's suggestion to just use more seasons. The downside of that is that it generally requires all data to be subdivided by those same seasons, which could be difficult for some of the fishery data.

[kellijohnson-NOAA]

On this topic of timing, we need to make some immediate decisions about weight at age for the beginning of the year after the last fish is caught, i.e., we always report spawning biomass on January 1 after the last catches occur. In a branch, dev-hake, we have implemented time-varying weight-at-age instead of averaging over all years for each age if the user provides that data. This led to spawning biomass on January 01, end_year + 1 to be 0 for all ages because the user only inputs weight-at-age information for start_year to end_year so the model assumed that fish weighed 0 tons in end_year + 1. What do we assume the weights of fish are for this end_year + 1 calculation?

• Enforce the user to put in weights for end_year + 1
• Use the weights from end_year

"Write a reply" to this comment rather than typing in the "Add a comment" box so we can keep track of the responses better.

[kellijohnson-NOAA]

I am leaning towards enforcing the user to put in weights in their data for end_year + 1 and we can change the R wrappers that determine the end year to not look at the weight-at-age type of data in the data inputs when determining the end year of the model. We could then, just repeat the last year's weights for end_year + 1 if they are not provided but provide a clear message to the user that is what is happening.

[nathanvaughan-NOAA]

I agree, it seems easier to require values for every year now than to use workarounds that will break down later and confuse users.

If we do want to allow for it to be missing in the future, we should develop a generic approach for handling potential missing values in any model year (and for any parameter as this effects anything we want to be time varying). It seems like a random effects style solution where the mean/variance of the years with values informs the missing years is the most reasonable. We need to figure out how to do that though when you want the years with values to be constant and or fixed effects and are probably backing in a trend if you were motivated enough to make the parameter time varying.

For now lets leave it up to the user to figure out by making them enter the values :)

[Rick-Methot-NOAA]

you will need weights for endyr+1 for projections, so I recommend starting now to require them.
I hope there is another branch looking at user-specified spawn-date which is a common feature in other models.

[Rick-Methot-NOAA]

SS3 protocol for years with missing wt-at-age:
when the year value is negative, use that year's wt-at-age vector to fill forward from that abs(year) to endyear of projection. Then any subsequent year-specific reads will overwrite that fill.

[nathanvaughan-NOAA]

That could work for missing values in the historic period as well!

[kellijohnson-NOAA]

Thanks to @Rick-Methot-NOAA for comments on how timing plays into estimation of growth in SS3

1. Growth2: get mean size-at-age at beginning of next period for each growth entity
2. In season growth3: get mean size-at-age at time of each observation in this period
3. ALK: get ALK for each entity at that point in time
4. FishSel: get ALK for each fishery at the midpoint of each season, then combine length selectivity and ALK to get the mean age selectivity for each fishery for use in the fishing mortality calculations
5. Get F at age/fleet and Z at age/fleet for this area and time step
6. Expected values: for each time step and each area with an obs(s): combine Numbers-at-age (at time of the observation using Z-at-age) and ALK to get the population that will be exposed to fishery and survey observations
7. Also, at the time of spawning, get the numbers-at-age and ALK for that time point
8. Expected values: for each fleet & survey with an obs: apply the age and length selectivity to the Numbers-at-age to get the selected age-length structured matrix for each growth entity for each fleet/survey
9. Then, for each type of observation (e.g. total survey abundance, age comp, length comp, etc.) extract expected value, which often will include summing across some/all growth entities. For example: length composition by sex will sum across platoons, morphs and settlement events, but not across sex.