...
Note that the ":group0" addition searches for a node with the property "group0". On cyrus1, this property will be present on all nodes designated for the queuing system. Nodes n017 through n021 will be reserved for software unable to use the queue system. On quantum2, this group0 designation should not be included. (If this proves to be difficult for users to manage, we will simply remove those non-designated queues from the configuration manager.)
Some or all of these arguments can also be given at the command line. Command-line settings override any settings in the script.
...
- Users should request the lowest possible walltime for their jobs, since the queue system will need to "block out" the entire 24-hour period when no walltime is specified. This is analogous to a customer arriving at a busy barbershop and explaining that he only needs a "very quick trim."
- If users do not specify a queue in their script, the "default" queue is used. This queue has a walltime limit of 24 hours, a node count limit of 1, and a default priority of 60; in other words, it is less desirable than any of the queues listed in the tables below. Specifying a queue with the "#PBS -q" option is a good idea.
- Input and output to files do not seem to be as immediate as when running directly from the command line. Users should not count on immediate access to program output.
- Users should test system scaling before expanding beyond one node; for systems of 10 to 20 katoms, poor scaling has been observed beyond 8 ppn, while the 92 katom ApoA1 benchmark case scales well to 2 nodes (and possibly beyond).
| Anchor | ||||
|---|---|---|---|---|
|
...