[FEATURE] Setup skeleton of .hpp file structure in inst/include

[Andrea-Havron-NOAA]

Is your feature request related to a problem? Please describe. The FIMS model will primarily be defined using a number of .hpp files organized in the inst/include folder. The current FIMS R package requires a base skeleton of .hpp files to initiate code development.

Describe the solution you'd like Create a skeleton of .hpp files for the inst/include file structure

Describe alternatives you've considered We have considered a standalone TMB model that is not dependent on .hpp files

Describe a reference describing the statistical validity of this approach n/a

Describe if this is needed for a management application FIMS will operate as a modular, maintainable, and extensible software system. The .hpp file structure will help acheive this objective.

[Andrea-Havron-NOAA]

@msupernaw and @ChristineStawitz-NOAA, should survey and fleet be separated into two .hpp files or should there be one fleet.hpp for both?

[JonBrodziak]

Surveys and fleets have been treated as one similar object structure in some assessment models. This has been a useful first order approximation, ignoring the heterogeneous nature of fishing vessel operations as a survey sampling data source. But we want the linkage to be explicit and realistics and socioeconomic outputs and metrics. Fundamentally a fleet generates information that can be viewed at an aggregate or individual vessel level and individual-based modeling of fleet dynamics would be a good and realistic extension of stock assessment modeling. Surveys are also going to be different that fishing fleet operations in a lot of details and it would be good for realism and generality to separate the two. That is not to suggest that fleets cannot be treated as producing standardized abundance indices. It is simply that the types of scientific surveys that can be conducted is changing with technological advances. It would be "cleaner" to keep surveys and fleets separate but note that there will be some similarities in the observational data that can be generated from both. But I want to reemphasize that fleet objects can be linked to other quantities of interest for economic and social metrics of fishery system performance. New survey types are eDNA and other genetic approaches close-kin MR as well as AUVs, which do not seem to have a natural linkage to socioeconomic benefit streams which are something we should strive to include in the assessment modeling system for supporting EBFM, IMHO. Thanks, Jon

On Wed, Mar 2, 2022 at 3:53 PM Andrea-Havron-NOAA @.***> wrote:

@msupernaw https://github.com/msupernaw and @ChristineStawitz-NOAA https://github.com/ChristineStawitz-NOAA, should survey and fleet be separated into two .hpp files or should there be one fleet.hpp for both?

— Reply to this email directly, view it on GitHub https://github.com/NOAA-FIMS/FIMS/issues/10#issuecomment-1057580297, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACVXIZXEFWBF4LUK66JTOSTU6ALQLANCNFSM5PYZWPEQ . 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: @.***>

-- Jon Brodziak, Ph.D. NOAA Inouye Regional Center Pacific Islands Fisheries Science Center 1845 Wasp Boulevard, Building 176, NMFS/PIFSC/FRMD Mail Room 2247 Honolulu, Hawaii 96818 USA Phone: 808-725-5617 Email: @.***

“Wherever my travels may lead, paradise is where I am.” ~ Voltaire

The views expressed in this message are my own and do not necessarily reflect any position of NOAA.

[iantaylor-NOAA]

Jon makes some good points, but I think the diversity within the set of survey and fishing fleet configurations that we may eventually support is greater than the distinction between those two groups, so rather than repeat a bunch of code within the two separate files, it would be better to have a single file with flexibility to turn on and off various elements. For instance, I think it should be easy to avoid calculating socioeconomic benefits for a fleet with zero catch.

Then again, I don't fully understand what these files contain, maybe they would just contain the non-shared elements of the treatment of fishing fleets and surveys.

Lastly, I will note that my memory is that the removal of the separation between fishing fleets and surveys in Stock Synthesis was driven less by coding efficiency and more by making it easier for folks to add or subtract fleets from the model. In older versions, all fishing fleets had to come first, followed by surveys, which meant that adding a fishing fleet required changing the fleet number associated with all the survey inputs. Thus, I think more important than the question of how the files are structured is the user experience of designating what's a fleet or survey.

[msupernaw]

I think we should have the survey class inherited from the fleet class and add the "q" term as a member variable. They can stay in the same .hpp file.

On Thu, Mar 3, 2022 at 12:02 PM Ian Taylor @.***> wrote:

