...
Label | Description | ||
|---|---|---|---|
| The project (slurm account) the query is being made for. You can only query projects that yopu are part of. | ||
| Starts the start to end date for the interval the query is running between. | ||
| Defines the number hours across the interval. | ||
If the account is part of an investment: | See Example 1 | ||
| A user can be part of an account that is associated with an investment. Note: An investment can have multiple accounts associated with it. | ||
| The total number of cores across all the investment nodes. | ||
| Total number of days across the month/interval. | ||
| Total CPU hours relating to the investment over the entire month/interval. | ||
| The calculated as the “investment cpus + free amount - current number of CPU hours used” | ||
|
The columns show the “number of jobs” and the “CPU Hour usage” across ALL the accounts that are associated with the investment. | ||
Account Details | |||
<account> |
The columns show the “number of jobs” and the “CPU Hour usage” across the account being queries. | ||
By User | |||
<username> |
Breakdown of the total jobs/CPUs by user. |
Core Hour Usage: Differences to (current) Monthly Reports
For calculating both user and account usage we are exploring an alternative approach to calculating usage compared to that currently implemented within the monthly reports.
Results do not include:
Jobs that were pre-empted.
Jobs that failed due to “Node Failure' - this is typically a hardware fail on the physical compute node - this is different to jobs that failed due to the application itself or experienced an out of memory issues (which is caused by the user not requesting enough memory for the job).
Job counts will typically be less as we do no include jobs that were cancelled while still pending i.e. the job had not been allocated any resources and had not started running.