Manage projects
Projects are used to control collaborator access to systems and backends that are allocated to a group. Collaborators can only access backends that are added to the projects that they belong to.
You can make changes to and view information about projects, including managing collaborators, managing backends, and accessing job results.
For instructions to control collaborator access in IBM Cloud®, see Plan Qiskit Runtime for an organization.(opens in a new tab)
Create a project
You can create up to 100 projects per group. Because projects are members of groups, you create a project from within a group.
Do not include personal information in hub, group, or project details.
- From the Groups tab, select the group where you want to create a new project. Alternatively, you can create a new group first (see Groups).
- Click Add project +.
- Enter the project details, including the title and description. The name is used to connect to the hub in Qiskit. It is auto-generated, but editable. Click Next.
- Select an available system or simulator and set the priority, maximum circuits, and maximum shots, then click Add +. See Define share and What values should I set for Max circuits and Max shots? for help setting these values. Continue allocating systems and simulators as necessary, then click Next.
- Add Collaborators by entering their email addresses, then click Save and close the window.
The project details page features three tabs: Collaborators, Backends, and Results. For more information on Results, visit the Results page.
Backends
The Backends tab lists all available backends for your project.
Backend details
All backends that are allocated to the project are listed. Click any backend to see detailed information.
Define share
Priority of jobs in the queue is determined globally and is based on the usage of all systems (not on individual backends). Hub and group administrators can adjust the share among groups and projects from the administrator dashboard. See Fair-share queuing and What is a queue slot (share)? for more information.
A queue slot is a share in the computational capability of the fleet of IBM Quantum™ systems. A hub’s reserved capacity entitlement is proportional to the number of queue slots assigned to that hub.
Queue slots inform the fair-share algorithm to schedule submitted jobs according to a prioritization that depends on the queue slots allocated and the usage till that moment during the current rolling time window.
Your queue slot allocation determines your reserved capacity. For example, given that each system with fewer than 200 qubits is worth 20 queue slots, if your hub is allocated five queue slots, then you will be guaranteed capacity equivalent to 25% of the up-time of the average <200-qubit system, if your users maintain a continuous demand.
Note that queue slot consumption changes depending on the number of qubits. Please refer to your contract or your IBM® engagement manager for the exact metrics.
Because the fair-share algorithm balances the recent history of on-chip execution time with the order of job submissions, the length of a queue is not necessarily an indication of how long a job will take to run.
The queueing system first tries to satisfy the hub’s share. It then determines which group, and then which project, will go next. This hierarchical relationship means that while a share may be available to a hub, the queueing behavior is based on the recent activity and usage of other instances (a hub/group/project combination) in the hub.
Example:
User A in one hub, who has not submitted a job for a long time, submits a job to a queue. User B, in a different hub, is constantly submitting jobs to the same queue. Even though User A’s job may have been submitted after User B’s jobs, User A’s job may be interleaved among User B’s jobs already in the queue, or User A’s job may be run before all of User B’s submitted jobs.