Jon makes some good points, but I think the diversity within the set of survey and fishing fleet configurations that we may eventually support is greater than the distinction between those two groups, so rather than repeat a bunch of code within the two separate files, it would be better to have a single file with flexibility to turn on and off various elements. For instance, I think it should be easy to avoid calculating socioeconomic benefits for a fleet with zero catch.

Then again, I don't fully understand what these files contain, maybe they would just contain the non-shared elements of the treatment of fishing fleets and surveys.

Lastly, I will note that my memory is that the removal of the separation between fishing fleets and surveys in Stock Synthesis was driven less by coding efficiency and more by making it easier for folks to add or subtract fleets from the model. In older versions, all fishing fleets had to come first, followed by surveys, which meant that adding a fishing fleet required changing the fleet number associated with all the survey inputs. Thus, I think more important than the question of how the files are structured is the user experience of designating what's a fleet or survey.

— Reply to this email directly, view it on GitHub https://github.com/NOAA-FIMS/FIMS/issues/10#issuecomment-1058264453, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFUSEHU2LZRWMMED3PYQHDU6DWABANCNFSM5PYZWPEQ . 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 were mentioned.Message ID: @.***>

-- Matthew Supernaw Scientific Software Developer National Oceanic and Atmospheric Administration Office Of Science and Technology NOAA Fisheries | U.S. Department of Commerce Phone 248 - 396 - 7797

[Andrea-Havron-NOAA]

Thanks @JonBrodziak and @iantaylor-NOAA for your input. Jon, that is a great point and good for us to be thinking about extensibility while we set up this initial file structure. I was thinking more in line with Ian - should we set up a generic fleet module that can interact with the selectivity module and potentially an economic module when we design one? I ask due to the wording in the M1 model specification section of the collarborative workflow document:

The product will be an age-structured integrated assessment model with two fleets (one survey, one fishery) and two sexes.

[JonBrodziak]

Yes, it may be useful to keep the simplification of approximating surveys as fleets, especially for trying to be concise in coding of the estimation model. But I also would add that we want the FIMS to be able to do MSEs and in that context being more realistic with the simulation of the two object types, fleets and surveys, in an operating model will be simpler with separate treatments. People have already developed agent-based models for individual vessels within the Hawaii longline fleet, for example, for choice of fishing pattern under different conditions. This is the type of realism that could be propagated into an operating model for testing alternative estimation and management approaches.

On Thu, Mar 3, 2022 at 7:02 AM Ian Taylor @.***> wrote:

Jon makes some good points, but I think the diversity within the set of survey and fishing fleet configurations that we may eventually support is greater than the distinction between those two groups, so rather than repeat a bunch of code within the two separate files, it would be better to have a single file with flexibility to turn on and off various elements. For instance, I think it should be easy to avoid calculating socioeconomic benefits for a fleet with zero catch.

Then again, I don't fully understand what these files contain, maybe they would just contain the non-shared elements of the treatment of fishing fleets and surveys.

Lastly, I will note that my memory is that the removal of the separation between fishing fleets and surveys in Stock Synthesis was driven less by coding efficiency and more by making it easier for folks to add or subtract fleets from the model. In older versions, all fishing fleets had to come first, followed by surveys, which meant that adding a fishing fleet required changing the fleet number associated with all the survey inputs. Thus, I think more important than the question of how the files are structured is the user experience of designating what's a fleet or survey.

— Reply to this email directly, view it on GitHub https://github.com/NOAA-FIMS/FIMS/issues/10#issuecomment-1058264453, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACVXIZRRZWCTE5TEOH5GVKLU6DWADANCNFSM5PYZWPEQ . 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 commented.Message ID: @.***>

-- Jon Brodziak, Ph.D. NOAA Inouye Regional Center Pacific Islands Fisheries Science Center 1845 Wasp Boulevard, Building 176, NMFS/PIFSC/FRMD Mail Room 2247 Honolulu, Hawaii 96818 USA Phone: 808-725-5617 Email: @.***

“Wherever my travels may lead, paradise is where I am.” ~ Voltaire

The views expressed in this message are my own and do not necessarily reflect any position of NOAA.

[ChristineStawitz-NOAA]

I think it makes sense to keep them in the same .hpp file. I like Matthew's suggestion of a parent class and inheritance so we can share any duplicated components by implementing them in the parent class. I think we will end up with some functions that are both survey specific (e.g. q) and fishing specific (e.g. unique fishing fleet scenarios like recreational) so having one .hpp file with a parent class and two child classes seems good but let's not add the children until we have differences we need to implement.