Who will lead the topic?

@iantaylor-NOAA

Topic description

How will authorship be determined in FIMS and where will "authors" (however they are defined) be listed?

Topic background

I noticed that @ChristineStawitz-NOAA is listed as "maintainer" on the FIMS landing page https://noaa-fims.github.io/FIMS/ (with all members of the team listed as "author"). The maintainer designation comes from the presence of "cre" on this line.

Topic outline

• Where do we often think about authorship with respect to FIMS
  • presentation authorship order and list,
  • R package authorship (i.e., creator, maintainer, contributor),
  • advocator for continued support in terms of national funding, etc.
  • idea contributor
  • code contributor
• What do individuals who are acknowledged as authors get in return?
  • Acknowledgement of contributions
  • A potential desire to continue their support of the project
  • Recognition on for their Performance Plan
  • Creating points of contact
  • <fill in more?>
• What types of authorship should be documented/standardized and published for people to clearly see?
  • Where should the authorship list(s) live?
  • What is the goal of including people in the DESCRIPTION file?
  • How much of a contribution must one give to the code to be listed on the DESCRIPTION file? Should all current and past members of the FIMS implementation team be listed as authors?
  • Will individuals that are no longer contributing still be listed?
  • What happens when someone changes their GitHub user name, is that something we even need to worry about?
  • Should the project lead always be listed as maintainer?
  • When folks outside the FIMS implementation team create pull requests that get merged in the future, do they get added to the author list?
  • How is authorship decided upon for presentations?

Topic resources

• Info on the Authors@R field used in the DESCRIPTION file of R packages
• Example of R package format in use at stan
• Examples authorship lists that don't follow R package format and have more nuance
  • https://mc-stan.org/about/team/
  • https://www.r-project.org/contributors.html

Who will lead the topic?

kellijohnson-NOAA

Topic description

NOAA-FIMS/FIMS #638 brings to light that there is an option to set proportion female to the user but it does not seem to propagate forward to the model.

Topic background

1. If the user thinks that they are setting something they should be able to, thanks to @KyleShertzer-NOAA for bringing this to our attention.
2. This seems like a simple bug to fix given that @msupernaw and @Andrea-Havron-NOAA already came up with exactly where to fix it in the code, i.e., population.hpp, but some more thought into what it actually means for the code base should be thought about. E.g., will the derived quantities be reporting the correct values if the input value is different than 0.5 and should this be an estimated parameter?

Topic outline

• Decide if we want users to be able to set proportion_female
  • If proportion_female is different than 0.5 will the codebase break?
  • Set up live share and make the necessary changes
• Should proportion_female be estimable in the future?

Topic resources

• NOAA-FIMS/FIMS#397
• NOAA-FIMS/FIMS #638
• population.hpp initialize()
• population.hpp prepare()

Who will lead the topic?

kellijohnson-NOAA

Topic description

Some rules need to be created for how to name parameters and derived quantities in the source code and R/json output.

Topic background

With so many developers (current and future) we want to ensure that the naming scheme used in the source code is consistent and understandable to those outside of the project. This is not possible if guidance does not exist. The R interface group started making a list of rules and found that the more people we talked to the more those rules developed/changed because of things that we did not think of. We would like to go over our proposed set of rules and finalize this list before @peterkuriyama-NOAA starts making changes to the source code next week.

We believe that it is important for the names in the source code to match the names in the R/json output to allow users to search the source code based on what they are finding in the output. Therefore, the priority is not to create names that are pretty in figures and tables. Instead of having parameter symbols as names in the code, the R output group will create converters, e.g., steepness to h.

Topic outline

• Overview of current rules
• Make decisions where they are needed
• Discuss how to choose symbols to represent parameters

Topic resources

• excel spreadsheet with rules
• GitHub for fishdictionary

Who will lead the topic?

ChristineStawitz-NOAA

Topic description

Get feedback on the Figures and Tables in the FIMS manuscript.

Topic background

@ChristineStawitz-NOAA please feel free to edit this comment to describe the necessary background.

Topic outline

• Review Figures
• Review Tables
• Create next steps

Topic resources

• FIMS paper message (figs and tables) (only NOAA employees can access the link)
• full FIMS manuscript (only NOAA employees can access the link)

Who will lead the topic?

Bai-Li-NOAA

Topic description

Interact with prototypes for simplifying the R interface. Think of the way that we currently interact with a FIMS model as the "power user" way and we are trying to create a general user way. Maybe in the future we will have a even more simple beginner user way.

Topic background

Currently it takes ~300 lines of code to run a FIMS model and it is not clear what you need to set unless you know. 🤯 you don't know what you don't know 🤯 which makes it difficult for new users to change modules, if we had different modules. The R interface group is busy prettying up the output so @Cole-Monnahan-NOAA and @Bai-Li-NOAA have been working on simplifying the R input. Here is your chance to give feedback 📣 .

Topic outline

• Overview of current practice.
• Proposals
  • Arguments of lists or many arguments for each input
  • Process method versus fleet method
• What this means for running a complex set of models

Topic resources [Edited]

• Comparison of three options for organizing parameters within an individual function
• Current practices for setting up FIMS inputs
• By-process approach (R functions)
• By-fleet approach (R functions)
• Comparison of multiple approaches for setting up FIMS inputs

@Cole-Monnahan-NOAA and @Bai-Li-NOAA please feel free to edit this comment to edit the issue as you see fit.

Who will lead the topic?

kellijohnson-NOAA

Topic description

How to model discards in FIMS.

Topic background

Yesterday in the Implementation Team Meeting we talked about how discards are currently modelled and what discard data looks like but we did not decide how to move forward with discards in FIMS. This topic needs to be discussed further to create a clear path for how FIMS will model discards in M3.

