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: Reservations.

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.

Depending on your hub configuration and its allocated share (queue slots), you can determine how runtime on the systems is allocated across projects and groups by setting backend share. Depending on how share is assigned across groups and projects, every project has a relative share of system time. Relative share is the proportion of hub access that groups or projects have. You can assign a value between 1-10000 as the share of each backend. Hub and Group admins assign share to lower levels in the hierarchy. Equal shares results in equal division of queue slots. Weighted shares can result in more availability to some groups/projects

Setting backend share is how you distribute and allocate queue slots for the hub users.

The number of allocated 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 queue slots 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 queue slots. Queue slots implement a fair-share algorithm that ensures a minimum share of the system is achieved, assuming a sufficient number of jobs are submitted. For example, if your hub has 5 queue slots 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.

Queue slots are allocated to groups and projects by setting shares for each backend. Each backend can be assigned a value between 1-10000. These basic rules apply to queue slot allocation:

• Equal priorities results in equal division of queue slots

• Weighted priorities can result in more availability to some groups/projects

At group and project level, you can think in terms of effective queue slots. For example, assume you have one hub with one backend and one queue slot. There are two groups inside this hub: Group A and Group B.

Case 1: The backend priority is the same for group A and B (100, for example). In that case, group A has an effective queue slot of 0.5 and group B has an effective queue slot of 0.5.

Case 2: Backend priority is 100 for group A and 300 for group B. In that case, Group A has an effective queue slot of 0.25 while Group B has an effective queue slot of 0.75.

The same reasoning can be applied at project level.

A good practice is to accord the sum of group priorities with the number of queue slots. For example, assume that your Hub has five queue slots. Then an easy way to track queue slot 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 queue slots of 2 you will configure the backend priority of this group to be equal to 2000.

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

As IBM Quantum Network members, you will have a contracted amount of access to one system, but you also have access to other systems that are not open to the public. If you want to ensure that a members of a certain project can submit more jobs than others, for example, if you have a project for researchers and a project for beginners, you should set appropriate priority values for all projects and groups.

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 to 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 backend 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 backend share to projects

• Invite group administrators

• Add collaborators to projects

• Manage system reservations

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

For hub and group administrators, it is generally recommended that you keep the default settings for Max Circuits (900) and Max shots (8192). However, there are some instances where you might want to use lower values. For example:

• If the queue is frequently blocked for a long time for some providers, you might want to lower the maximum circuit limit to 400, without changing Max Shots.

• 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 resource, 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.