r4ss

RE: Error in SS_output function

2022-10-12T15:53:22Z

Laura, you were not the only one. We'll add to the next release notes a link for updating r4ss.

Rick

RE: Error in SS_output function

2022-10-12T15:49:53Z

Thank you, Kelli. I should have tried that version before.

RE: Error in SS_output function

2022-10-12T15:21:23Z

Laura,

Thank you for posting your issue regarding using `r4ss::SS_output()` with SS3.30.20. I ran this version of Stock Synthesis with your input files and tried to read the output into R using {r4ss}. I was successful when using the GitHub version of {r4ss}, which can be installed via

unload(package = "r4ss")

remotes::install_github("r4ss/r4ss")

library(r4ss)

The CRAN version of {r4ss} is in the process of being updated to work with the newest version of Stock Synthesis. Sorry for the delay in this update and please let us know if you have difficulties installing the GitHub version.

Error in SS_output function

2022-10-12T11:52:21Z

I've updated to SS to the newest version (3.30.20.00) and updated the r4ss package and get errors with function SS_output. I get no special warnings running SS with the newest version only in r4ss reading the outputs. It finishes reading files, finishes dimensioning but after getting the covar files it gives an error:

Got covar file.
Error in `$<-.data.frame`(`*tmp*`, "MeaneffN/MeaninputN", value = logical(0)) :
replacement has 0 rows, data has 2

I attach the necessary files to run the model in case it's easier for you.

RE: End r4ss support for 3.24 models?

2022-07-29T21:35:29Z

We didn't hear any concerns about deprecating the r4ss functions related to 3.24 models as suggested in this forum thread, so those functions are now deprecated as discussed my the recent forums message "New version of r4ss released..."

