cunqa.qutils

Holds functions to manage and get infomation about the virtual QPUs displayed by the user.

Connecting to virtual QPUs

The most important function of the submodule, and one of the most important of cunqa is the get_QPUs() function, since it creates the objects that allow sending circuits and receiving the results of the simulations from the virtual QPUs already deployed:

>>> from cunqa import get_QPUs
>>> get_QPUs()
[<cunqa.qpu.QPU object at XXXX>, <cunqa.qpu.QPU object at XXXX>, <cunqa.qpu.QPU object at XXXX>]

The function allows to filter by family name or by choosing the virtual QPUs available at the local node.

When each QPU is instanciated, the corresponding QClient is created. Nevertheless, it is not until the first job is submited that the client actually connects to the correspoding server. Other properties and information gathered in the QPU class are shown on its documentation.

Q-raising and Q-dropping at pyhton

This submodule allows to raise and drop virtual QPUs, with no need to work in the command line. One must provide the neccesary information, analogous to the qraise command:

>>> qraise(n = 4, # MANDATORY, number of QPUs to be raised
>>> ...    t = "2:00:00", # MANDATORY, maximum time until they are automatically dropped
>>> ...    classical_comm = True, # allow classical communications
>>> ...    simulator = "Aer", # choosing Aer simulator
>>> ...    cloud = True, # allowing cloud mode, QPUs can be accessed from any node
>>> ...    family = "my_family_of_QPUs" # assigning a name to the group of QPUs
>>> ...    )
'<job id>'

The function qraise() returns a string specifying the id of the SLURM job that deploys the QPUs.

Once we are finished with our work, we should drop the virtual QPUs in order to release classical resources. Knowing the job id or the family name of the group of virtual QPUs:

>>> qdrop('<job id>')

If no argument is passed to qdrop(), all QPUs deployed by the user are dropped.

Warning

The qraise() function can only be used when the python program is being run at a login node, otherwise an error will be raised. This is because SLURM jobs can only be submmited from login nodes, but not from compute sessions or running jobs.

Note

Even if we did not raise the virtual QPUs by the qraise() function, we can still use qdrop() to cancel them. In the same way, if we raise virtual QPUs by the python function, we can still drop them by terminal commands.

Obtaining information about virtual QPUs

In some cases we might be interested on checking availability of virtual QPUs or getting information about them, but before creating the QPU objects.

To check if certain virtual QPUs are raised, are_QPUs_raised() should be used:
```
>>> are_QPUs_raised(family = 'my_family_of_QPUs')
True
```
In order to know what nodes have available virtual QPUs deployed:
```
>>> nodes_with_QPUs()
['c7-3', 'c7-4']
```

For obtaining information about QPUs in the local node or in other nodes:

>>> info_QPUs(local = True)
[{'QPU':'<id>',
  'node':'<node name>',
  'family':'<family name>',
  'backend':{···}
  }]

Functions

`are_QPUs_raised`	Checks availability of QPUs, filtering by family if desired.
`get_QPUs`	Returns `QPU` objects corresponding to the virtual QPUs raised by the user.
`info_QPUs`	Provides information about the virtual QPUs available either in the local node, an specific node or globally.
`nodes_with_QPUs`	Provides information about the nodes in which virtual QPUs are available.
`qdrop`	Drops the virtual QPU families corresponding to the the input family names.
`qraise`	Raises virtual QPUs and returns the job id associated to its SLURM job.

Exceptions

QRaiseError

Exception for errors during qraise slurm command.