[erlasturl]

Your commits explain the who, what, where and when of these changes. Your code shows the how. You do not need to reiterate this. This PR should complete the big picture by telling the why.

Justification

Makes the RAssess functions work for TAC and Effort allocation.

The main changes was done to Read_RAssess_output(). It can read in to format of files 1) TAC for each fishery 2) Effort allocation (box, season, fishery) based on effortmodel= 3. The code detects if there is TAC or Effort in the header of the file from R. It then reads the values into the appropriate arrays. The format of the files needed is given in a comment above the function in the code.

In order to allocate effort one needs to assess a species and put isTAC > 1 in the group csv file. This should then be done for a group which is not being assessed for TAC. The parameterization does not really make sense for effort allocation. We may want to add a parameter so instead of whichRAssess_XXX we would have RAssesseffortAllocation_YYY. Then I think we would need to call Do_RAssess (or just Run_RAssess() and Read_RAssess_output()) somewhere outside the loop Do_RAssess() is in. Maybe we would like to put it straight into RunNextTimeStep() after Manage_Calculate_Total_Effort() so it can be called before each season or monthly and the effort allocation for certain fleets updated.

Added new arrays to RAssessSurvey() to collect size index and fixed minor bugs. Using Ecology_Get_Size() instead of Get_Length() as there is a bug in Get_Length() when converting from mg N to g ww. Ecology_Get_Size() used the l-w parameters from the biology file but Get_Length() uses parameters from the assessment file.

In Populate_RAssessFile() I removed code that was not working. The array SizeCaught was only created but never used so only contained zeros. I made changes in Calculate_Catch() such that SizeCaught contains caught biomass which is used in Populate_RAssessFile() to calculate size in catch. This function now reads data into all columns that were initialized.

Types of changes

What types of changes does your code introduce? Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Other change (if none of the other choices apply)

Further comments

If this is a New Feature, Breaking change, or a bug fix, the Atlantis Manual will need to be updated to reflect these changes.
Now would be a good time to create an issue in the Atlantis Manual repo and begin documenting your changes.

• I've created an issue
• This is NA

Reviewer instructions:

Assign at least 2 reviewers:

• one of which should be a maintainer,
• the others should be familiar with the subject changes. Please add these under the assignees field

Please detail the process reviewers will need to follow to properly test these changes. It is especially helpful to identify the exact code needed to conduct a local build/review/test and to specify any aspects of the testing that may not be obvious.

I have written sections in the manual "Effort reallocation using R-link" (17.6.2) in "Fishing Mortality" chapter and "Dynamic TAC using R-link" (18.2.11) in "Management" that should help with the testing. Theses sections can be found on following branch

https://github.com/Atlantis-Ecosystem-Model/AtlantisManual/tree/docs/i32-rlink-documetation-new

In order to test this a model with assessment parameter file is needed and to test the effort allocation a fleet with effort model 3 is needed.

[jcaracappa1]

@erlasturl For new features, I think we need to be able to test it on the example SETAS model within the repo. That would allow anyone to review the new functionality more easily. To do this, we would need an example assess.prm file and R script in the example folder and instructions in the Pull Request for how to "turn on" the R link in the SETAS model. Otherwise, we would be testing a new feature on different regional models potentially introducing new issues.

[andybeet]

@erlasturl Did you have issues initially compiling this? I noticed you had changed the PreRules.am? Do you remember was going on? This PR had a merge conflict that i fixed but now the workflow is failing. It is looking for a file in the r-base-dev package which we dont install in the workflow. Not sure why it is now required.

I think it is related to ubuntu 18.04 EOL. Some base packages being moved into archived repositories. I have updated the workflow to run on 20.04 and amended the Prerules on a fork and i am testing it. I will make a branch off of this with the changes and we can merge it back into this PR.

EDIT: Ok that merge solved the broken workflow!!!

[andybeet]

@erlasturl How difficult would it be to create an assessment.prm file to use with the SETAS example. I seem to remember Beth sent @jacobkasper a bunch of example assessment prms. Maybe we can reuse one of those? I can't remember if Jacob initially tried to use those and whether he got one to work.

Here is a SETAS assessment file. Might be a good starting point?

[erlasturl]

I have added VMPA_setas_assess.prm to the example file along with an Rscript for the FPS group. Parameters that should be set for the TAC to run are described in the manual addition found here i32-rlink-documetation-new

In the group csv file, isTAC should be set to 2 for groups that should be R-assessed

In the harvest prm file these parameters should be as follows

XXX_flagmanage 2
flag_stop_F_tac 1
bulkTAC 0 # if only using the current year
TAC_XXX set to some value that will be used for the first year

In the assess prm file

UsingRAssess 1
RAssessSpringSurveyDay 100000 # set to large number if not used
RAssessAutumnSurveyDay 100000 # set to large number if not used
RAssessFisheryID 0 # As the order of the fisheries starting from 0, used in the survey
RAssessFixedM 1 # Whether using fixed M, used in the survey
RAssessRefYear 1948
RAssessRuseScript 1 # Whether using system() call to R (1) or using embedded R calls (0)
RassessColDelimiter ;
RAssessRinName RAssessinput.csv # Base name of RAssess input files (functional group names will be appended)
RAssessRoutName Rassess.out # Base name of RAssess output files (functional group names will be appended)
ss3Name ss3 # Name of the SS3 executable file
NumRAssessScriptNames 1 # number of RAssess scripts to call – possible to have different ones for different functional groups
RAssessRscriptName0 Rassess_TAC.R
whichRAssess_XXX 0 # if group should use Rscript0
flag_assess 1 # set to 1 for a group that should be allocated TAC

[andybeet]

Great! I'll give the example model a test!