Splitting into sub-packages

[mhesselbarth]

Splitting arrR into sub-package related to seagrass, fish, etc. to move forward and facilitate easy maintenance

[mhesselbarth]

Probably all seafloor processes can go into one package, all fishpop processes and maybe one utility?

[kmunsterman]

Notes on changes from KSM branches (matrix-extension) and (fixed-population)

1. matrix-entension
   • note, this does not seem to essential too essential moving forward with model development (beyond Katrina's paper)

what does it do?
matrix is created in R, outside of IBM, then imported into IBM

what is it?
fishpop_attr:
threshold matrix with 3 columns: fish ID, pop_reserves_thres_mean, and pop_reserves_consump

what files are affected?
R/run_simulation.R
rcpp_fishpop_growth
rcpp_move_behav
rcpp_move_wrap
rcpp_simulate
rcpp_simulate

what are the ways to merge changes?

Not sure there is a way around providing a threshold matrix if we want to keep this in the model moving foward

I think we could pass along either a 1 column matrix that simply has the ID and uses set parameters for pop_reserves_thres_mean and pop_reserves_consump

then use an if, else statement that asks how many columns are provided in fishpop_attr matrix. If 1 column, use the set parameters, else use all 3 columns in matrix provided

2. fixed-population
   • note, Jake wants this included in future model iterations. See ways to merge changes below.

what does it do?
changes the mortality term for fish individuals. instead of probability increasing as fish approach lmax, they immediately die at a certain size.

what is it?
pop_ldie
integer that is set in parameters

what files are affected?
R/run_simulation.R
R/setup_fishpop.R
rcpp_fishpop_growth
rcpp_mortality

what are the ways to merge changes? (from Max Sept 20)

We probably want to check if any individuals are above the fixed mortality size at the beginning of the model. Because if that is the case, the fish dies every single iteration. I added a check to run_simulation() returning a warning. Maybe we won't a stop/error?

We could set the default of pop_ldie to zero/infinity/NULL and only run the code if it's not the default value. Instead of adding another argument to run_simulation()

[mhesselbarth]

Thats all related to fish, correct?

I will go on today and separate the seafloor/water column sub-processes today.

[kmunsterman]

Yes, all related to fish. I can work on adding in these checks for 2. fixed mortality but I want your opinion about adding in an argument about the matrix or not.

[mhesselbarth]

Isn't there already an argument for the matrix which is defaulted to NULL? I am currently even leaning towards remove the random matrix generation completely from Rcpp and use the same value for all fish if the argument is NULL (default). Alternatively, if users want to use different values, they would need to create values in R.

What you think?

[mhesselbarth]

Seagrass: ac6fb0c

[kmunsterman]

Regarding the matrix, that sounds good to me. Forgot you already added in that NULL argument for the matrix - thanks!

[mhesselbarth]

So is there anything to do for me? And didn't we already merge that into development? I only see it on the other branches? Am I stupid?

[kmunsterman]

I will check later today. It would be awesome if you could check over the arguments I add to the fixed mortality branches. Thanks!

[mhesselbarth]

Do you mean the "fixed-population" branch? And can you quickly list which arguments you are referring to?

[kmunsterman]

Woop, yes - fixed-population!

1. Add a check and STOP/ERROR message if individuals are above the fixed mortality size - right now we only have a check in run_simulation()
2. Make default of pop_ldie to zero/infinity/NULL and only run the code if it's not the default value (I think this is already the case? I will need to check)

[mhesselbarth]

1. I think that's the perfect place to have the check? Where else would you put it?
2. See commit 9faff6e and mostly changes in rcpp_mortality(). How about that?

[kmunsterman]

1. I was suggesting having a STOP instead of just a warning - but I think the warning in that spot is fine.
2. Perfect - thanks!

[mhesselbarth]

1. Oh got it. Don't care tbh. If you prefer a stop we can change that
2. Cool!

Is the matrix outside the model and the fixed mortality all from your branch we need to preserve? If so, I think I can try to get these changes on the "development" branch.

[kmunsterman]

Yes, that is it - I went thru my branches the other day and outlined what might need to be changed here in this issue. Thanks!