Frequently asked questions (FAQ)

Hubs, groups, and projects are the organization levels for instances. At the lowest level, collaborators are members of projects. Projects are members of groups, and groups are members of hubs. You typically have one hub, which can be divided into any number of groups. Each group can then be divided into any number of projects. Administrators assign access to QPUs at the project and group level.

See this topic for more information: Instances.

Ensure that the time allocated does not exceed the hub's allotted time for groups, as well as the group allocation for projects. Not doing so may cause unexpected distribution of the usage. It is possible to have time unallocated; this time can still be consumed by groups and projects that are not limited.

When you are notified that there is a new QPU available, you must add it first to each group and then to each project that should have access. If you do not complete this step, your hub will not use the QPU. For each relevant group and project, open the group or project, click the Allocated QPUs tab, choose the new QPU under Select a QPU, then fill out the rest of the values as appropriate.

For full details, see Add or remove compute resources within groups.

A device is only available to a project if you have added it first to the project’s group.

Hub administrator tasks:

• Assign QPUs to all groups and projects
• Assign allocation to groups and projects
• Invite and assign hub and group administrators
• Add collaborators (non-administrator end users) to projects

Group administrator tasks:

• Assign QPUs to projects
• Assign allocation to projects
• Invite group administrators
• Add collaborators (non-administrator end users) to projects

Both hub and group administrators can adjust allocation at the project level. There is no precedence between what a hub administrator has set and what a group administrator has set. The most recent change is active regardless of who set it. However, hub administrators can make changes to all groups while group administrators can only make changes for their group.

Your API key is on your IBM Quantum™ dashboard, right at the top for easy access.

Several types of calibration jobs are run both daily and hourly to ensure that the QPUs are stable and return accurate results. Calibrations alert IBM to any QPU failures so that they can be resolved as soon as possible. They also provide users with the most up-to-date error rates and coherence times, allowing them to make better choices when choosing which qubits to use or how to compile their circuits. See more information in the About calibration jobs topic.

To avoid situations in which a new user inadvertently submits many jobs and negatively impacts your Hub’s fair-share priority, we recommend you follow these onboarding steps to train new users.

1. Encourage your user to send practice jobs through the Open Plan. This preserves your Hub’s fair-share allocation while giving the user practice with real hardware.
2. Next, give the user access to a Project in your Hub. This will give them experience sending jobs on larger QPUs that are only accessible through Projects in your Hub.

HTTPS

• IBM Quantum APIs: https://*.quantum-computing.ibm.com and https://*.quantum.ibm.com
• IBM Cloud object storage for jobs: https://*.cloud-object-storage.appdomain.cloud

WebSockets

• IBM Quantum APIs: wss://*.quantum-computing.ibm.com and wss://*.quantum.ibm.com

We have released a new feature that parallelizes some of the classical computation necessary to prepare a submitted job for its quantum computation. Before this feature, all aspects of job processing were executed serially, meaning the target QPU would be held from processing another job until its current job completes. This would be visible in your dashboard as having at most one job in the “Running” state at any one time. With the parallel compilation feature, you may see multiple jobs in the Running state, and which remain in the Running state longer than before. With this change, we also expect to see faster completion times for Qiskit Runtime jobs. Currently, this optimization has been made available on ibmq_manila, ibm_auckland, ibm_bangkok, ibm_cairo, ibm_geneva, ibm_hanoi, ibmq_jakarta, ibm_lagos, ibmq_montreal, ibm_nairobi, ibm_peekskill, ibm_perth, ibmq_toronto, ibm_wellington, ibm_oslo, ibmq_kolkata, and ibmq_mumbai.

It is important to note that a single Qiskit Runtime job does not have exclusive access to a QPU.

Yes, failed jobs count against the reserved capacity usage for the current month. To see if a job failed, visit the Workloads tab on your hub’s dashboard. A user can also view a job’s status on their Workloads page.

See the Fair-share scheduler topic.

Your contracted share will not be guaranteed on a single QPU. The new dashboard should help you track your members’ usage, and optimize compute resources and share balance to hit your targets. Usage is throughout a rolling window, and thus we cannot also guarantee that you can reach your share over a shorter span of time.

For each QPU, jobs that are part of a session take priority. If there are no jobs from an active session, the next job from the regular fair-share queue is run.

A job from the fair-share queue could activate or reactivate a session.