For a given job route, you should use `set_default_xcount` in your
to set a default RequestCpus for a given route. orig_RequestCpus
gets set to the original value of RequestCpus from the remote
submitter and if they don't bother to set this, it will default to
Depending on how you have your CE configured, the order of the job
routes may indeed be random, so I suggest specifying the order via
JOB_ROUTER_ROUTE_NAMES as documented here:
Additionally, it's important to note that the job router ClassAd
functions (copy_, set_, etc.) have an order of operations and I've
seen this trip up other users when writing routes:
On 6/22/20 8:24 AM, Fischer, Max (SCC)
weâve just had an HTCondor-CE Job Router _expression_ behave weirdly because we seem to mishandle the number of CPUs requested. This seems to be wildly different from regular Condor.
Since the evaluation order of a JRE seems random, we sometimes end up with the correct value (evaluated by the CE) and sometimes not (the initial job value).
In short, what *is* the correct job attribute to check the number of requested cpus in HTCondor-CE?
Looking at a known 8-Core job:
It seems job RequestCpus is a dummy. Using it in the JRE leads to the unexpected behaviour depending on evaluation order, and orig_RequestCpus always ends up as 1. Is this correct? This is what we usually use in Condor, so that came as a surprise.
Other candidate attributes are: OriginalCpus, xcount, remote_SMPGranularity (from GlideinWMS?), but none of these seem documented either for HTCondor-CE or HTCondor itself. Can we use them? Should we use them?
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
You can also unsubscribe by visiting
The archives can be found at: