Use this form to convert service units (SUs) on one platform to the equivalent amount on another platform using the accepted conversion factors. This calculator uses a weighting factor based on the performance of resources against the HPL benchmark, which is used to determine the Top 500 list of HPC systems.
Rounding of the results to the nearest thousand is acceptable for making Research Allocation requests or transfers. For example, if you convert 10,000 SUs and get 17,921 SUs, it is reasonable to use 18,000 for your request. If your project or group runs benchmarks of its own codes or applications on both resources involved in a requested transfer (e.g., Bridges vs. Stampede2), those benchmarks can be used instead of the default HPL basis to calculate the SUs to transfer. To use your own benchmarks, please include them in your transfer request.
The local Services Unit (SU) for all XSEDE resources can be converted to a common unit - a Normalized Unit (NU). The NU is based on the result of the High Performance LINPACK benchmark run on each system. Below is a conversion calculator that lets you convert SUs from a single XSEDE resource to NUs.
XSEDE Refund Policy (v1.2)
When appropriate, refunds for jobs run on XSEDE that failed due to circumstances beyond your control can be provided. As with any large and complex environment, there are instances where a machine hardware or system software failure may cause a user job to improperly terminate before completion. For this reason, users are expected to checkpoint their jobs on a regular basis. Exceptions are allowed for third-party software packages that do not offer checkpointing - in this case, a full refund will be provided.
The maximum refund amount will be based on 6 hours * (the number of CPUs), based on the assumption that users invoke checkpoint at least every 10 hours. It is recommended that checkpointing be done more frequently if possible. In addition, a request for a refund of service units (SUs) will be considered when any of the following conditions are true, indicating the reason for the job failure was beyond user control:
- Output was lost because of a system crash or hardware failure
- A bug in system software caused incorrect output or job termination
Users should not expect a refund under any of these conditions:
- Fewer than 100 TG SUs were consumed
- The refund request was made more than two weeks after the charge
- No charges were recorded for the job in question (e.g., the system crashed before a job finished and the usage was not recorded in the accounting logs)
- Output was lost because the job did not use the node-local or cluster-local scratch file system
Jobs that abort due to a system crash are typically either not charged or automatically refunded. When automatic refunds are provided, the owner of the job is notified.
How to Request a Refund
Please provide the following information to the XSEDE Help Desk (email@example.com) to request a refund:
- User ID/Login and the system(s) used
- Project account ID
- Name of Project PI
- Reason for the request
- Machine name(s)/sites on which the job was running
- Batch JobID or JobIDs (from PBS, LoadLeveler, LSF, etc.)
- Date the job terminated (optional)
- Date the job started (optional)
The list above is the minimum information required. Additional information may be requested including error messages, a copy of your batch script, etc. In such cases, you will be contacted by a member of the XSEDE staff for the additional information needed to review and address your request.
Notice will be sent via email to user and to the account PI when the refund is made.