New version of r4ss released (which might break your code, but fixes shouldn't be too hard)

2022-07-29T21:32:45Z

Hi r4ss users,

Recent changes merged into the main branch of r4ss on github include some things that could break your code if you run likelihood profiles, retrospectives, or jitters. The release notes are pasted below.

Sorry for rolling this out on a Friday afternoon. If you have problems with the revisions please get in touch via this forum, email, or GitHub issue. To work around any unexpected issues, you can either install the CRAN version of r4ss (version 1.44.0) which was released in May, or install a github version from a couple weeks ago before the major changes started getting integrated via remotes::install_github("r4ss/r4ss@c7ecd71b").

-Ian

Release notes for r4ss version 1.46.1 copied from https://github.com/r4ss/r4ss/releases:

This release includes a few significant changes that should make the {r4ss} package easier to use and maintain.
However, it includes some breaking changes with renamed functions names and renamed or deprecated input arguments.

The main changes (also described in NEWS.md) are as follows, where details and discussion of the changes are available via the numbered pull requests and issues linked below:

Major revamp of all functions that run the Stock Synthesis executable
#722
- Functions that run the executable have been renamed:
  #723:
  - run_SS_models() -> run() (now has defaults which allow you to
    simply call run() in the current working directory as well as
    and better support for having the Stock Synthesis executable in
    your path)
  - SS_profile() -> profile()
  - SS_doRetro() -> retro()
  - SS_RunJitter() -> jitter()
  - SS_tune_comps() -> tune_comps()
- Functions have more consistent inputs (e.g., always dir instead of
  mydir, File, or masterdir, and now defaulting to the current
  working directory)
- Input show_in_console = FALSE can be used with all these functions
  and will pipe output to a text file keeping R console cleaner while
  models run
Deprecates functions that relate to 3.24 models, like
SS_readdat_3.24() (although SS_output() is still compatible back
to version 3.24) #718
Introduces new "simple_small" example model but removes older
examples, reducing total package size #700
Uses new columns names in BIOLOGY output #711
Numerous bug fixes
Adds dependency on 'tidyr'
Removes never-completed function SSbootstrap()

End r4ss support for 3.24 models?

2022-07-06T21:31:21Z

Hi r4ss users,

Kathryn Doering and I have been having a discussion about discontinuing support for Stock Synthesis 3.24 models in the {r4ss} package. One proposal, discussed at https://github.com/r4ss/r4ss/issues/702, would be to deprecate all the functions related to reading and writing input files. This would leave the SS_output() and SS_plots() functions still working for 3.24 models. If necessary, we could maintain support for 3.24 in SSsummarize() and SSplotComparisons() for the purpose of comparing old to new models. We do not plan to support functions related to things like likelihood profiles and data weighting for older versions.

If you are still using a 3.24 model and see a need for these functions, please either reply to this forum message, post on the github issue linked above, or write directly to me and Kathryn at ian.taylor@noaa.gov and kathryn.doering@noaa.gov.

Also, if you would like support in converting 3.24 models to the current version of Stock Synthesis, please get in touch.

-Ian

RE: Error reading in Report files for profile analysis

2021-09-17T14:00:37Z

Thanks so much, Chantel! That seemed to do the trick!!!

Laura

RE: Error reading in Report files for profile analysis

2021-09-16T20:40:32Z

Hi Laura,

Can you try to update your r4ss via the following command:

remotes::install_github("r4ss/r4ss")

There was a recent change in the Report file that required some updating for the model comparison code. Hopefully, if you update r4ss this issue will be resolved but please let us know if it does not.

Chantel

Error reading in Report files for profile analysis

2021-09-16T20:09:17Z

Hi all,

I am running a profile on ln(R0) and using the code at https://rdrr.io/rforge/r4ss/man/SS_profile.html as a guide. Everything is working until I try to run the following:

profilemodels <- SSgetoutput(dirvec=mydir, keyvec=1:Nprofile)

When I submit this line, I get the following:

length(keyvec) as input to SSgetoutput: 21
length(dirvec) as input to SSgetoutput: 1
getting files with key = 1
reading output from C:/SS/mullet2021/final/profile/Report1.sso
Error in 1:ncol(morph_indexing) : argument of length 0

I'm not sure how to move forward and would appreciate any help in diagnosing the issue. Thanks in advance!

Cheers,

Laura

RE: jitter analasis

2021-07-28T06:09:50Z

Hi Kathryn & Kelli,

I reinstalled r4ss and it works fine with other executable names now.

Thanks for the quick fix.

Cheers,

Dan

RE: jitter analasis

2021-07-27T13:27:06Z

Hi Dan,

Kelli realized it was just a bug in 1 line of code in the SS_RunJitter function that was causing the error when using a different model name. The code assumed changing the model name also changed the par file name, when the par file is always called ss.par regardless of the exe's name.

I just pushed the fix to the main branch of r4ss; when you have the chance, would you mind re-installing r4ss using remotes::install_github("r4ss/r4ss"), restarting the R session, then trying the SS_RunJitter function while using the ss_win.exe as the model again?

Thanks,

Kathryn

RE: jitter analasis

2021-07-27T12:40:17Z

Hi Dan and Kelli,

Dan you are right, there is a difference in par files between 3.30.16 and 3.30.17 in some models. In 3.30.16, some models that did not use implementation error still had implementation error parameters (all 0) created. In 3.30.17, only models that use implementation error have the implementation error parameters. If someone wants to use a 3.30.16 par file with 3.30.17 for a model without implementation error, all that would be needed is to delete the implementation error parameteters from the par file.

Dan, thanks for also noting that SS_RunJitter will not work with models named something other than ss.exe. It would be great to make this function more flexible.

Thanks,

Kathryn

RE: jitter analasis

2021-07-27T12:31:03Z

Thanks Kelli for checking this so quickly. What you described seems to suggest a difference between 3.16 and 3.17 and In either case SS_RunJitter() works when the model is named "ss". That will work for me.

Cheers,

Dan

RE: jitter analasis

2021-07-27T12:07:06Z

Dan, Thanks for posting and providing your input files. I did not take the time to work through SS_RunJitter() when the model is named something other than ss but I did try to run your model with my executable, which happens to be version #V3.30.16.00 on this machine, and I was not able to run the model without first starting from the control file. After the model converged, I compared the ss.par that you attached to the one from the estimation and they differed at line 104. The new par file has the following two additional lines

```

# Fcast_impl_error:
0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000 0.00000000000
```

This could also be contributing to SS_RunJitter() failing because it runs successfully on my machine with the new par file.

Best,

Kelli

RE: jitter analasis

2021-07-27T11:28:25Z

OK, the function will work if I change the parameter "model" from "ss_win" to "ss". it probably has to do with the naming of the underlying par file. Anyway, the parameter doesn't seem to work properly and may need a fix.

Thanks

Dan

jitter analasis

2021-07-27T07:01:45Z

Dear SS team,

I have some trouble running Jittering using r4ss (1.43.0) and SSV3.30.17.00.

The input files and par files (attached) runs work on windows command line but running SS_RunJitter fails:

> jit.likes <- SS_RunJitter(mydir=mydir,model = 'ss_win',Intern = FALSE,Njitter=Njitter)
reading from STARTER.SS
reading from data file
Data read sucessful 999

reading forecast file
reading from control file
End of control file successful! 999
read parm file
Error trying to open parameter input file ss.par
Table of likelihood values:
< table of extent 0 >
Warning message:
In shell(cmd = command, intern = Intern) :
'ss_win -nohess' execution failed with error code 1

Would be please be able to take a look at this and see whether this is an issue with this function or my input files (attached)?

Much appreciated,

Dan

RE: Error in creating output for simple length model

2021-05-04T18:15:30Z

Fantastic! Thanks so much! That worked!!!

Laura

RE: Error in creating output for simple length model

2021-05-03T20:59:22Z

Hi Laura,

Thanks for the question and for providing the model files! Could you try updating r4ss by running remotes::install_github("r4ss/r4ss@main") in the R console, then restarting the R session and running r4ss::SS_output again?

I ran the model using the files you provided with SS 3.30.16 and then used SS_output; it ran fine for me, so I suspect the issue is a bug in an older version of r4ss.

If you are still having issues after updating r4ss , could you let me know which version of SS is being run so I can test?

Thank you,

Kathryn

Error in creating output for simple length model

2021-05-03T19:15:09Z

Hello all,

I am trying to run essentially the LIME method in SS, as suggested by the primary author of LIME. When I submit the following line to R:

output <- SS_output(mydir,printhighcor=100,printlowcor=100,printstats=FALSE,ncols=61,forecast=FALSE)

I get the following error:

Error in 1:ncol(morph_indexing) : argument of length 0

I would greatly appreciate any guidance.

Thank you for your time.

Cheers,

Laura

info on some small but visible changes to r4ss plots

2021-04-21T00:15:28Z

Hi r4ss users,

I just made a variety bunch of little changes to the r4ss code which impacts the plots. A full list is on github with links to code changes: https://github.com/r4ss/r4ss/pull/523.

The most visible differences, the first of which could potentially be an immediate pain or benefit to anyone in the middle of using these things for assessment reports are the following:

- change the default dimensions for all plots to either a little shorter than before (now 4 inches by 6.5 inches vs 5 x 6.5 previously) so that two figures can fit on a single page, or taller (now 6.5 x 6.5). The plots that seemed best suited to the taller format are controlled by a new "pheight_tall" input to the SS_plots() function and the number of panels in the multi-figure plots are increased to fill up the additional space.

- adding an underscore to the "_SS_output*.html" files so they appear before the png files in the directory of plots

- change the order of the composition plots so you don't have to scroll through a bunch of things to see the summary plots showing all the fleets together with comps aggregated across years which I find myself looking for first

If any of this causes problems, some options you could take are to install the version of r4ss immediately prior to these changes via the command remotes::install_github("r4ss/r4ss@d51fd9d"). Or in the case of the plot dimensions, you can go back to the old dimensions by specifying SS_plots(model, pheight = 5, pheight_tall = 5).

As always, please let me know via this forum, email, or github issues if you have questions, comments, or concerns.

-Ian

RE: Need help understanding r4ss catch plot (observed vs. predicted)

2021-03-29T22:46:08Z

Thank you for the clarification. I really appreciate it. That is very helpful.

RE: Need help understanding r4ss catch plot (observed vs. predicted)

2021-03-29T22:36:11Z

Hi Thom,

The numbers/biomass issue is surely the source of the difference in this figure. See discussion at https://github.com/r4ss/r4ss/issues/312 about this.

An easy, short-term fix would be to expand the figure caption for any model with any catch input in numbers to note that this figure is comparing apples to oranges.

-Ian

On Mon, Mar 29, 2021 at 3:26 PM Thom D. Teears <VLab.Notifications@noaa.gov> wrote:

Thanks for your reply Rick. I am using the hybrid F method and the max F is set to 2.95. The highest F value in the exploitation section of the report file is 1.64. In the catch section of the report file it indicates observed and expected values that are nearly identical for most years.

I was wondering if it is because my catch for fleet 1 is in numbers whereas the graph is in metric tons. Could that be the problem?

Thanks,

Thom

--
Thom D. Teears Stock Synthesis Virtual Lab Forum https://vlab.noaa.gov/web/stock-synthesis/public-forums/-/message_boards/view_message/14278696 VLab.Notifications@noaa.gov

RE: Need help understanding r4ss catch plot (observed vs. predicted)

2021-03-29T22:26:57Z

Thanks for your reply Rick. I am using the hybrid F method and the max F is set to 2.95. The highest F value in the exploitation section of the report file is 1.64. In the catch section of the report file it indicates observed and expected values that are nearly identical for most years.

I was wondering if it is because my catch for fleet 1 is in numbers whereas the graph is in metric tons. Could that be the problem?

Thanks,

Thom

RE: Need help understanding r4ss catch plot (observed vs. predicted)

2021-03-29T22:03:47Z

Hi Thom,

I think I would need to get more info to be sure. What F method are you using? What is the catch se? Is F hitting the max possible F level set in the control file? It might help to look at the source info for the plots. The sections of the report.sso labelled EXPLOITATION and CATCH have good details that may help.

Rick

Need help understanding r4ss catch plot (observed vs. predicted)

2021-03-29T21:31:52Z

Hello all,

I was wondering if anyone might be able to help me understand the catch plot generated by r4ss that I have attached below. The total catch likelihood is very low (1.48E-05) suggesting a good fit to the landings however, the plot shows that the fit is not what I expected.

Any help would be greatly appreciated.

Thanks,

Thom

RE: SS_doRetro

2020-12-21T23:06:44Z

Thanks for chiming in, Jemery. It's good to hear what the current approach is in your part of the world.

Here are a bit more on this subject:

[UPDATE: just saw that some of this email is redundant with what Kathryn just wrote, but sending anyway.]

You are correct about the bias adjustment being set automatically to 0 in the forecast years, but from what I can tell, the years with data removed by the retrospective settings are not considered forecast years. That is, in the SPAWN_RECRUIT table in Report.sso ($recruit is r4ss) the "era" column remains as "Main" or "Late" and the "biasadjuster" is unchanged and non-zero for those years. However, automatically setting the bias adjustment to 0 for those years would be an easy, if incomplete, solution to the problem of bias adjusted recdevs that have zero information in the data. Automatically adjusting the ramp parameters would probably be a better solution, but we should do some research to show if this makes sense in general.

On data-weighting, I agree with Rick's suggestion that the automated tuning options are the idea, but we should make sure to keep track of the resulting parameter estimates to see how they change when the recent data is removed. Kathryn updated the SS_tune_comps() function in r4ss to automate the iterative re-weighting process for Francis and McAllister-Ianelli data weighting methods (see note here https://github.com/r4ss/r4ss/issues/450) and in theory that could be combined with the SS_doRetro() function to automatically tune the retro models. But again the results might not always be sensible and the interpretation of any retrospective pattern might be different if the data weights are changing substantially.

RE: SS_doRetro

2020-12-21T23:01:01Z

I should have also said, this would not address all the complexities of your input, of course!

RE: SS_doRetro

2020-12-21T22:57:20Z

Hi Jemery,

These are good points, thank you for bringing them up!

I just wanted to bring up that there is now functionality to automatically reweight using Macallister-Ianelli or Francis weighting in the SS_tune_comps function in r4ss: https://github.com/r4ss/r4ss/blob/development/R/SS_tune_comps.R .

It should be possible to add a routine to r4ss that does retrospectives with iterative reweighting, if there is enough interest. I would be happy to help out with this, although like Rick mentioned, not on a very short timeline!

Perhaps this should be opened and discussed as an issue in the r4ss repository? Please feel free to open one.

Thanks,

Kathryn

RE: SS_doRetro

2020-12-21T22:40:43Z

Jemery,

Thanks for the additional information and clarifications. I agree that doing iterative reweighting would be too difficult to integrate into his procedure, so it would be better to use the extra_sd parameter for indexes and the Dirichlet-Multinomial for composition data. Whether or not you should allow these to change while doing a retro is an interesting question that warrants some deeper thought.

Most team members are taking some time off for the holidays, so we are unlikely to do anything on this until January. Please get back in touch then if you don't hear from us.

Rick

RE: SS_doRetro

2020-12-21T22:11:17Z

Hi,

Sorry for the slow response – I’m not sure if this is still of interest. We routinely conduct retrospectives with our SS assessments now and typically use the SS_doRetro() function, as a shortcut, and take advantage of all the plotting structures and outputs that are produced.

However, we routinely modify the SS input files produced by these functions and re-run them – to modify some of the defaults from SS_doRetro. There are a number of changes that could be made, including modifying the bias adjustments, that Ian refers to below. We typically ignore that nuance. However, as I understand it, SS now automatically truncates the part of the bias adjustment that slopes off on the right hand side, either at the last year of recruitment estimates or the last year of input data, so if the right hand bend in the bias adjustment happens early enough (the entry in the control file with comment #_last_yr_fullbias_adj_in_MPD), this truncation may still result in some adjustment of the bias ramp as years of data are dropped out (perhaps?). I’m sure Ian Taylor or others can correct any of these details that I may have misinterpreted.

Here is the standard warning indicating this “truncation”

bias adjustment ramp extends into forecast; biasadj set to 0.0 internally for forecast years

This raises two additional points where there could potentially be further adjustments to each of the retrospective runs. We address the first of these, but ignore the second.

(i) The last year that recruitments are estimated (the entry in the control file with the comment # last year of main recr_devs; forecast devs start in following year). I don’t think SS_doRetro adjusts this value in the control file. We go in and adjust this manually, decreasing the value by 1 for each year of data that is left out of the model run. If you don’t do this and remove 5 years of data, the last recruitments being estimated can give weird recruitment spikes, as they are no longer being constrained by any information on recruitment from the length and age data. We don’t think this is behaviour that you want to be examining in a retrospective analysis – so we adjust these last year of recruitment estimates values manually, re-run SS in each sub-directory and then use the SS plotting (re-running this) that has been nicely set up by SS_doRetro

(ii) Iterative reweighting. As age and length data are removed from the runs, in theory the standard iterative reweighting done to tune the input and output variances should be repeated. Typically, we don’t repeat this procedure for any of the standard sensitivities that we do, such as varying h or M (this would take too long) nor do we do this for our retrospective analyses. It could be argued that this should be done, both for sensitivities and for retrospectives. This is not something that could be easily automated in SS_doRetro, partly because there are different versions of iterative reweighting used in different assessments. This does beg the question of whether others will routinely iteratively re-weight any standard sensitivities that are run for assessments? The extra time required to do this used to make it prohibitive (especially with manual iterative-weighting), but with automation of iterative re-weighting, it seems this is something that could be done. My question is should it be done?

ciao

Jemery

From: Ian Taylor <VLab.Notifications@noaa.gov>
Sent: Thursday, 10 December 2020 5:05 AM
To: VLab.Notifications@noaa.gov
Subject: [Stock Synthesis - r4ss] SS_doRetro

Glad you got it working, Laurie. The SS_doRetro() function in r4ss just modified the starter file and re-runs SS, so just saves time but doesn't differ from going through those steps manually. All CPUE and comp data from after the chosen retro year are ignored in those analyses, so removing them manually should have the identical effect. To confirm this, you could use a model for which the standard retro process works without error.

I should note that one subtlety about retrospective analyses in SS is the use of the bias adjustment, where the inputs provided for when the recruitment bias adjustment ramps down aren't automatically shifted as you remove data (and thus information about the most recent recruitments). The line between the main and late/forecast recdevs is also unchanged. Thus, the retro model you get may not match the settings you would have chosen if you were setting up that model manually. Adding automatic adjustment is on the wishlist but hasn't been prioritized so far.

--
Ian Taylor Stock Synthesis Virtual Lab Forum https://vlab.noaa.gov/web/stock-synthesis/public-forums/-/message_boards/view_message/12846749 VLab.Notifications@noaa.gov

RE: SS_doRetro

2020-12-11T06:28:18Z

Thanks, I tried out my code on another stock and got the same results as r4ss version, so it looks like the problem is fixed. Thanks for the help. Laurie ⁣Sent from Blue On Dec 9, 2020, 6:05 PM, at 6:05 PM, Ian Taylor wrote: >Glad you got it working, Laurie. The SS_doRetro() function in r4ss just >modified the starter file and re-runs SS, so just saves time but >doesn't differ from going through those steps manually. All CPUE and >comp data from after the chosen retro year are ignored in those >analyses, so removing them manually should have the identical effect. >To confirm this, you could use a model for which the standard retro >process works without error. > >I should note that one subtlety about retrospective analyses in SS is >the use of the bias adjustment, where the inputs provided for when the >recruitment bias adjustment ramps down aren't automatically shifted as >you remove data (and thus information about the most recent >recruitments). The line between the main and late/forecast recdevs is >also unchanged. Thus, the retro model you get may not match the >settings you would have chosen if you were setting up that model >manually. Adding automatic adjustment is on the wishlist but hasn't >been prioritized so far. > > >-- >Ian Taylor Stock Synthesis Virtual Lab Forum >https://vlab.noaa.gov/web/stock-synthesis/public-forums/-/message_boards/view_message/12846749 >VLab.Notifications@noaa.gov

RE: SS_doRetro

2020-12-09T18:05:03Z

RE: SS_doRetro

2020-12-09T17:34:53Z

Many thanks for this. I did manage to run a retrospective analysis by peeling back the CPUE and length compositions. A question then is do these give the same result as do_ssRetro? Laurie ⁣Sent from Blue On Dec 9, 2020, 5:29 PM, at 5:29 PM, Richard Methot wrote: >Hi Laurie, > >I'm not sure that we will be able to solve this problem as all of our >development and investigation energy has been with SS3.30 for some time >now. I looked at the input files and noticed that there are >time-varying Qdevs and also selectivity devs. SS3.24 was not very >advanced with regard to dealing with time-varying parameters that were >designed for the base model but then overlapped into the forecast >period when doing the retro. So my recommendation is to modify the >year range for the time-vary parameters such that they do not overlap >into forecast when doing the retro. I'm not certain this will fix the >problem, but it is my best suggestion at this time. > >Rick > > > > >-- >Richard Methot Stock Synthesis Virtual Lab Forum >https://vlab.noaa.gov/web/stock-synthesis/public-forums/-/message_boards/view_message/12845850 >VLab.Notifications@noaa.gov

RE: SS_doRetro

2020-12-09T17:29:42Z

Hi Laurie,

I'm not sure that we will be able to solve this problem as all of our development and investigation energy has been with SS3.30 for some time now. I looked at the input files and noticed that there are time-varying Qdevs and also selectivity devs. SS3.24 was not very advanced with regard to dealing with time-varying parameters that were designed for the base model but then overlapped into the forecast period when doing the retro. So my recommendation is to modify the year range for the time-vary parameters such that they do not overlap into forecast when doing the retro. I'm not certain this will fix the problem, but it is my best suggestion at this time.

Rick

RE: SS_doRetro

2020-12-09T17:11:53Z

It is 3_3.24z Laurie ⁣Sent from Blue On Dec 9, 2020, 5:09 PM, at 5:09 PM, Kelli Faye Johnson wrote: >Sorry about this Laurie. We were able to recreate the problem locally >on a windows machine, but can you let us know which 3.24 exe you are >using? Typically, there is a letter after it, like 3.24Z. > > >-- >Kelli Faye Johnson Stock Synthesis Virtual Lab Forum >https://vlab.noaa.gov/web/stock-synthesis/public-forums/-/message_boards/view_message/12845342 >VLab.Notifications@noaa.gov

RE: SS_doRetro

2020-12-09T16:59:35Z

Sorry about this Laurie. We were able to recreate the problem locally on a windows machine, but can you let us know which 3.24 exe you are using? Typically, there is a letter after it, like 3.24Z.

RE: SS_doRetro

2020-12-09T16:56:55Z

It also fails with the windows exe, but gives a different error message "Illegal male selex option selected for fleet 2"

SS_doRetro

2020-12-09T07:38:41Z

I have problems with the retrospective analysis, as set up using SS_doRetro

I am using SS 3.3.24 under linux and want to do a retrospective analysis. The "0" scenario runs as normal.

I ran SS_doRetro and I get this error

Error trying to open data input file ss3_3.24z.dat
reading from STARTER.SS
reading from data file
Data read sucessful 999

reading forecast file
reading from control file
Error: Invalid index -6 used for array range [0, 34] in "int& ivector::operator() (int i)".
array bound exceeded -- index too low

The retrospective files created by SS_doRetro are attached, and the master files is in the zip file.

Laurie

RE: movement matrix bug

2020-08-11T15:49:10Z

Hi Dan,

Thanks for reporting this! From your description it does look like a bug. I will try to replicate the problem and push a bug fix as soon as possible, posting on the forum when finished.

Thanks,

Kathryn

movement matrix bug

2020-08-11T07:14:46Z

Dear SS team,

I think there is probably a bug in SS_output() relating to reading in the movement matrix:

> dat <- out$movement
> head(dat)

1 1 1 2 2 8 age0 age0 age0.00159169 age0.00228114 age0.00326826 age0.00468052 age0.00669895 age0.00957944 age0.0136814
2674 1 1 2 1 2 8 0 0 0.39452600 0.51201700 0.62819500 0.73123200 0.81416300 0.87584900 0.919094000
2675 2 1 1 2 2 8 0 0 0.23376300 0.09266880 0.03306130 0.01131700 0.00381740 0.00128123 0.000429289

It appears that the correct column headers ('seas','GP','source_area','dest_area',...) are missing and the first row of the estimates have been converted to column headers.

I am using SS3.30.15.07-safe and the development version of r4ss from github.

Cheers,

Dan

RE: an error using 3.30.15

2020-04-09T20:08:50Z

Excellent. I am glad the newest version of r4ss worked for you.

RE: an error using 3.30.15

2020-04-09T20:08:50Z

Thank you. I have forgotten to update r4ss via GitHub. Now it works well with 3.30.15, no errors.

ps

RE: an error using 3.30.15

2020-04-09T20:08:50Z

Thank you for reporting that you are having an issue with r4ss. Unfortunately, I was not able to recreate the issue on my machine. I am curious if you have updated your version of r4ss using devtools::install_github('r4ss/r4ss') such that the latest fixes are available to work with version 3.30.15 of Stock Synthesis? Also, it would be helpful if you clarify what R function you were calling when the error occurred. I am assuming that the reading of the Report.sso went fine and the error was generated from SS_plots()? Please let me know if this is incorrect. Again, thank you for reporting that you are having issues and we hope that we can get this fixed today once we have more information.

an error using 3.30.15

2020-04-09T20:08:50Z

Hi!

I have the following message in r4ss script when I use the newest ss3 version (3.30.15):

Starting length comp data plots (group 13)
Error in round(vals, sampsizeround) :
non-numeric argument to mathematical function

But there is no warning messages in warning.sso

The previous ss3 version (3.30.14) works well - no errors with r4ss.

r4ss SS_output () error: can't find report file

2020-04-09T21:16:15Z

I am running SS3 V3.30.14 on Mac OS. The SS run was completed successfully, and the Report.sso file is generated. However, when I run the function SS_output() in r4ss package (version 1.36.1), R version is 3.4.0. I got error saying "can't find report file", but Report.sso is right there. See below for the error message. Any tips are extremely appreciated.

> library(r4ss)
> dd=SS_output('~/Desktop/Review_workshop_striped_bass_2019_NewBern_NC/AR_SS_model⁩/model_1',covar=T) #use covar=F if no var-cov matrix is produced;end parth is the folder where ss outputs
Some stats skipped because the .par file not found:

Error in SS_output("~/Desktop/Review_workshop_striped_bass_2019_NewBern_NC/AR_SS_model\u2069/model_1", :
can't find report file: ~/Desktop/Review_workshop_striped_bass_2019_NewBern_NC/AR_SS_model⁩/model_1/Report.sso

Trouble understanding selectivity plot with male offset

2020-04-09T20:08:50Z

Hello all,

I am struggling to understand the selectivity plot from r4ss when using the male offset option. I have included the plot as an attachment below. I am using a double normal (pattern 24) with the male offset (option 1). The female selectivity has taken an asymptotic shape but it plateaus at 0.25 for some reason instead of at 1.0 as I would expect. The male selectivity looks dome-shaped. I would expect both curves to be asymptotic.

Any help with understanding these selectivities would be greatly appreciated. Thanks in advance.

Cheers,

Thom

SSmohnsrho and start year

2020-04-09T21:14:34Z

Hej everybody and I hope all of you is having a good summer, I use often SSmohnsrho but I have a doubt about the use of the startyr in the function. I have tested SSmohnsrho changing the startyr but i always get the same results. If I run:

SSmohnsrho (retroSummary, endyrvec = endyrvec, startyr = 2013)

I get:

$AFSC_Hurtado_SSB [1] -0.0927447 $AFSC_Hurtado_Rec [1] 1.651444 $AFSC_Hurtado_F [1] 0.1117054

If I run:

SSmohnsrho (retroSummary, endyrvec = endyrvec, startyr = 2016)

I get:

$AFSC_Hurtado_SSB [1] -0.0927447 $AFSC_Hurtado_Rec [1] 1.651444 $AFSC_Hurtado_F [1] 0.1117054

So exactly the same values irrespective of the starting year.

Cheers

Max

SS_RunJitter

2020-04-09T21:13:20Z

According to r4ss help function, SS_RunJitter should run with the hessian on with -nohess added as an extra element in the command. However, when I run SS_RunJitter, the dafault seems to be with -nohess instead.

Cheers

Max

R4SS report equilibrium yield

2020-04-09T21:12:31Z

Hello,

I am wondering exactly what the equil_yield object from the SS_output is. Is this the equilibrium yield at different levels of F or SPR?

Thanks,

Meg