645 add variable map

[Andrea-Havron-NOAA]

What is the feature?

• refactor variable map
• refactor distribution interface

How have you implemented the solution?

• add variable_map infrastructure
• add variable map as an object in informatin.hpp
• add std::vector<uint32_t> key to density_components_base
• add unique ID to VariableVector class and get_id function
• resize key and pass to densities in rcpp_distributions

each rcpp_object: set unique key for all tracked parameter/derived value

• rcpp_fleet: log_Fmort, expected_catch, expected_index, catch_numbers_at_age
• rcpp_population: log_init_naa, log_M, numbers_at_age
• rcpp_recruitment: logit_steep, log_rzero, log_sigma_recruit, log_devs
• rcpp_selectivity: inflection_point, slope, inflectin_point_asc, slope_asc, inflection_point_desc, slope_desc

refactor the following vectors to use .estimated_m and .is_random_effect_m in interface:

• fleet->log_Fmort
• population->log_M
• population->log_init_naa
• recruitment->log_devs

add documentation

refactor user interface

• fix tests to work with C++ changes

refactor model.hpp

refactor fleet.hpp

• remove evaluate_age_comp_nll
• remove evaluate_index_nll in fleet.hpp
• remove log_obs_error from fleet

refactor interface

• remove estimate booleans from fleet and population
• remove set likelihood components from fleet
• refactor data objects to be set from distributions interface
• expose vectors to R
• track parameter names

fix C++ tests to work with changes in C++ code

refactor user interface

• fix R tests to match changes in C++ code
  • remove test on nll in recruitment
  • report out nll components
  • set log devs estimation to true
• update demo to work with changes in C++

refactor distributions

• add conditional to handle data object
• add distribution logs
• reset nll_components to zero

Does the PR impact any other area of the project, maybe another repo?

The user will now set up distributions through the R interface

[github-actions]

Instructions for code reviewer

Hello reviewer, thanks for taking the time to review this PR!

• Please use this checklist during your review, checking off items that you have verified are complete!
• For PRs that don't make changes to code (e.g., changes to README.md or Github actions workflows), feel free to skip over items on the checklist that are not relevant. Remember it is still important to do a thorough review.
• Then, comment on the pull request with your review indicating where you have questions or changes need to be made before merging.
• Remember to review every line of code you’ve been asked to review, look at the context, make sure you’re improving code health, and compliment developers on good things that they do.
• PR reviews are a great way to learn, so feel free to share your tips and tricks. However, for optional changes (i.e., not required for merging), please include nit: (for nitpicking) before making the suggestion. For example, nit: I prefer using a data.frame() instead of a matrix because...
• Engage with the developer when they respond to comments and check off additional boxes as they become complete so the PR can be merged in when all the tasks are fulfilled. Make it clear when this has been reached by commenting on the PR with something like This PR is now ready to be merged, no changes needed.

Checklist

• The PR is requested to be merged into the appropriate branch (typically main)
• The code is well-designed.
• The functionality is good for the users of the code.
• Any User Interface changes are sensible and look good.
• The code isn’t more complex than it needs to be.
• Code coverage remains high, indicating the new code is tested.
• The developer used clear names for everything.
• Comments are clear and useful, and mostly explain why instead of what.
• Code is appropriately documented (doxygen and roxygen).

[Andrea-Havron-NOAA]

@Bai-Li-NOAA , can you review changes I made to helper-integration-tests-setup.R and test-integration-fims-estimation.R?

[Bai-Li-NOAA]

@Bai-Li-NOAA , can you review changes I made to helper-integration-tests-setup.R and test-integration-fims-estimation.R?

@Andrea-Havron-NOAA, would you like me to review only the changes in the tests or all the changed files? I started reviewing all the files but realized that it might take some time. I'm also finding that reviewing some of the .hpp files is stretching my current knowledge🤔. Could we possibly get another pair of 👀 on the pull request or split the review effort for some of the files? Thank you!

[Andrea-Havron-NOAA]

@Bai-Li-NOAA , can you review changes I made to helper-integration-tests-setup.R and test-integration-fims-estimation.R?

@Andrea-Havron-NOAA, would you like me to review only the changes in the tests or all the changed files? I started reviewing all the files but realized that it might take some time. I'm also finding that reviewing some of the .hpp files is stretching my current knowledge🤔. Could we possibly get another pair of 👀 on the pull request or split the review effort for some of the files? Thank you!

@Bai-Li-NOAA, we have already done an initial review of the code except for the changes I made to the two files:
helper-integration-tests-setup.R
test-integration-fims-estimation.R

There will also be a more in depth review on the PR from dev to main. I just need you to review the two files listed above. Thanks!

[Bai-Li-NOAA]

@Andrea-Havron-NOAA, the helper-integration-tests-setup.R and test-integration-fims-estimation.R files look good to me. I noticed that the run-doxygen GHA failed. If you’re planning to address that before merging into Dev, running cmake -S . -B build -G Ninja -DDOXYGEN_WARN_AS_ERROR=YES can help identify all the places that need documentation.