On 7/28/22 11:46, Christian Meesters wrote:
This is no SLURM job file, as it contains no '#SBATCH' directives.
(Yes, they could be given on the command line).
You're correct. Sort of. Recall from the original post that I submit a
request to an intermediary which looks like this:
#e rob.sargent@work.email
#c redwood
#t 96
#
/inst/sys/installdir/sgspub/bin/83a9a2ad.hcMt 4 Bb5V32
That intermediary converts that into a slurm request which when launched
executes the "83a9a2ad.hcMt" script which is what I showed earlier. At
the slurm host this is run under an account over which I have no control
and whose umask is apparently 0027 .
It is also a bit peculiar, as you must think it is necessary to adjust
permissions. This is usually done in so-called prolog scripts, which
run prior to the job start. If your cluster deviates, you should
discuss this with your admins, as it makes your work cumbersome and
error prone. Also, it is not necessary to infer the number of CPUs on
a node as the number of CPUs available in your particular job should
be available as environment variables (see the wiki-link I have
given). Please contact your administrators about these things.
As for the job log: SLURM gathers stdout/stderr as specified by the
sbatch -o and -e directives. They should be directed to shared file
systems. Anything which is local to job, might not be accessible after
the job finished. Whether or not /sratch is a global filesystem or a
local one, cannot be understood from the context.
All in all, you should contact your local helpdesk, there are a number
of things, which might be due to the application or the cluster
settings, not parallel.
My "permission adjustments" run under the foreign account open the
permissions on "my" files for me to view, delete as necessary.
All is working according to plan from the perspective of the
intermediary and the slurm host. I was only hoping there was some
parallel nuance I could exploit to get access to the joblog file during
the slurm run.
Thanks
