refactor(tests): update integration test setup

.devcontainer/README.md

@@ -0,0 +1,35 @@
+# :package: FIMS devcontainer cheat sheet
+
+This cheat sheet outlines the steps for setting up a consistent FIMS development environment on a Windows machine using Windows Subsystem for Linux 2 (WSL2), Docker Engine, and Visual Studio Code (VS Code). By using a Docker image, this approach bypasses manual dependency installation and keeps everyone's setup the same.
+
+## :rocket: Launch the FIMS environment
+
+### Connect VS Code to WSL
+
+- Open VS Code and press `Ctrl + Shift + P` to open the command palette.
+- Type and select `WSL: Connect to WSL using Distro`.
+- Choose `Ubuntu` from the list.
+
+### Clone FIMS repo (first time only)
+
+- Once connected to WSL, open a new terminal in VS Code.
+- Clone the project repository:
+```bash
+git clone https://github.com/NOAA-FIMS/FIMS.git
+```
+
+### Open FIMS in Dev Container
+
+- In VS Code and press `Ctrl + O` to open the FIMS Folder you just cloned. 
+- Press `Ctrl + Shift + P` to open the command palette.
+- Type and select `Dev Containers: Reopen in Container`.
+- Docker will now build the container. The first build can take several minutes.
+
+## :door: Close the WSL Dev Container connection
+
+When you're finished, open the Command Palette (`Ctrl + Shift +P`) and type `Remote: Close Remote Connection`.
+
+## :raising_hand: Need help?
+
+If any of the instructions above do not work as expected, please
+[report an issue on GitHub](https://github.com/NOAA-FIMS/FIMS/issues).

.devcontainer/devcontainer.json

@@ -5,16 +5,20 @@
 	// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
 	"image": "ghcr.io/rocker-org/devcontainer/r-ver:4.3", //commma needed if other sections are used.
 
+  // Add capAdd and securityOpt to allow debugging with lldb
+  "capAdd": ["SYS_PTRACE"],
+  "securityOpt": ["seccomp=unconfined"],
+
 	// Features to add to the dev container. More info: https://containers.dev/features.
 	"features": {
 		// if we want to install r packages using pak
 		// more info: https://github.com/rocker-org/devcontainer-features/blob/main/src/r-packages/README.md
 		"ghcr.io/rocker-org/devcontainer-features/apt-packages:1": {
-			"packages": "clang,clang-format,clang-tidy,cmake,doxygen,g++,gcc,libxt6,libxtst6,make,ninja-build,gdb,valgrind",
+			"packages": "clang,clang-format,clang-tidy,cmake,doxygen,g++,gcc,libxt6,libxtst6,lldb,make,ninja-build,gdb,valgrind",
 			"updatePackages": true			
 		},
 		 "ghcr.io/rocker-org/devcontainer-features/r-packages:1": {
-			"packages": "covr,dplyr,devtools,ggplot2,jsonlite,methods,Rcpp,RcppEigen,scales,snowfall,TMB,tibble,tidyr,usethis,spelling",
+			"packages": "covr,dplyr,devtools,diffviewer,ggplot2,jsonlite,methods,Rcpp,RcppEigen,scales,snowfall,TMB,tibble,tidyr,usethis,spelling",
 			"installSystemRequirements": true
 		  },
 		 // option to run rstudio. you can type rserver into the command line to

.github/workflows/build-doxygen.yml

@@ -21,7 +21,7 @@ jobs:
 
     steps:
     - name: Get repository
-      uses: actions/checkout@v4
+      uses: actions/checkout@v5
 
     - name: Installing build dependencies
       run: |
@@ -40,16 +40,17 @@ jobs:
       if: ${{ github.ref == 'refs/heads/main' }}
       run: |
         mv build/html ./
-        mv ./html ./docs
+        mv ./html ./doxygen
 
     - name: Push docs to FIMS-docs repo
       if: ${{ github.ref == 'refs/heads/main' }}
       uses: dmnemec/copy_file_to_another_repo_action@main
       env:
         API_TOKEN_GITHUB: ${{ secrets.API_TOKEN_GITHUB }}
       with:
-        source_file: 'docs'
-        destination_repo: 'NOAA-FIMS/FIMS-docs'
+        source_file: 'doxygen'
+        destination_repo: 'NOAA-FIMS/noaa-fims.github.io'
+        destination_folder: 'doxygen'
         destination_branch: 'main'
         user_email: 'kelli.johnson@noaa.gov' # your email
         user_name: 'Kelli Johnson'           # your login

.github/workflows/call-allcontributors.yml

@@ -19,7 +19,7 @@ jobs:
             pull-requests: write
         steps:
             - name: Checkout repository
-              uses: actions/checkout@v4
+              uses: actions/checkout@v5
             - name: Setup R
               uses: r-lib/actions/setup-r@v2
 

.github/workflows/call-spell-check.yml

@@ -15,3 +15,5 @@ on:
 jobs:
   call-workflow:
     uses: nmfs-ost/ghactions4r/.github/workflows/spell-check.yml@main
+    with:
+      spell_check_additional_files: true

.github/workflows/get-gtest-codecov.yml

@@ -19,7 +19,7 @@ jobs:
       GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
 
     steps:
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
     - name: Install Ninja
       run: sudo apt-get install ninja-build
     - uses: r-lib/actions/setup-r@v2

.github/workflows/greetings.yml

@@ -2,14 +2,18 @@ name: Greetings
 
 on: [pull_request_target, issues]
 
+permissions:
+  issues: write
+  pull-requests: write
+
 jobs:
   greeting:
     runs-on: ubuntu-latest
     permissions:
       issues: write
       pull-requests: write
     steps:
-    - uses: actions/first-interaction@v1
+    - uses: actions/first-interaction@v3
       with:
         repo-token: ${{ secrets.GITHUB_TOKEN }}
         issue-message: >

.github/workflows/run-clang-format.yml

@@ -27,7 +27,7 @@ jobs:
     # Format hpp and cpp files under inst/include, src/, and test/gtest
     # We use Google style to format code.
     steps:
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
     - uses: DoozyX/clang-format-lint-action@v0.20
       with:
         source: './inst/include ./src ./tests/gtest'

.github/workflows/run-clang-tidy.yml

@@ -27,7 +27,7 @@ jobs:
     strategy:
       fail-fast: false
     steps:
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
 
     - name: install clang-tidy
       run: sudo apt update && sudo apt -y install clang-tidy

.github/workflows/run-googletest.yml

@@ -16,7 +16,7 @@ jobs:
       GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
 
     steps:
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
     - name: Install Ninja
       shell: bash
       run: ${{ runner.os == 'macOS' && 'brew install ninja' || runner.os == 'Windows' && 'choco install ninja' || 'sudo apt-get install ninja-build' }}

.vscode/settings.json

@@ -1,11 +1,39 @@
 {
+    "files.associations": {
+      "*.rmd": "markdown",
+      "*.Rmd": "markdown",
+      "vector": "cpp"
+    },
     "githubPullRequests.ignoredPullRequestBranches": [
         "main"
     ],
+    // Set where the rulers are, needed for Rewrap. 
     "editor.rulers": [
         80
     ],
-    "files.associations": {
-        "vector": "cpp"
-    }
-}
+    // Should the editor suggest inline edits?
+    // "editor.inlineSuggest.enabled": true,
+    // For diffs under version control, should whitespace be ignored?
+    // "diffEditor.ignoreTrimWhitespace": false,
+    // Max number of lines that are printed as output to the terminal?
+    // "terminal.integrated.scrollback": 10000,
+    // Potential R settings
+    // sending R code from the editor to the terminal
+    // "r.alwaysUseActiveTerminal": true,
+    // Needed to send large chunks of code to the r terminal when using radian
+    // "r.bracketedPaste": true,
+    // Needed to use httpgd for plotting in vscode
+    // "r.plot.useHttpgd": true,
+    // path to the r terminal (in this case, radian) for Windows
+    // "r.rterm.windows": "C://Users//my.name//AppData//Local//Programs//Python//Python310//Scripts//radian.exe", 
+    // options for the r terminal
+    // "r.rterm.option": [
+    //     "--no-save",
+    //     "--no-restore",
+    //     "max.print=500"
+    // ],
+    // Setting for whether to allow linting of documents or not
+    // "r.lsp.diagnostics": true,
+    // Potential CMake settings
+    // "cmake.configureOnOpen": true,
+}

CMakeLists.txt

@@ -54,33 +54,6 @@ IF(BUILD_DOC)
     COMMENT "Building documentation with Doxygen.")
 ENDIF()
 
