Run only a profile over steepness does not copy the ss3.exe on the next folder

[akatan999]

Hej

I have installed the latest version of nwfscDiag and tested jittering, retro and profiling. While the first two works without problems, profiling does not run as it is not able to copy the ss3.exe on the next folder when this is created, infact If I manually copy the exe and then run the function it works.

I run:

get = get_settings_profile( parameters = c("SR_BH_steep"),
low = c(0.65),
high = c(1.00),
step_size = c(0.05),
param_space = c('real'))
model_settings = get_settings(mydir = mydir, settings = list(base_name = "Basecase",
run = "profile",
profile_details = get))
run_diagnostics(mydir = mydir, model_settings = model_settings)

I get:

run_diagnostics(mydir = mydir, model_settings = model_settings)
Profiling over SR_BH_steep across values of 0.65, 0.7, 0.75, 0.85, 0.9, 0.95, and 1.
running profile i=1/7
Parameter names in control file matching input vector
'strings' (n=1): SR_BH_steep
line numbers in control file (n=1): 114
Wrote new file to control_modified.ss with the following changes:
oldvals newvals oldphase newphase oldlos newlos oldhis newhis oldprior newprior oldprsd
1 0.8 0.75 -1 -1 0.2 0.2 0.999 0.999 0.999 0.999 0.2
newprsd oldprtype newprtype comment
1 0.2 0 0 # SR_BH_steep
Error in (function (.x, .f, ..., .progress = FALSE) :
ℹ In index: 1.
Caused by error in check_exe():
! ss3.exe not found in ~/Max/Commitees/ICES/WKBBASS/Northern stock//Basecase_profile_SR_BH_steep/profile1 nor in the path.

sessionInfo()
R version 4.4.2 (2024-10-31 ucrt)
Platform: x86_64-w64-mingw32/x64
Running under: Windows 11 x64 (build 26100)

Matrix products: default

locale:
[1] LC_COLLATE=English_United Kingdom.utf8 LC_CTYPE=English_United Kingdom.utf8
[3] LC_MONETARY=English_United Kingdom.utf8 LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.utf8

time zone: Europe/Stockholm
tzcode source: internal

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] purrr_1.0.2 nwfscDiag_1.1.2

loaded via a namespace (and not attached):
[1] viridis_0.6.5 tidyr_1.3.1 utf8_1.2.4 future_1.34.0 generics_0.1.3
[6] xml2_1.3.6 stringi_1.8.4 lattice_0.22-6 listenv_0.9.1 digest_0.6.37
[11] magrittr_2.0.3 evaluate_1.0.1 grid_4.4.2 r4ss_1.50.0 fastmap_1.2.0
[16] jsonlite_1.8.9 gridExtra_2.3 fansi_1.0.6 viridisLite_0.4.2 scales_1.3.0
[21] codetools_0.2-20 cli_3.6.3 rlang_1.1.4 parallelly_1.39.0 munsell_0.5.1
[26] withr_3.0.2 remotes_2.5.0 yaml_2.3.10 tools_4.4.2 parallel_4.4.2
[31] coda_0.19-4.1 dplyr_1.1.4 colorspace_2.1-1 corpcor_1.6.10 ggplot2_3.5.1
[36] globals_0.16.3 kableExtra_1.4.0 curl_6.0.1 vctrs_0.6.5 R6_2.5.1
[41] lifecycle_1.0.4 stringr_1.5.1 furrr_0.3.1 pkgconfig_2.0.3 pillar_1.9.0
[46] gtable_0.3.6 glue_1.8.0 gh_1.4.1 systemfonts_1.1.0 xfun_0.49
[51] tibble_3.2.1 tidyselect_1.2.1 rstudioapi_0.17.1 knitr_1.49 htmltools_0.5.8.1
[56] rmarkdown_2.29 svglite_2.1.3 compiler_4.4.2

[chantelwetzel-noaa]

