SS bug reports

Comments on 3.30.19 pre-release

2022-02-25T19:05:41Z

comments on this pre-release can be made here.

RE: help on converting 3.24 to 3.30

2022-01-23T13:15:50Z

Dear, please ignore my previous request. The problem appears to be resolved. I found that the Q requires further manual setup after ss_trans and now the 3.30 version works OK

Cheers,

Dan

help on converting 3.24 to 3.30

2022-01-23T10:17:26Z

Dear SS team,

I am wondering if I can get some help to convert IOTC bigeye assessment files from 3.24 to 3.30.

The ss_trans converts the files fine (I just need to manually change one of the Q parameter to floating 0 afterwards)

However when running ss_trans for estimation, it complained about the likelihood stepsize being two small and also reported an error in the end.

When running ss.exe (3.30.17), the likelihood seems to be stuck in a region where B0 is about 1/10 of what was estimated by ss3.24.

It would be very appreciated if you could spare some time having a look at this.

The 3.24 input and par files attached.

Thanks for you help

Dan

RE: A bug converting SS files from 3.24 to 3.30 when the recruitment offset is defined

2021-01-28T17:28:36Z

Thanks Richard for the quick response. I understand now and will have a go to get it work.

Cheers.

RE: A bug converting SS files from 3.24 to 3.30 when the recruitment offset is defined

2021-01-28T16:54:48Z

Hi Dan,

This is one of the very few issues that is only partially converted by ss_trans.

When you ran ss_trans, you should find in the warning.sso file a message like this:

The R1_offset parameter is now the regime parameter and it must not be estimated and should have value of 0.0
Instead, time-varying offsets to the regime parameter can be estimated; and a block for doing this has been created
you will need to manually create the parameter line for that block or turn autogen value to 0 for SR_parms

That warning file may well also show you some additional issues that were improved with 3.30.

The change from the unique R1_offset parameter to a generic block parameter was part of the effort with SS3.30 to unify the code for time-varying parameters for biology, spawner-recruitment, catchability and selectivity. The benefit for spawner-recruitment is that you now can define multiple blocks as needed.

Rick

A bug converting SS files from 3.24 to 3.30 when the recruitment offset is defined

2021-01-28T15:54:39Z

Dear SS3 team,

Happy new year.

There appears to be a bug when converting SS files from 3.24 to 3.30 when the recruitment offset (regime shift) is defined in the original (3.24) control files:

-5 5 -0.05 0 0 1 1 # SR_R1_offset

The ss_trans.exe runs OK but subsequent ss3.exe run will fail. It appears that the translated files didn't generate the relevant time block properly, I think.

It should be easy to reproduce this 'error'. (I can send my working files if needed).

I am using 3.30.16

Thanks.

Dan

RE: Jitter analysis

2020-07-22T21:29:57Z

I recently pushed a change to r4ss that will allow for users to specify ss or ss.exe as well as a few other minor changes to make things more robust. Hopefully the new functionality will serve you well and be faster than the previous version of SS_RunJitter(). Thanks for your help on this!

Best,

Kelli

RE: Jitter analysis

2020-07-18T15:58:27Z

Hi Kelli,

You are quite right and the function seems to be working once changed to 'ss' ! The help file indeed mentioned something about using 'ss' rather than 'ss.exe'. My neglect. Thanks for your timely response. Much appreciated.

Cheers,

Dan

RE: Jitter analysis

2020-07-18T13:31:41Z

Dan,

I am sorry you are having problems. I was the last one to edit SS_RunJitter() so I am guessing I did something wrong. What operating system are you running on? Also, have you tried running the command with model="ss" rather than model="ss.exe" ... I think that is where the bug is because it is renaming the par file with the model name and I did not account for the fact that it could have the extension on it. Please let me know if changing the input argument for model works for you.

Best,

Kelli

Jitter analysis

2020-07-18T11:53:27Z

Dear ss3 team,

I am trying to run a jittering analysis under V3.30.15.07-safe usng r4ss (Github developement version).

