PBS: incorrect qsub arguments for PBS v20 (qsub does not take -wd or -t)

[jeffcbecker]

qsub.jl has incorrect qsub arguments for PBS. We're currently on PBS v20, and qsub does not take -wd or -t

[diegozea]

I am having the same problem:

$ qsub --version
pbs_version = 20.0.0

julia> # Add the PBS workers
       addprocs_pbs(np, qsub_flags=qsub_flags)
qsub: invalid option -- 'w'
qsub: invalid option -- 'd'
qsub: invalid option -- 't'
usage: qsub [-a date_time] [-A account_string] [-c interval]
	[-C directive_prefix] [-e path] [-f ] [-h ] [-I [-X]] [-j oe|eo] [-J X-Y[:Z]]
	[-k keep] [-l resource_list] [-m mail_options] [-M user_list]
	[-N jobname] [-o path] [-p priority] [-P project] [-q queue] [-r y|n]
	[-R o|e|oe] [-S path] [-u user_list] [-W otherattributes=value...]
	[-v variable_list] [-V ] [-z] [script | -- command [arg1 ...]]
       qsub --version
Error launching workers
ErrorException("")
Int64[]

julia> versioninfo()
Julia Version 1.8.3
Commit 0434deb161e (2022-11-14 20:14 UTC)
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 8 × Intel(R) Xeon(R) Gold 6242R CPU @ 3.10GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-13.0.1 (ORCJIT, haswell)
  Threads: 1 on 8 virtual cores
Environment:
  LD_LIBRARY_PATH = 

(@v1.8) pkg> st
Status `~/.julia/environments/v1.8/Project.toml`
  [336ed68f] CSV v0.10.9
  [34f1f09b] ClusterManagers v0.4.4
  [a93c6f00] DataFrames v1.5.0
  [51bafb47] MIToS v2.11.1
⌃ [14b8a8f1] PkgTemplates v0.7.31
⌃ [91a5bcdd] Plots v1.38.8
⌃ [c3e4b0f8] Pluto v0.19.22
  [f3b207a7] StatsPlots v0.15.4
⌃ [b8865327] UnicodePlots v3.4.1
  [8ba89e20] Distributed
Info Packages marked with ⌃ have new versions available and may be upgradable.

[kescobo]

By chance do you know what the equivalents for v20 are? I'm not so familiar with qsub. In particular, is there a form we could use that would work for previous versions as well, or do we need to have a conditional check?

[diegozea]

I do not know if there is a mapping between the different versions 😬

[MilesCranmer]

Looks like I'm getting hit with this too: MilesCranmer/PySR#419.

Is there a workaround?