-# Set up Rcpp
-FetchContent_Declare(
-  rcpp
-  URL https://github.com/RcppCore/Rcpp/archive/refs/tags/1.0.8.zip
-)
-FetchContent_MakeAvailable(rcpp)
-
-# Set up R
-MESSAGE(STATUS "Looking for R executable")
-
-EXECUTE_PROCESS(
-  COMMAND which R
-  OUTPUT_VARIABLE R_EXECUTABLE)
-
-MESSAGE(STATUS "R_EXECUTABLE is ${R_EXECUTABLE}")
-
-EXECUTE_PROCESS(
-		COMMAND R "--slave" "--no-save" "-e" "cat(R.home())"
-		OUTPUT_VARIABLE R_HOME)
-
-MESSAGE(STATUS "R_HOME is ${R_HOME}")
-
-EXECUTE_PROCESS(
-		COMMAND R "--slave" "--no-save" "-e" "remotes::install_local(upgrade = 'always')")
-EXECUTE_PROCESS(
-		COMMAND R "--slave" "--no-save" "-e" "FIMS:::setup_gtest()")
-
 # Enable testing for current directory and below
 enable_testing()
 
@@ -91,8 +64,6 @@ add_library(fims_test INTERFACE)
 target_include_directories(fims_test
   INTERFACE
     inst/include
-    ${rcpp_SOURCE_DIR}/inst/include
-    ${R_HOME}/include
 )
 
 # Add compile definition STD_LIB to the fims_test target.

