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.Sent from my iPhoneOn Jan 17, 2025, at 12:55 PM, Andrea-Havron-NOAA ***@***.***> wrote: 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. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[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.