Proposed design change to population->Evaluate

[Andrea-Havron-NOAA]

The evaluate function in population follows a design pattern that is a bit restrictive for random effects models. The current design pattern sets up each module (eg. maturity) as a scalar function and evaluates it inside the year loop of population->evaluate(). This setup necessitates that evaluations are hard coded at ages[age], preventing expansion into random effect structures such as RW or AR1.

A proposed change would be to call module specific evaluate functions (maturity, selectivity, growth) prior to the year loop in population-> Evaluate() and evaluate the entire vector instead of a scalar in the specific module functions. This way, the functions could be evaluated deterministically or as a random effect based on the previous age.

So instead of :

maturity.hpp
evaluate(const Type& x){ //evaluates and returns scalar}

population.hpp  
void CalculateMaturityAA(size_t i_age_year, size_t age) {
            this->proportion_mature_at_age[i_age_year] =
                    this->maturity->evaluate(ages[age]);
 }
Evaluate(){
for(y=0...){
  for(a=0...){
    ...
    CalculateMaturityAA(i_age_year, a);
    ..
  }
}

I propose:

maturity.hpp
evaluate(const fims::Vector<Type>& x){ //evaluates and returns vector of expected values}

population.hpp
void CalculateMaturityAA(size_t i_age_year, size_t age) {
            this->proportion_mature_at_age[i_age_year] =
                    this->maturity->expected_value[age];
 }
Evaluate(){
  maturity->evaluate(ages)
  for(y=0...){
    for(a=0...){
      ...
      CalculateMaturityAA(i_age_year, a);
      .. 
   }
}

This is all just from a Friday morning brainstorming session. I'fd be happy to write up a more formal design doc to present to the group if others don't see any problems with this change.

@kellijohnson-NOAA @msupernaw @Bai-Li-NOAA @nathanvaughan-NOAA

[msupernaw]

We’ll just need to make sure the proposed design doesn’t impact the derivative chain in a negative way.

[Andrea-Havron-NOAA]

good point, I think this also raises the issue that we should be benchmarking new changes against dev/main to ensure we're not introducing code that significantly slows down the model run.