But I get the following error message:

jit.likes <- SS_RunJitter(mydir=mydir,model = 'ss.exe',Njitter=2)
Error trying to open data input file C:\Projects\2020\2020SW~1\Working\SS3\2020\basic\Jitter\ss.dat
reading from STARTER.SS
reading from data file
Data read sucessful 999

reading forecast file
reading from control file
If you see 999, we got to the end of the control file successfully! 999
read parm file
Error trying to open parameter input file ss.par
Table of likelihood values:
< table of extent 0 >
Warning message:
In SS_RunJitter(mydir = mydir, model = "ss.exe", Njitter = Njitter, :
No Report.sso file found from run 1

It seems to complain about the ss.par file but I had ensured that the ss.par under the directory is correct (i.e. I have to problem running under the command line)

I have attached all input files. Could you please have a look at this issue?

Thanks

Dan

RE: issues by pull back the end-year by one year in 3.30

2020-06-17T17:49:45Z

Yes, they SHOULD work with the high reporting option, although subtle differences may exist.

If you have problems with this branch of r4ss working with your existing scripts, feel free to report them at https://github.com/r4ss/r4ss/issues/9 if you have a github account, or just email me directly.

-Ian

On Wed, Jun 17, 2020 at 9:48 AM Dan Fu <VLab.Notifications@noaa.gov> wrote:

Thanks Ian, I will try. One more question on the new version - If I keep the output option in the starter file as 1. high instead of using the new custom options, I suppose all my existing r4ss calling scripts should still work ? .

--
Dan Fu Stock Synthesis Virtual Lab Forum https://vlab.noaa.gov/web/stock-synthesis/public-forums/-/message_boards/view_message/10495342 VLab.Notifications@noaa.gov

RE: issues by pull back the end-year by one year in 3.30

2020-06-17T16:48:49Z

Thanks Ian, I will try. One more question on the new version - If I keep the output option in the starter file as 1. high instead of using the new custom options, I suppose all my existing r4ss calling scripts should still work ? .

RE: issues by pull back the end-year by one year in 3.30

2020-06-17T16:36:45Z

Hi Dan,

I just got the in-progress branch of r4ss working with your model when run using the development 3.30.15.07 version of SS.

You can install it via

remotes::install_github('r4ss/r4ss@use_blank_lines')

These changes will be merged into the master branch by the time SS version 3.30.16 gets released.

Let us know if you have problems with this.

-Ian

On Wed, Jun 17, 2020 at 9:35 AM Richard Methot <VLab.Notifications@noaa.gov> wrote:

The excel sheet with the change log has just been uploaded to its folder in the document library.

Rick

--
Richard Methot Stock Synthesis Virtual Lab Forum https://vlab.noaa.gov/web/stock-synthesis/public-forums/-/message_boards/view_message/10495241 VLab.Notifications@noaa.gov

RE: issues by pull back the end-year by one year in 3.30

2020-06-17T16:35:49Z

The excel sheet with the change log has just been uploaded to its folder in the document library.

Rick

RE: issues by pull back the end-year by one year in 3.30

2020-06-17T16:33:31Z

Hi Dan,

Yes, it does.

RE: issues by pull back the end-year by one year in 3.30

2020-06-17T16:28:43Z

Thanks, noted. Does this version include the fix for the projection problem caused by the settlement time in a multi-season configuration?

RE: issues by pull back the end-year by one year in 3.30

2020-06-17T16:13:45Z

You'll need to update your r4ss also. This version of SS implements an option for custom selection among the ~60 numbered report elements. Look at a starter.ss_new to see how to use it. We will of course get it documented more completely.

3 # detailed output (0=minimal for data-limited, 1=high (w/ wtatage.ss_new), 2=brief, 3=custom)
# custom report options: -100 to start with minimal; -101 to start with all; -number to remove, +number to add, -999 to end

-100 # start with a brief list

43 # add report 43

-31 # remove report 31

-999 # end customizing report list

The list of the report elements is found at top of the report.sso file.

Richard D. Methot Jr. Ph.D.
NOAA Fisheries Senior Scientist for Stock Assessments

Mobile: 301-787-0241

On Wed, Jun 17, 2020 at 9:02 AM Dan Fu <VLab.Notifications@noaa.gov> wrote:

Hi Kathryn, the windows version will do for me for now.

Thanks again for the timely response and help.

--
Dan Fu Stock Synthesis Virtual Lab Forum https://vlab.noaa.gov/web/stock-synthesis/public-forums/-/message_boards/view_message/10494876 VLab.Notifications@noaa.gov

RE: issues by pull back the end-year by one year in 3.30

2020-06-17T16:01:55Z

Hi Kathryn, the windows version will do for me for now.

Thanks again for the timely response and help.

RE: issues by pull back the end-year by one year in 3.30

2020-06-17T15:20:04Z

Hi Dan,

A development version (3.30.15.07) is available in the fixes folder. Just the Windows versions are there, so please let us know if you need the Mac or Linux versions (we can easily and quickly build them). Note we are still performing tests on this version, so please use with caution.

Thanks,

Kathryn

RE: issues by pull back the end-year by one year in 3.30

2020-06-17T05:51:12Z

Thanks Rick for the quick diagnostics. I did notice the retro feature works fine in the other example I reported a few days ago for the projection issue which is a single area model.

Looking forward to 3.30.16. In the meantime Is there a development version of 3.30 for download in case of a delay of the formal release ?

RE: issues by pull back the end-year by one year in 3.30

2020-06-16T23:32:41Z

Dan,

Thanks for testing a new situation for SS. Here's what happened.

When you reducing endyr by 1, this placed an observation in the forecast era. That should be OK and we now intentionally allow that so MSE and other procedures can know to generate expected values for these forecast observations.

The problem was that we never tested a forecast observation in a multi-area model. The call to get_expected_values() in forecast was within a loop of areas. But get_expected_values() function has an area loop within it and chaos results because the code is not sufficiently modular.

It was easy to move the call to get_expected_values outside of the area loop and all is working fine now.

Also I found that the forecast file input for benchmark range of years was not robust to years > endyr, so that code is now more robust also.

We will be releasing 3.30.16.00 with changes and a few other fixes within a couple of weeks. It will have one largish change in which we introduce custom selection of report modules so requires an upgrade of r4ss also.

RE: issues by pull back the end-year by one year in 3.30

2020-06-16T20:30:00Z

Hi Dan,

Thanks for the extra details. We will check it out and report back.

Cheers,

Kathryn

RE: issues by pull back the end-year by one year in 3.30

2020-06-16T19:50:27Z

I am using 3.30.15.

I checked more detail - the problem appears to be related to that the CPUE indices in 2015 is still retained in the file when the end year was reset to 2014. Once I removed the 2015 CPUE index for all fleets, the problem goes aways. The other data (catch, size) in 2015 could still be kept.

But this is not an issue in 3.24 .

Dan

RE: issues by pull back the end-year by one year in 3.30

2020-06-16T19:12:45Z

Dan,

We'll take a look. Which version of 3.30 are you using? We have found a couple of issues with 3.30.15.00 and also have introduced some augmentations, so we will be releasing 3.30.16 soon.

Rick

Richard D. Methot Jr. Ph.D.
NOAA Fisheries Senior Scientist for Stock Assessments

Mobile: 301-787-0241

On Tue, Jun 16, 2020 at 11:41 AM Dan Fu <VLab.Notifications@noaa.gov> wrote:

Dear SS3 team,

I'd like to report another issue I encountered with 3.30.

As part of a retrospective analysis, I am running the model by simply pulling back the end year of the model by one year, i..e, only changing in the data file:

2015 #_EndYr

to

2014 #_EndYr

Running ss.exe in the command line will hang up at the end of the estimation - it appears to generating endless warning messages to the warning file.

Performing the same operation to the original 3.24 files works fine.

Is this something you could help taking a look at? I have attached the original 3.30 files (you could reproduce the error by setting EndYr to 2014)

Thanks for your help

Dan

--
Dan Fu Stock Synthesis Virtual Lab Forum https://vlab.noaa.gov/web/stock-synthesis/public-forums/-/message_boards/view_message/10481005 VLab.Notifications@noaa.gov

RE: issues by pull back the end-year by one year in 3.30

2020-06-16T18:45:22Z

Hi Dan,

Thanks for reporting this - could you specify which version of SS 3.30 you are using that gives this issue?

Thanks,

Kathryn

issues by pull back the end-year by one year in 3.30

2020-06-16T18:41:29Z

Dear SS3 team,

I'd like to report another issue I encountered with 3.30.

As part of a retrospective analysis, I am running the model by simply pulling back the end year of the model by one year, i..e, only changing in the data file:

2015 #_EndYr

2014 #_EndYr

Running ss.exe in the command line will hang up at the end of the estimation - it appears to generating endless warning messages to the warning file.

Performing the same operation to the original 3.24 files works fine.

Is this something you could help taking a look at? I have attached the original 3.30 files (you could reproduce the error by setting EndYr to 2014)

Thanks for your help

Dan

RE: ss3.30 forecast

2020-06-11T16:55:50Z

Thanks Rick, that is very quick. Please keep me posted on the new release :)

