Frequently asked questions (FAQ)¶

Hubs, groups, and projects are the organization levels for providers. 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 systems at the project and group level.

See this topic for more information: Providers.

Hub administrators can manually reserve time on a particular provider for specific systems from the Systems page. Each collaborator can view upcoming reservations on providers that he or she is a member of on the details page for the relevant system and on their dashboard.

Each hub is allowed a specific amount of time on each system. To determine how much time your hub is allocated, contact IBM Quantum Support. By default, IBM only enables one provider per client to accept reservations. If you need more providers to be able to access reservations, contact IBM Quantum Support (ibmq@us.ibm.com).

See this topic for more information: Reserve system time.

Collaborators can only view reservations on providers that they are members of. Therefore, if they are not added to the provider until shortly before the reservation time starts, they will not see the reservation.

The number of allocated system shares (queue slots) determines a guaranteed minimum percentage of time that you are able to run jobs on that system. For example, if you have 5 system shares on your contracted device and that device has 20 total slots, your hub is guaranteed at least 25% of the run time.

You still have access to non-contracted devices, but your usage percentage is not guaranteed on those devices.

A hub’s entitlement determines its proportional share of a system, which is measured in portions of system shares. System shares implement a fair-share algorithm that helps facilitate job prioritization. For example, if your hub has five system shares on a 20-slot device, your hub is entitled to a minimum of 25% of the run time on that device.

See this topic for more information: Fair-share queuing.

A good practice is to accord the sum of group priorities with the number of system shares. For example, assume that your Hub has five system shares. Then an easy way to track system share access is to make the sum of your group priorities to be equal to 5000. That way, if you want one group to have an effective system share of 2, you will configure the backend priority of this group to be equal to 2000.

See this topic for more information: Fair-share queuing.

No. You must manually set the share for each group and project.

When you are notified that there is a new system 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 system. For each relevant group and project, open the group or project, click the Manage backends tab, choose the new system under Select a backend, then fill out the rest of the values as appropriate.

For full details, see Add or remove backends within groups.

One basic administrator role is to assign shares to groups and projects. These shares are assigned per system. Therefore, group and project administrators are also defined per system. Therefore, one person could be a group administrator on System A and a project administrator on System B.

Hub administrator tasks:

• Assign backends to all groups and projects

• Assign the system share to groups and projects

• Invite and assign hub and group administrators

• Add collaborators (non-administrator end users) to projects

• Manage system reservations

Group administrator tasks:

• Assign backends to projects

• Assign the system share to projects

• Invite group administrators

• Add collaborators to projects

• Manage system reservations

Both hub and group administrators can adjust system share 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.

It is recommended that you use circuit bundling (run several circuits in one job) to minimize the overhead of sending several jobs, which helps reduce queue wait time. The Max Experiments setting specifies how many circuits can be bundled in this manner.

Moreover, to minimize sampling errors of any experiments, your collaborators should maximize the number of shots (repetitions) that their circuit is run.

The default number of shots is 4000. The maximum number of circuits and shots for most systems is 300 circuits and 100,000 shots (under the Open Plan, the maximum is 100 circuits and 20,000 shots). We recommend that hub and group administrators keep the default settings for Max experiments and Max shots. However, there are some instances where you might want to use lower values. For example:

• It could be useful to decrease those values for providers meant to be used by beginners. This will ensure that they have less impact on the allocated Hub usage, allowing more system time for advanced users.

Your API token 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 systems are stable and return accurate results. Calibrations alert IBM to any system 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.

In general, exploratory systems have new experimental features that we believe can improve our quantum systems. Keep in mind that new features can be unreliable, and thus we will only make them more broadly available once they are fully qualified. While we are opting to rapidly give you access to exploratory systems, we still maintain a fleet of systems that have been fully validated, and can be a stable backbone for your science and research. See Exploratory systems for more details.

For more information on the processors in IBM Quantum systems, visit the IBM Quantum processor types topic.

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

1. Give the user access to a Project that only contains simulators. This provides them with the opportunity to familiarize themselves with Qiskit while practicing basic job submission to a system.

2. Next, encourage your user to send practice jobs using 5Q systems available through the Open Plan. This preserves your Hub’s fair-share allocation while giving the user practice with real hardware.

3. Finally, give the user access to a Project in your Hub. This will give them experience sending jobs on larger systems that are only accessible through Projects in your Hub.

HTTPS

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

• IBM Cloud object storage for non-Runtime jobs: https://*.cloud-object-storage.appdomain.cloud

WebSockets

• IBM Quantum APIs: wss://*.quantum-computing.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 backend 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, and ibm_wellington.

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

Yes, failed jobs count against the share allotted to a user for the current month. To see if a job failed, visit the Results tab on your hub’s dashboard. A user can also view a job’s status on their Jobs page.