All allocation requests must justify why the selected resources were chosen and how the requested allocation amounts were estimated. The level of justification is commensurately higher for Research requests. Explaining why you selected resources generally requires a brief statement of how the resource meets your research needs or which aspects of the system are essential to your work. Reasons may include availability of software, need for specialized hardware components, and so on. Resource use should be consistent with the recommended use statements provided for each resource.
Justifying requested allocation amounts requires three elements: A detailed computational plan for using each resource, benchmarks or other sources of the cost of activities planned for each resource, and information about how allocation units for the resource are defined. Guidance for the first two elements is provided in the Research allocation documentation. This page provides guidance for understanding how allocation units are defined and applied.
The term "Service Units" is often treated as synonymous with "core-hours" due to a long history of allocating computing resources that shared this common architectural foundation. However, the origin of the term reflected from the outset that allocation charges may be modified due to various factors. Today's allocated resources encompass a variety of architectures and resource types, many of which are not allocated in core-hours, and the allocations process and documentation are adapting to this reality.
Thus, the phrase "Service Units" should be interpreted in its most broad sense, that is, the units of service for a given resource. The documentation for each resource should be consulted for a precise definition of its allocation and accounting service units, how users should calculate allocation request amounts, and how accounting charges will be calculated.
Here are some common service units and their definitions in use on current allocated resources.
- Core-hours (e.g., Comet — Number of cores used over a given time in hours. This unit is often applied to multi-core systems and, when nodes are dedicated exclusively to user jobs, the charges are often applied as the number of nodes times the number of cores per node times wallclock hours.
- Node-hours (e.g., Stampede2) — Similar to core-hours, but only considers the number of nodes times the wallclock hours. This unit may be used on many-core systems, systems with accelerators, or systems with a variety of node architectures.
- Gigabyte-hours (e.g., Bridges Large) — For data-intensive systems designed to provide large amounts of memory to user jobs, charges may be applied as the amount of memory occupied times the wallclock hours.
- vCPU-hours (e.g., Jetstream — For cloud systems, charges may be applied as the number of virtual CPUs in the requested VM images multiplied by the wallclock time used.
- GPU-hours (e.g. XStream) — the number of GPUs used over a given time in hours. On XSEDE's GPU resources the user has access to one or more CPU cores associated with each GPU, but charges are only applied to the GPU usage.
The XSEDE Resource Overview page provides a brief summary of the resources available for allocation, including relative compute and storage capacities, vendor and architecture, and availability to users.
In preparing an allocation request, users should also refer to the more detailed resource information provided by XSEDE User Portal's Resource Monitor.
On the Resource Monitor, clicking on the resource name in the left column will open a pop-up window. Scroll down in that window will show more fields.
Of particular interest for users preparing allocation requests, scroll down to find the resource description and recommended use, as well as the Startup allocation limit for that resource.
Last update: September 22, 2017