Topic outline

• Proposals on how to model it by
  • @iantaylor-NOAA
  • @nathanvaughan-NOAA
  • @KyleShertzer-NOAA
  • @cmlegault
  • @JonBrodziak
  • @msupernaw
  • @kellijohnson-NOAA
• Pros and cons of each method

Topic resources

• Implementation Team Notes
• Kyle's paper
• National Standard 9

Who will lead the topic?

No response

Topic description

S4 classes in R are used for the input and output of FIMS and it would be great if more people understood their role in an R environment.

Topic background

S4 classes was a topic that only a few FIMS Implementation Team Members understood when polled during an Implementation Team Meeting.

Topic outline

Topic resources

Who will lead the topic?

@Andrea-Havron-NOAA

Topic description

What is TMBad and how is it different than using CppAD?

Topic background

NOAA-FIMS/FIMS#210 discusses some initial pros and cons of moving to TMBad from CppAD within TMB. The move will require changes in the C++ portion of the FIMS code. See a comment in FIMS#210 for a list of changes required.

Topic outline

• What is TMBad
  • Initiated with TMB 1.8.0 (2022-03-07)
  • see ?TMB::compile
• What is CppAD
• What are the benefits of staying with CppAD
  • Widely used by more than just TMB
• What are the benefits of moving to TMBad
  • faster computations with certain hessian structures that do not meet the usual sparsity requirement by clipping the tape
  • More advancements are happening in TMBad
  • more readable than CppAD.
  • intern=TRUE allows for the entire Laplace approximation (including sparse matrix calculations) to be done within the AD machinery on the C++ side and provides an autodiff hessian (obj$he) wrt the fixed effects but can only be done using TMBad; consider also compiling with supernodal=TRUE to get performance comparable to R’s matrix calculations.
  • Bias correction is faster due to some rank-reduced thing
  • At some point, Kasper will deprecate the use of CppAD and then we will need to switch
  • Reduced amount of code in RCPP interface
• Drawbacks of CppAD
  • TMB is not kept up to date with the latest version of CppAD, TMB uses a static version of CppAD from 2015
• Drawbacks of TMBad
  • random effects are no longer visible in the model environment which may break assumptions on the layout of internal vectors (par, last.par) if intern = TRUE
  • Requires users install TMB 1.8.0 and higher but we already require that
  • Model debugging becomes harder when calculations are moved to C++

Topic resources

• CppAD
• Compiling instructions for TMBad

Who will lead the topic?

kellijohnson-NOAA

Topic description

Understanding how {usethis} templates work is a first step to creating a template to implement a new module in the C++ code.

Topic background

Previously there was a template written in R that called cat() statements called FIMS::create_rcpp_interface_object(). See issues NOAA-FIMS/FIMS#390 and NOAA-FIMS/FIMS#588.

Topic outline

Topic resources

Who will lead the topic?

kellijohnson-NOAA

Topic description

Some of the guidance in the collaborative workflow website that could suggested/enforced using Git hooks. I would like to explore the use of Git hooks for FIMS.

Topic background

When writing a commit message I do not always remember the cheat sheet for how to create a good commit message from Conventional Commits. We could create a new default commit helper message that reminds people of this guidance when they are writing their commit so they would not have to look it up.

Topic outline

• What are Git Hooks
  • Client-side hooks: work on local machines when using git but cannot be enforced through version control, i.e., individual users must set them up
  • Server-side hooks: work on the GitHub server but must be used on GitHub Enterprise and have to be configured by the administrator because there could be security risks involved.
• Where would hooks be useful for FIMS
  • Commit message help
  • Check that main was not merged into a branch
  • Commit message check
• Why will hooks be difficult to implement
  • Client-side hooks are not auto enforceable
  • Server-side hooks will make people 😠 when their commits cannot be pushed and have to be approved and turned on at the Enterprise level
• What else can be done
  • git merge --ff-only <some branch> to require that the branch you are merging from is rebased on the target before you merge, otherwise it will fail.

Topic resources

• Git hooks
• Git hook documentation
• Git hooks Atlassian
• githooks.com
• Collection of git hooks on GitHub
• Conventional Commits
• Conventional Comments
• Example hook file to stop merges

Who will lead the topic?

kellijohnson-NOAA

Topic description

Talk about how and where to move guidance in the collaborative workflow that is larger than FIMS so the collaborative workflow can be more focused on FIMS-specific guidance.

Topic background

• Currently, the collaborative workflow is large and contains a lot of guidance that would be useful for people outside of FIMS, e.g., how to set up VS Code.
• Recently, @Bai-Li-NOAA mentioned that the workflows project that she is leading would benefit from having a collaborative workflow guide as well. I would hate to see her have to maintain both of these efforts when there is a high amount of overlap in the content and the people involved.
• Some of the information in the collaborative workflow could be decreased to links rather than explanations.

Topic outline

• What do people like about the collaborative workflow?
• What do people use the collaborative workflow for?
• If we were to break it up, where would you like to see the NMFS-level information moved to?
• Are you interested in working on moving information if we agree to do so?

Topic resources

• collaborative workflow website
• collaborative workflow GitHub repo

Who will lead the topic?

Cole-Monnahan-NOAA

Topic description

A short tutorial on how to simulate data in TMB.

Topic background

Functionality to simulate with FIMS is coming in M2 so it would be good to have a basic understanding of how to use the simulation capacity of other simpler TMB models before users start to dive into simulation with FIMS.

Topic outline

• Features of simulation with TMB
• Examples of how to simulate data with TMB

Topic resources

• Documentation for simulation with TMB
  • It would also be good to know how Kasper created this page on the documentation using doxygen because it is more like an essay but still available within the same website as the C++ documentation.
• TMB sam example