PHOTO OF THE WEEK

This will be the last FIMS Weekly for a while as we test out using the GitHub Discussion Board to post weekly summaries. Using GitHub Discussions will allow everyone with a GitHub account to subscribe (or unsubscribe 🙁) to the specific GitHub Discussion Thread without requiring us to set up a list serve. The thread is called Project Updates and it exists in the Announcement section. Please navigate to the link and click ‘Subscribe’ if you aren’t already subscribed to all FIMS Discussions. See the image for where the subscribe button is located.

PHOTO OF THE WEEK

Just this morning I learned that issues associated with a milestone can be ordered to show users which issues will be worked on first. This should help communicate how work will be prioritized within FIMS.

PHOTO OF THE WEEK

Close-kin mark recapture (CKMR) was recently added to the Beaufort Assessment Model (BAM) for the assessment of red snapper, where DNA is used to identify family relationships or next of kin. The photograph below is a DNA sample of red snapper by Liam Kehoe, you can read about Liam’s story and view the photo on the Florida Sea Grant website. Liam Kehoe is a 2024 NMFS-Sea Grant fellow. Please let me know if you have ideas regarding CKMR and FIMS.

PHOTO OF THE WEEK

In the priorities presentation during the CIE Review, I presented the following image, which I found on a blog post titled Stop building what your customers ask for. In short, the blog post reminded me how it is not only our job to produce a product that is of use to fisheries managers but it is also our job to interpret what stakeholders see as a problem and imagine a solution potentially outside of a workflow that currently exists.

PHOTO OF THE WEEK

A recent PR came in that changes our spell checker from the one provided by ghactions4r, which uses {spelling}, to one that uses cspell and does not require installing R. This new action requires fewer words in the WORDLIST and will hopefully be easier to maintain given that we have both snake_case and PascalCase code. Locally, you can use the code below to learn more about cspell and how to check your files for spelling errors.

cspell lint --help

PHOTO OF THE WEEK

GitHub released a feature last week allowing users to sort their notifications on the web interface. You can look at all of your notifications by navigating to www.github.com/notifications; this interface is great for being able to turn off notifications for specific threads that you are not interested in or honing in on recent notifications from a certain repository.

PHOTO OF THE WEEK

Elizabeth and others worked a few weeks ago on editing an infographic to display user pathways. The work is now live on the FIMS organization website. Please feel to provide comments to Elizabeth if you have more ideas.

PHOTO OF THE WEEK

I finally figured out how to merge dev into main without changing all of the commit hashes and messing up all of the outstanding Pull Requests to dev. There is not an option within the GitHub user interface to do this. Instead, it must be done from the command line (see below). I think we are coming to a point in our development though where we can think about removing dev from our workflow and instead of letting features pile up in dev before they are released, we more thoroughly review them in their feature branches and release them directly to main rather than going to dev first.

git checkout main
git fetch -a
git rebase origin/main
git merge dev --ff-only
git push origin main

PHOTO OF THE WEEK

