Tibble management in FIMS workflows

[Bai-Li-NOAA]

Currently, there are several tibbles floating around after setting up model configurations and running a model, including default_configurations and default_parameters. I can see a potential issue: if users modify a module_type in the default_parameters, it may no longer align with the original module_type in the default_configurations tibble.

Do we want to explore the possibility of expanding the default_configurations tibble by modifying it directly, rather than creating new tibbles each time a function is used? Right now, the R script still allows us to reproduce results.

Along the same lines, the modified_parameters tibble is not fully connected to the outputs. Do we want to consider appending identifiers (e.g., module_id and parameter_id) to the output of initialize_fims(), so that this tibble can be linked to the model estimates later? This way, we could maintain a single tibble throughout the workflow.

[kellijohnson-NOAA]

Thanks @Bai-Li-NOAA for the Discussion topic. I think it would be 🥇 if we can get the input parameter tibble to match the output tibble to the best extent possible. One small thing off the bat that I notice is the differences in module_name where the output tibble is all lowercase. I think that the case-specific names in the input tibble is by design because it matches up with the code, right?

Below is a table of labels by module_name from an example output. Where line 23 should be "EWAAGrowth" rather than just "EWAA" to match the input.

dplyr::count(out, module_name, label) |> print(n = 900)
# A tibble: 45 × 3
   module_name label                          n
   <chr>       <chr>                      <int>
 1 fleet       age_to_length_conversion     552
 2 fleet       agecomp_expected             720
 3 fleet       agecomp_proportion           720
 4 fleet       catch_index                   60
 5 fleet       index_expected                60
 6 fleet       index_numbers                 60
 7 fleet       index_numbers_at_age         720
 8 fleet       index_numbers_at_length     1380
 9 fleet       index_weight                  60
10 fleet       index_weight_at_age          720
11 fleet       landings_expected             60
12 fleet       landings_numbers              60
13 fleet       landings_numbers_at_age      720
14 fleet       landings_numbers_at_length  1380
15 fleet       landings_weight               60
16 fleet       landings_weight_at_age       720
17 fleet       lengthcomp_expected         1380
18 fleet       lengthcomp_proportion       1380
19 fleet       log_Fmort                     60
20 fleet       log_index_expected            60
21 fleet       log_landings_expected         60
22 fleet       log_q                          2
23 growth      EWAA                          12
24 maturity    inflection_point               1
25 maturity    slope                          1
26 population  biomass                       31
27 population  expected_recruitment          31
28 population  log_M                        360
29 population  log_init_naa                  12
30 population  mortality_F                  360
31 population  mortality_Z                  360
32 population  numbers_at_age               372
33 population  proportion_mature_at_age     372
34 population  spawning_biomass              31
35 population  sum_selectivity              360
36 population  total_landings_numbers        30
37 population  total_landings_weight         30
38 population  unfished_biomass              31
39 population  unfished_numbers_at_age      372
40 population  unfished_spawning_biomass     31
41 recruitment log_devs                      29
42 recruitment log_rzero                      1
43 recruitment logit_steep                    1
44 selectivity inflection_point               2
45 selectivity slope                          2

I also think that the code could be better in matching column names, where the current column names of the output are

 [1] "module_name"     "module_id"       "module_type"     "label"           "type"            "type_id"         "parameter_id"    "fleet"          
 [9] "year_i"          "age_i"           "length_i"        "input"           "estimated"       "expected"        "observed"        "uncertainty"    
[17] "estimation_type" "distribution"    "input_type"      "lpdf"            "likelihood"  

and the column names of the input are

"model_family" "module_name" "fleet_name" "module_type" "label" "distribution_link" "age" "length" "time" "value" "estimation_type" "distribution_type" "distribution"

It would be nice to change "value" in the input tibble to "input" to match the output because value is not specific enough in the output tibble. Do we need "fleet_name" in the input or is "fleet" sufficient? I will add "time" to the output.

Note that @Schiano-NOAA @sbreitbart-NOAA and @kellijohnson-NOAA will be working on this today at 12:30 PT for the estimates tibble.

[Bai-Li-NOAA]

@kellijohnson-NOAA Yes, the case-specific names in the input tibble are intentional, since they align with the code. Combining module_type and module_name into a single string automatically matches the module name in the C++ code, making it easy to extract fields. Otherwise, we’d need extra R code to handle case matching before finding the correct module to initialize.

For line 23 in the output, my understanding is that module_name is Growth, module_type is EWAA, and label is NA (see input example here).

The time field in the input is meant to represent years, so it may be clearer to rename it to year for consistency with the output.

Renaming value in the input tibble to input sounds good to me. I don’t have a strong preference between fleet and fleet_name.

[kellijohnson-NOAA]

@Bai-Li-NOAA would you mind expanding on this idea more because I am not sure exactly what you mean

Do we want to explore the possibility of expanding the default_configurations tibble by modifying it directly, rather than creating new tibbles each time a function is used? Right now, the R script still allows us to reproduce results.

[Bai-Li-NOAA]

Sure, happy to expand. Here’s one example scenario: A user creates a configuration tibble with logistic selectivity for a survey fleet using create_default_configurations(). They then pass that output to create_default_parameters() to generate default parameters in a new tibble. Later, they decide to change the parameters to double-logistic selectivity using dplyr::rows_update(). At this point, the configuration becomes inconsistent: the output from create_default_configurations() still shows logistic selectivity, while the parameters tibble now reflect double-logistic.

My thought is that we could instead use rows_update() within create_default_parameters() on the tibble returned by create_default_configurations(). This would keep the configuration and parameter outputs in sync. More generally, use a modify-in-place approach over copy-and-modify in those wrapper functions.

[kellijohnson-NOAA]

As an FYI we are deprecating create_default_configurations() and going down the route of exporting all create_default_*() functions. Where create_default_configurations() was setting things, we will just assume the default settings there are the default settings elsewhere, such as Logistic selectivity and empirical weight-at-age but users can always use the other newly exported helper functions to change those assumptions.