time of year for measurements

[kellijohnson-NOAA]

Should we specify when measurements are available? For example, should 2022 biomass be biomass at the start of the year if it is not explicitly stated when the measurement occurs?

[Bai-Li-NOAA]

It sounds good to specify when measurements are available and use start of the year as default. For example, BAM uses B.mdyr.age to represent biomass age comp from the middle of the year. Maybe biomass_month (e.g. biomass_jan) would help clarify the timing of the measurement? I wonder if including an info data list in assessment output RData/JSON to document the default timing for some measurements and default units for length, weight, biomass, ssb, numbers, and recruitment would help explain default values.

On Mon, Feb 28, 2022 at 9:01 AM Kelli Johnson @.***> wrote:

Should we specify when measurements are available? For example, should 2022 biomass be biomass at the start of the year if it is not explicitly stated when the measurement occurs?

— Reply to this email directly, view it on GitHub https://github.com/nmfs-fish-tools/data_dictionary/issues/7, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOJI36UXQ25AF2BCNFLKM3DU5N5Y5ANCNFSM5PRFL3NQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[chantelwetzel-noaa]

I had to think about this question for a bit. Existing stock assessment models often have at least start of the year and mid-year quantities and FIMS will surely also have this functionality. However, I would also likely expect the ability to calculate specific quantities are user-requested points in the season (similar to SS3) beyond just the start and mid-point in a year which could make having output names associated with time of the calculation messy (e.g., growthStart, growthMidYear, growthMonth3, ...). Given this I would opt to generally have output names explicitly state when the calculation occur but rather have them output in a way (matrix) that also specifies other factors in the calculations (year, season/time of year, area, sex, growth pattern). I could be swayed otherwise but in my mind this approach would seem cleaner.

[kellijohnson-NOAA]

Thanks @Bai-Li-NOAA I think having information regarding units and timing for terms is needed and I am trying to include them in my edits to top20.txt.

I agree @chantelwetzel-noaa with having explicit accounting of variables within a matrix to define when measurements occur rather than using names like GrowthMidYear. For FIMS and CASAL, this is really important because several configurations of timing are/will be available. For this issue, I am more thinking just about how they would be reported in a document. Can we assume that if the timing is not specified that the measurement comes from the very beginning of the time counter. If a user specifies the year the measurement came from but not any other information regarding the time period, then it is safe to assume that the measurement came from the very beginning of that time period, e.g., 2022 biomass is January 01, 2022 biomass, without needing to write out the full date?

[chantelwetzel-noaa]

Thanks for the clarification. I think having the default value reported for a quantity to be the start of the year would be fine. We may want to just add clarification that the quantity would be from the start of the "year" as defined in the model since I could foresee some model where start of the year does not align with the calendar.