@akatan999 Thanks for posting a detailed issue. It isn't clear to me what may be occurring so this might take me a bit to dig through, but I am on it. @iantaylor-NOAA have you encountered this type of issue before with r4ss::check_exe()?

[iantaylor-NOAA]

There are a lot of different combinations possible so it's hard to know what's going on. First r4ss::profile() runs r4ss::check_exe() to look for the specified executable name and then if the path where it's found is the same as the path where the original model files are found, it should try to copy it to each profile folder. Theoretically that SHOULD work with how nwfscDiags is configured.

r4ss::profile() SHOULD work with exe in PATH, exe specified with a directory (e.g. r4ss::profile(..., exe = "c:/something/ss3.exe")), or exe in the folder with the models. However I haven't tested it with paths that use the ~/ notation, so that may be the issue.

@akatan999, is it possible to specifying the absolute path instead of using ~/? Alternatively, you could try adding the path to the exe into the nwfscDiag settings list. We should definitely improve the function to avoid the problem or at least provide a clear warning that what you're doing isn't working, but I'm not yet sure how best to do that.

[chantelwetzel-noaa]

@iantaylor-NOAA Thank you for adding your thoughts. The part the really puzzles me here is that both the retros and jitters run, only the profile is having this issue. The first lines in the run_diagnostics script is:

exe <- r4ss::check_exe(exe = model_settings$exe, dir = file.path(mydir, model_settings[["base_name"]]))[["exe"]]
model_settings[["exe"]] <- exe

with model_settings[["exe"]] used in each of the jitter, retro, and profile calls. If the ~/ was causing issues, I would expect all the runs to fail.

[shcaba]

Not sure if this is useful, but I just updated r4ss and nwfscDiag to confirm I had the latest versions and ran a likelihood profile using the SAC tool <https://github.com/shcaba/SS-DL-tool> (which implements profiling using profile()) and had no issues running it. In this implementation using this Shiny app, I just point to the folder that I want to run the profile, choose the parameter or parameters I want to run profiles for, and the range of values for the parameters, then push go. I ran an example for steepness and it worked fine.

…

On Fri, Dec 13, 2024 at 9:42 AM Chantel Wetzel ***@***.***> wrote: @iantaylor-NOAA <https://github.com/iantaylor-NOAA> Thank you for adding your thoughts. The part the really puzzles me here is that both the retros and jitters run, only the profile is having this issue. The first lines in the run_diagnostics script is: exe <- r4ss::check_exe(exe = model_settings$exe, dir = file.path(mydir, model_settings[["base_name"]]))[["exe"]] model_settings[["exe"]] <- exe with model_settings[["exe"]] used in each of the jitter, retro, and profile calls. If the ~/ was causing issues, I would expect all the runs to fail. — Reply to this email directly, view it on GitHub <#48 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6IZLRSZ4W6WBDG4TUWI3L2FMMBJAVCNFSM6AAAAABTRKLPPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBRHE2DMOJUGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- *Jason M. Cope, Ph.D.Research Fishery Biologist* *Fishery Resource Analysis and Monitoring Division* *Northwest Fisheries Science Center* *2725 Montlake Blvd. East* *Seattle, WA 98112-2013* *NOAA Fisheries* *Affiliate assistant faculty* *School of Aquatic and Fishery Sciences* *University of Washington* ***@***.*** ***@***.***> (206) 302-2417 www.nmfs.noaa.gov

[chantelwetzel-noaa]

@shcaba Thank you for confirming that this is working for you. The github action that runs each of the diagnostics is passing as well, so I think this issue is somewhere deep in the weeds with something not working given a specific set-up in the machine set-up. I hope all the information posted by @akatan999 can help us narrow down what this may be.

[iantaylor-NOAA]

