Backends and Batching¶
“Backend” is the term used in Nexus to mean the provider of quantum (or simulation/emulation) compute power.
Backends act as an interface for submitting circuits and provide a way for quantum software to be platform independent: the compilation and execution steps accept an instance of a backend class as an argument. That means that with little alteration, quantum programs can be edited to run against alternative providers, whether simulators, emulators or real quantum hardware.
Represented in Python code, a backend is an instance of a class called
SomethingConfig - for example, QuantinuumConfig - and each provider
class will accept or require different parameters. Also, one backend can
encompass multiple quantum devices. For example, the QuantinuumConfig
backend accepts a device_name parameter which allows the calling code to
choose between the available hardware devices, syntax checkers and emulators.
Job Queues in Nexus¶
Nexus operates a First-In First-Out (FIFO) queue for all compilation jobs, in addition to execution jobs submitted to nexus-hosted emulators and simulators.
Execute jobs submitted to Quantinuum Systems or third-party backends are passed by Nexus to the appropriate queue for that backend as soon as the job is submitted to Nexus.
Supported backends¶
The following backends are supported:
Aer - a Nexus-hosted simulator running Qiskit’s Aer engine (AerState and AerUnitary are also supported).
Braket - hosted on Amazon Web Services (AWS), Braket offers access to multiple quantum computers from IonQ, IQM and Rigetti. Will require you to share your credentials into Nexus.
Quantinuum - access to Quantinuum Systems hardware and emulators. When you use these options through Nexus, your Nexus login is automatically used to interact with Quantinuum Systems, where necessary. Your account may have access to any or all of
H2,H2, syntax checkers, simulators and emulators with advanced noise models.Emulators may be hosted by Nexus or by Quantinuum. In this context, “Hosted by Nexus” means that use will be via your Nexus quota and Nexus’s internal job queue, whereas “Hosted by Quantinuum” means that use will be via your Hardware Quantum Credits (HQC) and subject to the queuing explained in the [Quantinuum Systems documentation](https://docs.quantinuum.com/systems/).
IBMQ - access to hardware hosted by IBM on the IBM Quantum Platform . Will require you to share your credentials into Nexus.
IBMQEmulator - runs circuits on a Nexus-hosted simulator which uses the noise model of a specific IBM quantum device.
ProjectQ - a Nexus-hosted simulator running the ProjectQ engine.
Qulacs - a Nexus-hosted simulator running the Qulacs engine.
Find out more about the backends available through Nexus from the “Backends” link in the main menu.
For full details about backends, refer to pytket documentation section on
backends. Nexus
uses pytket to convert circuits to run on different providers, so Nexus
backends correspond to pytket backends.
Backend Availability¶
Backend availability can be checked on the backends page in the Nexus website. For Quantinuum Systems a calender view (showing machine availability in a calender month) is available on the page for the specific backend. For third-party backends (Braket and IBMQ) Nexus will try and fetch the status of the device from the provider.
Batching behavior¶
Quantinuum backends¶
Please review: Batch Jobs.
IBMQ backends¶
If you submit circuits in one Nexus job then, because Nexus uses
pytket-qiskit
internally, it will attempt to take advantage of IBM’s “batch” execution mode. Your
job’s circuits are first grouped according to n_shots and then the groups
are invoked on IBMQ in batches.
Other backends¶
Automatic batching through Nexus jobs is not currently supported for other backends.
About credentials¶
To use any of the backends other than Quantinuum Systems, you must provide your own credentials from that service.