Version 0.9.0 has two breaking changes. (1) If you have time-varying weight_at_age data you can use it but you must make a decision for the beginning of the last year after catches. FIMS does not accommodate this need for an additional year of weight_at_age data you must decide if you want to put in an average or some kind of projection. But, if you do not have time-varying weight_at_age data you can input just a single year as a power user and everything will be taken care of. (2) All six m_*() functions have been renamed to `model_*(). Below we show how a power user can implement (1).

# A vector of weights for each age
weights <- 1:12
ewaa_growth <- methods::new(EWAAGrowth)
ewaa_growth$n_years$set(get_n_years(fims_frame))
ewaa_growth$ages$resize(get_n_ages(fims_frame))
purrr::walk(
  seq_along(get_ages(fims_frame)),
  \(x) ewaa_growth$ages$set(x - 1, get_ages(fims_frame)[x])
)
ewaa_growth$weights$resize(get_n_ages(fims_frame))
purrr::walk(
  seq(ewaa_growth$weights$size()),
  \(x) ewaa_growth$weights$set(x - 1, weights[x])
)

PHOTO OF THE WEEK

The tests for new convergence functions use a mocking structure so we can test the individual function without having to run a FIMS model. You can read more about mocking on the testthat github page. I think that mocking might be helpful for more tests in FIMS to increase coverage but keep the tests running fast.

test_that("check_sdreport_convergence() returns correct outputs for edge cases", {
  #' @description Test that `check_sdreport_convergence()` gracefully handles when summary extraction throws an error.
  obj <- make_mock_obj(random = 1)
  opt <- list(par = numeric())
  sdreport <- make_mock_sdreport(
    pdHess = TRUE,
    fail_on = "fixed"
  )
  register_mock_sdreport_summary()

  expect_warning(
    object = FIMS:::check_sdreport_convergence(list(), obj, opt, sdreport),
    regexp = "Unable to extract summary from sdreport"
  )
})

PHOTO OF THE WEEK

Bai recently experimented with using quarto to write a manuscript and found the template for Elsevier Journals easy to use. All the code is on GitHub and you can implement the template in your own repo with the following, single, line of code within a terminal. Quarto also provides templates for other journals and information regarding how to use templates on their website. Thank you Bai for sharing.

quarto use template quarto-journals/elsevier

PHOTO OF THE WEEK

While trying to find an example of rlang::arg_match() I came across the tidyverse design principles, which has some great content, and was reminded that many R developers do not know or understand match.arg() or rlang::arg_match(). These functions can be game changes when you want the options within a function argument to be clear to users and I believe that we should be using them more in FIMS. See a small example below and read the relevant section of design.tidyverse.org for more information.

# Base R function trimws uses match.arg() on the which argument
# both is the default
trimws
# function (x, which = c("both", "left", "right"), whitespace = "[ \t\r\n]") 
# {
#     which <- match.arg(which)
#     mysub <- function(re, x) sub(re, "", x, perl = TRUE)
#     switch(which, left = mysub(paste0("^", whitespace, "+"),
#         x), right = mysub(paste0(whitespace, "+$"), x), both = mysub(paste0(whitespace,
#         "+$"), mysub(paste0("^", whitespace, "+"), x)))
# }
# <bytecode: 0x0000024f9a563858>
# <environment: namespace:base>

trimws(x = " My bad formatting ")
# [1] "My bad formatting"

trimws(x = " My bad formatting ", which = "right")
# [1] " My bad formatting"

PHOTO OF THE WEEK

Our cheatsheet is now live in the FIMS package.

Why we use {renv}

Typically, when you install an R package, you are installing it into a central library that is accessible for all R sessions on that computer. This generally will work but what happens when you are working on a project with someone else and they write some code but when you try to run it on your computer it doesn’t work. You get a confusing error message and spend hours trying to debug it, only to realize you are using an older version of a package than they are and an argument has changed in a function. You update that package to the newest version and everything runs fine. But, the next time you work on a different project, you realize that you actually need the older version of that package. This leads to a lot of frustration and having to remember to install and uninstall different versions of r packages or having to change your code. As the {FIMS} ecosystem grows and we encounter or anticipate these and similar situations, we have begun incorporating {renv} into our workflows to address certain challenges. The {renv} R package is a package manager that tracks and records all R packages used within a project and creates a project-specific package library. It makes each of your projects their own isolated, portable, and reproducible environment that can be shared easily with others. In our experience, three challenges in particular pushed us toward using {renv} for {FIMSdiags} and the case studies. The three challenges we faced were:

1. Collaborating across different machines and operating systems
   
2. Managing multiple versions of {FIMS}
   
3. Integrating {renv} into automated environments

branch <- Sys.getenv("GITHUB_REF_NAME")
if (branch == "") {
  branch <- system("git rev-parse --abbrev-ref HEAD", intern = TRUE)
}
profile <- if (grepl("main", branch)) "default" else "dev"
Sys.setenv(RENV_PROFILE = profile)
source("renv/activate.R")

"postCreateCommand": "Rscript .devcontainer/setup.r"

# Restore the renv packages on container build
renv::restore(prompt=FALSE)

^renv$
^renv\.lock$

Takeaways

By incorporating {renv} into our workflows, we’ve tackled three challenges that are common in collaborative, multi-platform development: keeping environments consistent across developers and operating systems, managing multiple versions of an actively-developing dependency, and making all of this happen automatically so that developers and users can focus on the work itself. The result is a codebase that is easier to share, easier to reproduce, and easier to maintain as both projects continue to grow.

What is Code Club?

Welcome to the FIMS Code Club, where we don’t just build software; we build developers. Every month, we gather to tackle GitHub issues in a space where curiosity is more important than expertise. The FIMS Team provides the framework, but you provide the future. Our goal for these Code Clubs is to lower the barrier to entry so that every user feels like an owner, and every ‘newbie’ becomes a contributor.

[The FIMS Code Club is built on the idea that people matter more than pull requests.]

Join Us at the Next Session

You don’t need to be an expert to walk through the door. You just need to be curious.

• When: Monthly (Check the FIMS Calendar)
• Where: Virtual Breakout Rooms via Google Meet
• Tooling: We recommend having VS Code and the Live Share extension installed. Even if you don’t, you are still able to interact with the Live Share coding in your browser.

PHOTO OF THE WEEK

We are using copilot to help with some changes related to integers in C++ in [PR #1199] to remove many of the compiler warnings when you compile on a Windows machine. These warnings are helpful when developing and this effort will make it even more helpful because you will not have to sift through hundreds of non-helpful warnings to get to the ones that you want.

# old code
RealVector(Rcpp::NumericVector x, size_t size) {
  this->id_m = RealVector::id_g++;
  this->storage_m = std::make_shared<std::vector<double>>();
  this->resize(x.size());
  for (size_t i = 0; i < x.size(); i++) {
    storage_m->at(i) = x[i];
  }
}

# new code
RealVector(Rcpp::NumericVector x, size_t size) {
  this->id_m = RealVector::id_g++;
  this->storage_m = std::make_shared<std::vector<double>>();
  this->storage_m->assign(x.begin(), x.end());
}

PHOTO OF THE WEEK

In the dev-hake branch, we now have the ability to estimate parameters using a time-varying vector. Below is code to set the initial values and estimation type. We need to decide as a group what would be the best way for non-power users to interact with time-varying parameters.

# Resize the parameter vector
fleet_selectivity$inflection_point$resize(get_n_years(data_4_model))
# Set the initial value of each element of the vector to be one and
# estimate it as a fixed effect
for (ii in seq(get_n_years(data_4_model))) {
  fleet_selectivity$inflection_point[ii]$value <- 1
  fleet_selectivity$inflection_point[ii]$estimation_type$set("fixed_effects")
}

PHOTO OF THE WEEK

We have diagnostics thanks to Meg and Ian. Below is some sample code for running a likelihood profile over R_zero. Attend the tutorial on Thursday to learn more about {FIMSdiags}.

# data
data("data1", package = "FIMS")
data_4_model <- FIMS::FIMSFrame(data1)

# Create parameters
parameters <- data_4_model |>
  FIMS::create_default_configurations() |>
  FIMS::create_default_parameters(data = data_4_model)

# Run the  model with optimization
base_model <- parameters |>
  FIMS::initialize_fims(data = data_4_model) |>
  FIMS::fit_fims(optimize = TRUE)
FIMS::clear()

# Run a likelihood profile on R_zero
like_fit <- FIMSdiags::run_fims_likelihood(
  model = base_model,
  parameters = parameters,
  parameter_name = "log_rzero", 
  data = data1,
  n_cores = 1,
  min = -1,
  max = 1,
  length = 5
)

PHOTO OF THE WEEK

To add ten years of projections onto your time series you can use FIMS::FIMSFrame() to add -999 to all of your data streams by just adding a single year of -999 for any type with the maximum year that you want to project to. See the code below for an example, which was taken from the projections vignette. Now we need to think carefully about the default uncertainty values for the -999 in each type.

data("data1", package = "FIMS")
years_of_projections <- 10
data1_with_extra_year <- dplyr::add_row(
  data1,
  type = "landings",
  timing = get_end_year(data_4_model) + years_of_projection,
  name = "fleet1",
  value = -999,
  unit = "mt"
) |>
  # Make a FIMSFrame object out of this data frame with the extra row to add all
  # of the other missing years for each data type
  FIMSFrame()

PHOTO OF THE WEEK

Codecov has had some recent development that allows you to use copilot to generate tests for your Pull Request. It uses context from your test report to generate unit tests that target exactly what is missing so you can boost patch coverage. You can add the following comment on a Pull Request to make this happen. This feature has yet to be tried yet on a NOAA-FIMS repository.

@codecov-ai-reviewer test