create example with time-vary growth (Linf increase by 5 cm). See impact on SPB/R in expanded output to SPAWN_RECR table; but very little impact on estimated recruitments. Implied steepness move from 0.6 to 0.63 with the change in SPB/R.
Note that r4ss will be broken for now. Need to cleanup the SPAWN_RECR table first.
@timjmiller/wham
compare_SRR.zip

example file here and in the Issue.
update_SRR_AB.zip

To use r4ss with the SS3 version in this 191-spawner-recruitment-with-a-b-formulation branch, it necessary to install the expanded_SR branch of r4ss via
devtools::install_github("r4ss/r4ss@expanded_SR")
or
pak::pak("r4ss/r4ss@expanded_SR")

Two notes on failing github actions:

1. "build-ss3 / macos-12" github action can be ignored as discussed in Anyone still using Mac OS 12? Deprecate the build that's failing? #629. The action has been updated in main but this branch is behind and hasn't gotten the update to use macos-13 instead of macos-12.
2. The "run-ss3-no-est" action is failing because three models (growth_timevary, Simple_with_DM_sizefreq, and two_morph_seas_areas) have this error: Fatal Error! user must select 1, 2, or 3 for updating SPR0 flag (formerly labelled future feature in SR input) because there is time-varying biology.

@Rick-Methot-NOAA do you have a preference on the SPR0 flag used in the test models? I'm not yet familiar with the options and don't know how much difference any would make for the test models.

Ian,
when there is time-varying biology, the model can use option 2 to maintain backward compatibility with what seems to be an incorrect approach. We can convert examples the the correct option 1 approach later.

Thanks @Rick-Methot-NOAA.
The "run-ss3-no-est" action is now passing. I accidentally set the values to 1 ("correct") for all three models in my first commit, which was fine for two of the three models, but impacted the ForeCatch values in the growth_timevary model enough to fail the test. Changing the setting to 2 ("backwards compatibility") for just the one model got the test passing.

@e-perl-NOAA

• Can you update this branch with the 3.30.23 main?

@Rick-Methot-NOAA please review to make sure that everything was implemented in the rebase correctly. For everything but the updated ss3-build.yml workflow I went with the changes that you made in this branch when merge conflicts occurred.

After going through the rebase I keep getting this error on the build:
Error in line 13129 while reading
L
Error in line 3983 while reading
*
@Rick-Methot-NOAA @iantaylor-NOAA could either of you help decipher where that error is coming from?

that error must be me. Let me s33 if the ab branch compiles locally. Possible that I had not pushed a fix.

This branch has been open for a while which made the rebase challenging so it might have been an error introduced there. I should have rebased this branch earlier in the process and rebased it frequently throughout but I didn't know how long this was going to take initially.

OK. It does compile locally. VS Code says that there are 40 incoming changes from origin and 30 outgoing changes.

Locally, I pulled in the 40 changes and saved to a new branch. That branch fails to compile because in the ss_param.tpl file there are numerous lines that have lost the required initial indent.
Perhaps rather than do the rebase, I should try to merge the #191 branch into main locally while fixing any conflicts, then continue with that as a new version of the work. I'll await your advice next week.

Well. I did a pull(rebase) and now my local is messed up also. There are many lines where the initial 2 spaces are missing. In SS_param.tpl is seems to occur right after clang-format on. Then elsewhere I see that the {} than delineate a FUNCTION is not indented.
@iantaylor-NOAA please save your local version of this branch just in case recovering from there is easier than fixing the rebase.

Sorry about the troubles. I won't touch my local version. I'm guessing that someone more skilled with rebasing or merging could help us sort this out next week. The git history should also all be recoverable from github.

@iantaylor-NOAA can you make a branch off your untouched local version (maybe even 2 just to have an extra around in case we need it) and publish that, then rick and I can go through the rebase together?

I just pushed the 191-spawner-recruitment-backup branch. It does not include the "latest update" commit 27d4095 but that should be too hard to add back manually if necessary.

OK. I have your backup locally and verified that it compiles. I also see this branch with "cherrypick" and don't know what to do with that.

I just deleted it. Any branch you see created after Ian's just ignore. I'm troubleshooting ways to try to merge things. Ultimately Rick, you and I are going to need to go through certain merge conflicts together because with many of them, you will know what the code should best look like. I'll schedule that when I figure out the best way to proceed.

switching to rebased branch