On Tue, 14 Feb 2017, William Hay wrote:
...
qsub -ac Template=GPU -l gpu=1 script
Your jsv could spot that a Template had been requested and fill in
sensible defaults based on other requests. If no template is requested
users have access to the full power of this fully operational caommand
line.
This is sort of along the lines of what we do already to help emulate more
interesting forms of parallel job request ("I want 2 compute nodes/8 MPI
ranks, launching 4 MPI ranks per node and 6 OpenMP threads per rank");
although, as we're using a client-side JSV, I don't restrict myself to
using "-ac" since I can delete the figments of my imagination before they
hit the server.
To do this, we've had the concept of a node_type for some years now - a
requestable complex, taking the value of something looking like
"24core-128G". It's turned out to be pretty useful.
I was thinking about extending it for co-processor cards in general.
Adding an optional 3rd element, e.g. "24core-128G-2K80", and combining
with a "-l co_k80=<num>" seems to let me derive a job request to allocate
fractions of a compute node's CPU and memory (the numerator being the
number of cards per node requested, the denominator being the cards per
node).
I'm not sure what purpose contexts originally served in Grid engine but
AFAICT their only practical use is to allow users to pass info to JSVs
without affecting anything important.
I'd be interested to know what contexts were for: I was considering them
for something at one point as I was hoping they'd end up in the accounting
file. They didn't :(
You can do almost anything in Grid Engine with a combination of JSVs and
carefully designed started_methods. The hard question is whether you
should.
I appear to have an extreme case of hatred of extraneous boiler plate in
job scripts and have been wondering if I've gone way too far. My JSV is
pretty big now although, thankfully, that appears to be the main place I'm
hiding my queue-related ugly.
Cheers,
Mark
_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users