@chantelwetzel-noaa, it looks like r4ss::jitter() and r4ss::retro() have copy_exe hardwired to TRUE: https://github.com/r4ss/r4ss/blob/main/R/retro.R#L132, unlike r4ss::profile(). The drawback of doing that is that for users who have the exe in the path (which is my current approach), or who provide the directory where it's found in the exe argument, they will get a warning about Warning message: In copy_SS_inputs(..., : No executable files found in .... But maybe if they're already getting the warning for 2 of the 3 functions, it's not a big deal to have it for the third.

@okenk, you were the one who improved the profile function and added the smarter check for the copy_exe settings. What do you think about just hardwiring to TRUE and causing more unnecessary warnings vs some other solution.

[chantelwetzel-noaa]

@iantaylor-NOAA I commend your eagle eyes on this! I have been staring at the calls within these function trying to find what was different in the profile script but had not found it. My intention was to set it up so it utilized @okenk changes and to make it work across options of where the exe is located. I think changing the profile function to be the same as the other two makes sense. I am okay with the warnings but if others have opinions on this I could add suppressWarnings around the call to keep the terminal clean.

[okenk]

The updates to r4ss::jitter() and r4ss::retro() to allow running the models in parallel were much more straightforward than the r4ss::profile() ones (since if you want to use starting values from previous values of the profile, you cannot run it in parallel).

Let me look into this later today. I have a pull request I owe @iantaylor-NOAA on r4ss::jitter() anyway.

[iantaylor-NOAA]

One more thought on this: it might be better to just set copy_exe = FALSE and NOT copy the executable for any of these functions than use r4ss::copy_SS_inputs() and always just reference the ones in the original model folder (or PATH or specified location). The directory for a recent assessment I worked on contains 322 copies of the same SS3 executable, including copies in each retro folder. My harddrive isn't full but those files slows down things like transferring model results to collaborators.

[akatan999]

Ian was correct, I simply changed to: "C:/Users/mascar/Documents/Max/Commitees/ICES/WKBBASS/Northern stock" And works. Thanks a lot for your help Cheers “I had never been salaried and felt that the research should be its own reward” Gorillas in the Mist Dian Fossey Massimiliano Cardinale Associate Professor Sveriges lantbruksuniversitet Swedish University of Agricultural Sciences Department of Aquatic Resources (SLU Aqua) Institute of Marine Research Turistgatan 5, 45 330 Lysekil Phone: +46 761 268 005 ***@***.******@***.***> www.slu.se/akvatiskaresurser<http://www.slu.se/akvatiskaresurser> SLU Aqua on Facebook<https://www.facebook.com/sluaqua/> Our vision: Viable fish stocks in healthy waters ***@***.*** Please consider the environment before printing this e-mail From: Chantel Wetzel ***@***.***> Sent: 13 December 2024 19:00 To: pfmc-assessments/nwfscDiag ***@***.***> Cc: Massimiliano Cardinale ***@***.***>; Mention ***@***.***> Subject: Re: [pfmc-assessments/nwfscDiag] Run only a profile over steepness does not copy the ss3.exe on the next folder (Issue #48) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. @iantaylor-NOAA<https://github.com/iantaylor-NOAA> I commend your eagle eyes on this! I have been staring at the calls within these function trying to find what was different in the profile script but had not found it. My intention was to set it up so it utilized @okenk<https://github.com/okenk> changes and to make it work across options of where the exe is located. I think changing the profile function to be the same as the other two makes sense. I am okay with the warnings but if others have opinions on this I could add suppressWarnings around the call to keep the terminal clean. — Reply to this email directly, view it on GitHub<#48 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHDZUMCKDCLREXVTHH35TRL2FMOATAVCNFSM6AAAAABTRKLPPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBRHE3TKNBXGA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

…

--- När du skickar e-post till SLU så innebär detta att SLU behandlar dina personuppgifter. För att läsa mer om hur detta går till, klicka här <https://www.slu.se/om-slu/kontakta-slu/personuppgifter/> E-mailing SLU will result in SLU processing your personal data. For more information on how this is done, click here <https://www.slu.se/en/about-slu/contact-slu/personal-data/>