RE: ss3.30 forecast

2020-06-11T16:35:10Z

Dan,

I have diagnosed the problem. It is not related to setting the forecast catch = 0. Rather it is a problem with the propagation of the forecast population agecomp from one time step to the next. I see how to fix it and will get a new exe posted soon. But I also want to hunt down when this problem got introduced. A similar issue occurred for another user with age at settlement = 1. That got fixed but now you encounter a similar problem with multiple seasons. Top priority now.

Rick

RE: ss3.30 forecast

2020-06-11T15:51:10Z

Hi Rick, I am using the lastest version from vLab :3.30.15.

Note that in the model, the F for fleet 6 (longline) is extremely high, although the the catch is very tiny. This is because the selectivity for fleet 6 is very poorly estimated. But I don't think this is a separate issue and should not be what cause the problem as the projection works fine in 3.24, and the catch for all fleets are set to zero in the projection anyway.

Thanks for helping out.

Dan

RE: ss3.30 forecast

2020-06-11T15:42:53Z

Hi Dan,

Sorry that you ran into a problem here, we'll take a look. Which version of 3.30 are you using?

Rick

ss3.30 forecast

2020-06-11T09:56:17Z

Dear SS3 team,

I run into an issue with the SS3.30 (lastest) constant catch forecasting, which doesn't appear to be working.