CONTRIBUTING.md

@@ -1,21 +1,48 @@
 # Contributing to the NOAA Fisheries Integrated Modeling System
 
-A comprehensive set of guidelines for contributing to NOAA's Fisheries Integrated Modeling System can be found in our [NMFS Fish Tools Organization](https://noaa-fims.github.io/collaborative_workflow/contributor-guidelines.html) on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request to the [collaborative workflow document](https://github.com/NOAA-FIMS/collaborative_workflow).
+External contributions and feedback are important to the development and future maintenance of the Fisheries Integrated Modeling System (FIMS) and are welcome. This section provides contributing guidelines and workflows for developers of FIMS and the ecosystem surrounding FIMS. All contributors, both internal and external, are required to abide by the [Code of Conduct](https://github.com/NOAA-FIMS/.github/blob/main/CODE_OF_CONDUCT.md).
 
-## Code of Conduct
+## TLDR --- I just have a question
 
-This project and everyone participating in it is governed by the [Code of Conduct](https://noaa-fims.github.io/collaborative_workflow/code-of-conduct.html). By participating, you are expected to uphold this code. Please report unacceptable behavior to [fims.conduct@noaa.gov](mailto:fims.conduct@noaa.gov).
+Please use [GitHub Discussions](https://github.com/orgs/NOAA-FIMS/discussions) if you have a question. There is a special category set up for [Q&A](https://github.com/orgs/NOAA-FIMS/discussions/categories/q-a). But, you should also check out the other categories to see if your question has already been answered.
 
-## I don't want to read this whole thing I just have a question!!!
+## Found a :bug:
 
-> **Note:** Please don't file an issue to ask a question. You'll get faster results by using the resources below.
+Please use [GitHub Issues](https://github.com/NOAA-FIMS/FIMS/issues/new?template=bug_report.yml) to submit a :bug: report. If you have an idea for a well-defined enhancement to FIMS, please use GitHub to submit a [Feature request](https://github.com/NOAA-FIMS/FIMS/issues/new?template=feature_request.yml). Before submitting either of these tickets, please search the [existing issues](https://github.com/NOAA-FIMS/FIMS/issues?q=is%3Aissue) to see if something identical or similar has already been submitted. Once created, Issues are automatically tagged with the `status: triage_needed` tag and placed on the [Issue Triage Board](https://github.com/orgs/NOAA-FIMS/projects/21) where they will be labeled, given an assignee, and given a milestone by those in charge of the triage process.
 
-Please use [GitHub Discussions](https://github.com/orgs/NOAA-FIMS/discussions) if you have a question. There is a special category set up for [Q&A](https://github.com/orgs/NOAA-FIMS/discussions/categories/q-a). But, you should also check out the other categories to see if your question has already been answered.
+## Contributing code
+
+### Feature branches
+
+Once an issue is approved and prioritized for work, a feature branch off of the dev branch, e.g., `dev-discards`, can be created to address the issue. Feature branches can be made within the repository or on a fork of the repository. When making a fork, be sure to fork all branches not just the default branch because feature branches should only be created off of main if they are a hotfix for the current release, e.g., `fix-pointer`. There are no hard and fast rules for branch names but we tend to use dashes to separate words. Often while working on this new feature branch, there will be updates to the dev branch. These updates must be brought in using `git rebase`. Branches that have merge commits will not be accepted into the code base. Please see the [GitHub documentation for rebasing](https://docs.github.com/en/get-started/using-git/about-git-rebase) for more information.
+
+Along the development process it is important to add tests and ensure that the code is well documented. Below are the steps to follow to ensure that the code is ready for a pull request:
+* Build the doxygen-generated C++ documentation using `cmake --build build`, where the resulting html files will be in build/html. This can also be done using `setup_and_run_gtest()` in R.
+* Implement the suite of Google tests using `cmake --build build` and `ctest --test-dir build`. This can also be done using `setup_and_run_gtest()` in R. If there are failing tests, run `ctest --test-dir --rerun-failed --output-on-failure` to re-run the failed tests verbosely.
+* Run clang format to format the C++ code using TODO: document how to run clang-format.
+* Run clang tidy to check C++ for common mistakes using TODO: document how to run clang-tidy.
+* Spell check the package using `spelling::spell_check_files(list.files(c("R", "tests", file.path("inst", "include")), recursive = TRUE, full.names = TRUE, pattern = "\\.cpp|\\.hpp|\\.md|\\.R$|\\.Rmd|\\.txt"), ignore = spelling::get_wordlist())`. Remove all the .md files in the vignettes directory and then spell check the package using `spelling::spell_check_package(pkg = ".", use_wordlist = TRUE)`.
+* Build the roxygen documentation using `devtools::document()`. See the [r-lib](https://roxygen2.r-lib.org/) for all available tags and best practices.
+* Implement the suite of testthat tests using `devtools::test()`.
+* Run `styler::style_pkg()` to style R code.
+* Run `devtools::check()` to ensure the package can be compiled and R tests pass. If there are failing tests, run `devtools::test(filter = "file_name")` (where "test-file_name.R" is the testthat file containing failing tests) and edit code/tests to troubleshoot tests. During development, run `devtools::build()` locally to build the package more frequently and faster.
+* Build the package down site using `pkgdown::build_site()`.
+* Run the code coverage report using `covr::report()` to ensure that all of the code is covered, with the goal of maintaining 80 percent code coverage.
+
+### Pull requests
+
+Once the work is complete, a pull request should be created to bring the changes into the appropriate branch. Pull requests from forks will be reviewed under the same guidelines as pull requests from internal branches. Review of the pull request will be both automated and manual, where all pull requests must pass automated tests and syntax checks before being merged in addition to being reviewed by at least one developer. [Code review](https://github.com/features/code-review) ensures health and continuous improvement of the FIMS codebase, while simultaneously helping FIMS developers become familiar with the codebase. [Google's code review guide](https://google.github.io/eng-practices/review/) provides a useful set of guidelines for both reviewers and code authors. Each PR is accompanied by a [checklist of major considerations for code reviews](https://github.com/NOAA-FIMS/FIMS/blob/main/.github/workflows/pr-checklist.yml) to guide reviewers through the PR. Additional guidance can be found at [Conventional Comments](https://conventionalcomments.org/) for formatting/structuring your reviewer comments. Navigate to the [Perforce Blog](https://www.perforce.com/blog/qac/9-best-practices-for-code-review) for nine best practices for code review and use the [FIMS Style Guide](#style-guide) to settle any style arguments.
+
+Versioning follows [semantic versioning](https://semver.org/) to establish the major, minor, and patch number for a release. Often, multiple pull requests are included in a single release, which will be initiated by a member of the FIMS Implementation Team. Release notes for each version can be found in the [release notes](https://github.com/NOAA-FIMS/FIMS/releases).
+
+## Non-code contributions
+
+Not all contributions are code! Writing documentation, teaching, and other activities are also key parts of contributing to software that are much appreciated. For more information about open source contributions, see [the Open Source Guide's How to Contribute page](https://opensource.guide/how-to-contribute/). A good place to start is by looking for open issues with the [good first issue label](https://github.com/NOAA-FIMS/FIMS/contribute). These issues are generally small and well-defined, making them a good starting point for new contributors. We encourage collaborators to feel welcome to contribute in any way they can, and we will do our best to incorporate these contributions into the FIMS projects. We thank you in advance for being part of the team.
 
-## I want to file a bug or feature request
+## Style guide
 
-Please use our [issue templates](https://github.com/NOAA-FIMS/FIMS/issues/new/choose) to submit a Bug Report, Feature Request, or Refactor.
+Style guides are used to ensure the code is consistent, easy to use (e.g., read, share, and verify) and ultimately easier to write. We use the [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html) for C++ code and the [tidyverse style guide](https://style.tidyverse.org/) for R code.
 
-## How can I contribute?
+A self-imposed style within FIMS is the use of `typename` instead of `class` when defining templates for consistency with the `TMB` package. While types may be defined in many ways, we use `Type` instead of `T` to define Types.
 
-Not all contributions are code! Writing documentation, teaching, and other activities are also key parts of contributing to software, and guidelines for how to do this are covered in the [collaborative workflow book](https://noaa-fims.github.io/collaborative_workflow/contributor-guidelines.html). For more information about open source contributions, see [the Open Source Guide's How to Contribute page](https://opensource.guide/how-to-contribute/).
+Commit messages communicate details about changes that have occurred to collaborators and improve team efficiency. The best guidance for how to create an excellent commit message can be found on [Conventional Commits](https://www.conventionalcommits.org), which is our style guide for commit messages. See [Conventional Comments](https://conventionalcomments.org/) for how to format reviewer comments.

DESCRIPTION

@@ -92,12 +92,12 @@ LinkingTo:
     TMB
 VignetteBuilder:
     knitr
+Config/roxygen2/version: 8.0.0
 Config/testthat/edition: 3
 Config/testthat/parallel: false
 Encoding: UTF-8
 Language: en-US
 LazyData: true
 NeedsCompilation: yes
 Roxygen: list(markdown = TRUE)
-RoxygenNote: 7.3.2
 SystemRequirements: GNU make

NAMESPACE

@@ -7,7 +7,7 @@ export(DlnormDistribution)
 export(DmultinomDistribution)
 export(DnormDistribution)
 export(DoubleLogisticSelectivity)
-export(EWAAgrowth)
+export(EWAAGrowth)
 export(FIMSFit)
 export(FIMSFrame)
 export(Fleet)
@@ -26,6 +26,7 @@ export(SharedInt)
 export(SharedReal)
 export(SharedString)
 export(clear)
+export(create_default_configurations)
 export(create_default_parameters)
 export(finalize)
 export(fit_fims)
@@ -64,7 +65,6 @@ export(initialize_process_distribution)
 export(initialize_process_structure)
 export(inv_logit)
 export(is.FIMSFit)
-export(is.FIMSFits)
 export(log_error)
 export(log_info)
 export(log_warning)
@@ -78,7 +78,6 @@ export(m_lengthcomp)
 export(m_weight_at_age)
 export(multinomial)
 export(set_log_throw_on_error)
-export(update_parameters)
 exportMethods(Math)
 exportMethods(Ops)
 exportMethods(Summary)