I simply set up a 10-year forecast with catch set to zero for all fleets. The SS3.24 forecast works as intended which shows SSB rapidly increasing (see attached SS3.24-forecast.png).
But the forecast for SS3.30 files failed - the SSB crashed a few years into the projection period (see attached SS3.30-forecast.png).

Parameter estimates from the 3.30 are the same as the 3.24 (I used the ss_trans.exe for the conversion).

Running the forecast with alternative catch levels under 3.30 had the same issue

I have attached the input files for SS3.24 and the problem is very easy to reproduce.

Hope you could help me look into this issue - (Most likely I have missed some configuration in the 3.30 forecast file?)

Thanks for your help.

Dan

ss3.30 forecast

2020-06-11T09:55:24Z

Dear SS3 team,

I run into an issue with the SS3.30 (lastest) constant catch forecasting, which doesn't appear to be working.

Parameter estimates from the 3.30 are the same as the 3.24 (I used the ss_trans.exe for the conversion).

Running the forecast with alternative catch levels under 3.30 had the same issue

I have attached the input files for SS3.24 and the problem is very easy to reproduce.

Hope you could help me look into this issue - (Most likely I have missed some configuration in the 3.30 forecast file?)

Thanks for your help.

Dan

ss3.30 forecast

2020-06-11T09:59:52Z

Dear SS3 team,

I run into an issue with the SS3.30 (lastest) constant catch forecasting, which doesn't appear to be working.

Parameter estimates from the 3.30 are the same as the 3.24 (I used the ss_trans.exe for the conversion).

Running the forecast with alternative catch levels under 3.30 had the same issue

I have attached the input files for SS3.24 and the problem is very easy to reproduce.

Hope you could help me look into this issue - (Most likely I have missed some configuration in the 3.30 forecast file?)

Thanks for your help.

Dan

SS3.30 forecast

2020-06-11T09:53:31Z

Dear SS3 team,

I run into an issue with the SS3.30 (lastest) constant catch forecasting, which doesn't appear to be working.

I simply set up a 10-year forecast with catch set to zero for all fleets. The SS3.24 forecast works as intended which shows SSB rapidly increasing (see attached SS3.24-forecast.png).

But the forecast for SS3.30 files failed - the SSB crashed a few years into the projection period (see attached SS3.30-forecast.png).

Parameter estimates from the 3.30 are the same as the 3.24 (I used the ss_trans.exe for the conversion).

Running the forecast with alternative catch levels under 3.30 had the same issue

I have attached the input files for SS3.24 and the problem is very easy to reproduce.

Hope you could help me look into this issue - (Most likely I have missed some configuration in the 3.30 forecast file?)

Thanks for your help.

Dan

RE: potential bug in SS_writedat(version = "3.30")

2020-06-11T07:07:36Z

Thanks. Will do that.

RE: potential bug in SS_writedat(version = "3.30")

2020-06-10T15:48:33Z

Hi Dan,

Thank you for reporting this - it is indeed a bug! I just pushed a commit to the r4ss development branch to fix this - would you mind checking if the issue is fixed by 1) re-downloading r4ss by restarting your R session, using remotes::install_github("r4ss/r4ss@development") to install and 2) trying r4ss::SS_writedat again?

Thank you,

Kathryn

potential bug in SS_writedat(version = "3.30")

2020-06-10T10:09:27Z

Hi SS3 team,

I found the the SS_writedat(version = "3.30") appears to generate a termination line for tag release and recapture input as below:

-9999 0 0 0.00000 0.00 #_terminator

which I think is not supposed to.

Maybe a bug?

Cheers,

Dan

RE: Potential Bug making data_new.ss files

2020-04-10T14:55:28Z

The change to make this line a comment is now included in the SS source code and was included in the 3.30.15 release. (Michelle, please feel free to report if this is not the case!)

Thanks,

Kathryn

Potential Bug making data_new.ss files

2020-04-10T14:51:51Z

We have a model in SS 3.30.14 with generalized size comp data. When we examine the data_new.ss file, there is a line added below where you input your size frequency bins that reads "Note: negative value for first bin makes it accumulate all smaller fish vs. truncate small fish" that is not commented out. This means that we have to manually go through the new data file, if we are using it, and comment that line out. It is especially problematic when trying to bootstrap the model because then we have to open every new datafile and comment the line out manually so that we can run the bootstrapped model. I've attached the data_new.ss file that shows the problem line (line 599 is the first instance).

Thanks

Michelle Sculley

ss3 projection

2020-04-10T14:41:24Z

Hi, I have come across an issue when doing standard ss3 projections where the stock 'crashes' in some future years with certain catch senarios ( biomass/F values is too big or too small). I I don't think this is because the the catch has been set too high, as the projection with a much higher catch senario works fine. This appears to be an numeric issue as simply rounding the catch numbers to fewer decimal places can fix the problem in some instances. I wonder if someone has come across similar issues before? Thanks. Dan

ss_trans error

2020-04-10T14:37:50Z

I am using ss_trans (version SS3.30.03.05) to convert the ss 3.24z input files (IOTC skipjack assessment) to ss3.30 but get the following error message.

''This version of ADMB only supports 250 initial parameter objects.''

The conversion did not generate the *.ss_new files. The echoinput.sso shows that that the there are only 161 Active parameters. Can I get some help on this? Much appreciated.