Refactor StaticParameters for all platforms.

The calibration module is not installed with qibolab. It is most likely missing a __init__.py inside the calibration folder.

We should increase coverage, add tests and regression tests before making this repository public.

During these last days, I did with JI some performance benchmarks for a couple of single qubit circuits. Let's consider the following procedure:

from qibo import gates, models
c = models.Circuit(1)
c.add(gates.H(0))
c.add(gates.RX(0, theta=0.2))
c.add(gates.X(0))
c.add(gates.M(0))
result = c(nshots=1024)

This code takes 5.9s to execute in qpu1q which I believe everybody agrees it is too long for 3 gates and 1024 shots (naively ~2 milliseconds/shot without including slurm communication).

In order to identify potential bottlenecks, I've executed the previous code with cProfile (python -m cProfile script.py) and I've obtained the timings below, which after a very superficial look, seems to show that we are, obviously, spending >50% of the time in qblox and pulsar calls among others. I believe it is time to check carefully and identify all places where we might have performance deterioration and elaborate a technical justification or, if possible, propose a fix.

@stavros11 @aorgazf @DavidSarlle could you please try to reproduce my results?

[Qibo 0.1.8rc0|INFO|2022-08-31 11:12:19]: Loading platform tii1q from runcard /nfs/users/stefano.carrazza/qibolab/src/qibolab/runcards/tii1q.yml
[Qibo 0.1.8rc0|INFO|2022-08-31 11:12:22]: Using qibolab (tii1q) backend on /CPU:0
[Qibo 0.1.8rc0|INFO|2022-08-31 11:12:22]: Connecting to tii1q instrument cluster.
[Qibo 0.1.8rc0|INFO|2022-08-31 11:12:23]: Connecting to tii1q instrument qrm_rf.
[Qibo 0.1.8rc0|INFO|2022-08-31 11:12:23]: Connecting to tii1q instrument qcm_rf.
         6099691 function calls (6018584 primitive calls) in 5.925 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      260    0.005    0.000   17.509    0.067 __init__.py:1(<module>)
        2    0.000    0.000    5.929    2.964 test.py:1(<module>)
   2958/1    0.019    0.000    5.929    5.929 {built-in method builtins.exec}
        1    0.000    0.000    5.549    5.549 circuit.py:911(__call__)
        1    0.000    0.000    5.549    5.549 circuit.py:894(execute)
        1    0.000    0.000    3.038    3.038 backends.py:21(execute_circuit)
   2920/8    0.011    0.000    2.646    0.331 <frozen importlib._bootstrap>:1002(_find_and_load)
   2879/6    0.008    0.000    2.645    0.441 <frozen importlib._bootstrap>:967(_find_and_load_unlocked)
   2650/9    0.009    0.000    2.641    0.293 <frozen importlib._bootstrap>:659(_load_unlocked)
   2425/9    0.005    0.000    2.641    0.293 <frozen importlib._bootstrap_external>:844(exec_module)
   3395/9    0.002    0.000    2.641    0.293 <frozen importlib._bootstrap>:220(_call_with_frames_removed)
        1    0.000    0.000    2.511    2.511 __init__.py:50(__new__)
        1    0.000    0.000    2.510    2.510 __init__.py:9(construct_backend)
        1    0.000    0.000    2.508    2.508 backends.py:8(__init__)
        1    0.000    0.000    2.508    2.508 platform.py:4(Platform)
        1    0.000    0.000    2.491    2.491 abstract.py:19(__init__)
     66/3    0.000    0.000    2.245    0.748 __init__.py:109(import_module)
     68/3    0.000    0.000    2.245    0.748 <frozen importlib._bootstrap>:1018(_gcd_import)
        1    0.000    0.000    2.243    2.243 qblox.py:2(<module>)
        2    0.000    0.000    2.127    1.064 pulsar.py:10(<module>)
        1    0.000    0.000    2.085    2.085 abstract.py:84(connect)
   914/65    0.002    0.000    2.045    0.031 {built-in method builtins.__import__}
      299    0.004    0.000    1.952    0.007 cluster.py:47(decorator_wrapper)
 2558/910    0.003    0.000    1.747    0.002 <frozen importlib._bootstrap>:1033(_handle_fromlist)
      320    0.003    0.000    1.684    0.005 ieee488_2.py:81(_read)
      320    0.013    0.000    1.667    0.005 ip_transport.py:244(readline)
      306    0.004    0.000    1.655    0.005 cluster.py:4922(_check_error_queue)
        1    0.000    0.000    1.621    1.621 qblox.py:14(connect)
      320    0.010    0.000    1.608    0.005 {method 'readline' of '_io.TextIOWrapper' objects}
        1    0.000    0.000    1.603    1.603 station.py:1(<module>)
      328    0.003    0.000    1.592    0.005 socket.py:690(readinto)
      328    1.588    0.005    1.588    0.005 {method 'recv_into' of '_socket.socket' objects}
       11    0.000    0.000    1.587    0.144 base.py:1(<module>)
        1    0.000    0.000    1.559    1.559 parameter.py:1(<module>)
        1    0.000    0.000    1.554    1.554 data_array.py:1(<module>)

@sorewachigauyo could you please confirm that there is no sensitive information in this code, that cannot be shared publicly.
For example, there are some IP addresses, which most likely are local net values, which are fine to keep.

Following our discussion today, we would like to start the integration of our pulse library with the platform.

Here some minimal example on how the API should look like:

from qibolab.platforms import TIIq
from qibolab import pulses

# standardize input format                                                                           
pseq = pulses.PulseSequence()
pseq.add(pulses.Pulse(1e-5, 10, ...))
pseq.add(pulses.Pulse(..,..,.))

# standardize output format                                                                          
exp = TIIq()
result = exp.execute(pseq)

The platform class should take care of the translation between the PulseSequence and its specific instrumentation.

@scarrazza @stavros11 @aorgazf I have found a small bug. It is raised when a sequence of gates starts with the Identity gate.
As it is implemented in qibo the metjod to_sequence od the Identity gate produces an illegal state on the sequencer when it is the firts gate to be executed in a sequence (not when it is in the middle, because the sequencer has been inicialized with a valid pulseSequence in a previous stage of the sequence).

This error is not raised when you translate the "I" gate as it is done in the PR #107 with pulses, creating a pulse with 0 amplitude for the "I" gate.

Can you review the gate translation in Qibo?

@sorewachigauyo and icarusq team, could you please move the inst content to the instruments folder?

This issue will cover an in-depth explanation of Qililab, comparing it to the Qibolab library, looking at their similarities and differences, and discussing possible advantages/disadvantages of both implementations.

Class comparison

Backend

This class is used by Qibo to know which gate and circuit to instantiate when building a Circuit.

In Qililab we no longer use this class: given that the class Experiment is the one in charge of executing Circuit classes, we can safely remove this dependence from Qibo. Consequently, we don't need to call qibo.set_backend() anymore.

Platform

In both Qililab and Qibolab libraries the goal of the class Platform is to represent the structure of the chip being used and of all the instruments connected to it. However, we moved all the non-descriptive methods (connect(), setup(), execute()...) to the new class Experiment. Please find below the class diagrams for the Platform and Experiment. The code may slightly differ from the class diagrams because it is still a work in progress.

Platform

As you may have seen in the diagram, we introduce the idea of Bus, which is a representation of a line in the lab: it contains a SystemControl class (a class describing the instrument/s needed to control and readout the qubit) and a Qubit / Resonator class (objects describing the qubit/resonator that the line is connected to).

The ChipPlaceHolder class is not yet implemented. Ideally this class should describe all the information of the chip and how it is connected to the instruments (to which bus is each element connected).

Note: Whenever we need to use a group of classes (such as a list of Bus objects) we represent it as a new class (Buses). This gives us more freedom to control them.

Experiment

Note: In the following class diagram Experiment is referenced as CalibrationTest.

The important ideas to take from this class diagram are the following:

• The Experiment class' constructor takes 3 arguments: a list of Circuit or PulseSequence classes, a platform name and (optionally) experiment settings.
• The platform name is used to build the Platform object.
• The Platform, PulseSequence and ExperimentSettings are used to build the Execution class. This class contains a list of BusExecution classes, which contain all the pulses that will run for a specific bus.
• Running the execution returns a class containing the results (similar to the HardwareState class of Qibolab).

Some advantages of using this Platform + Experiment representation:

• The Platform class is platform agnostic: there is no need to modify the source code and add a new platform class every time we want to add a new platform (using a new lab, changing instruments...). We just need to modify the YAML file containing the description of the Platform, and all the needed classes will instantiate automatically.
• Given that a BusExecution class is instantiated if and only if there is a PulseSequence on that specific bus, the 'Experiment' class only connects to the instruments needed for the execution. This will become relevant when running sequences on multiple qubit chips, given that a customer might want to run, for example, a 3-qubit sequence on a 5-qubit chip.
• Multiple circuits can be executed without having to connect and disconnect every time.
• Given that the 'Experiment' class knows what platform is being used, it can execute a sequence of pulses while changing any parameter/s of the platform, which is very useful for characterization and tuning of the qubit. One clear example is tuning the RX and RY gates by running an AllXY experiment while changing the gain of the QCM:

Instruments

The classes used to control the Qblox and Rohde&Schwarz instruments are, of course, very similar. We however introduced several layers of abstraction, which simplifies a lot the task of adding new instruments. Another advantage of using abstract classes is that we can connect Qililab with our FluxQubitSimulator very easily, by just adding a SimulatedSystemControl class (which is agnostic to the simulated qubit and thus it only needs to be added once) and adding a new YAML defining the simulated platform.

I don't think adding the simulator in Qibolab is very straightforward, because the AbstractPlatform class is not instrument agnostic:

• It has a hard coded local oscillator, which is not needed when using an integrated system control or a simulator.
• It has a hard coded QRM and QCM, which is not needed when using a simulator.
• In the execute_pulse_sequence method of the MultiqubitPlatform class you use instrument-specific methods such as upload(), which I believe is only used with Qblox instruments.

Gates

Qibolab defines gate classes that inherit from qibo.gates, and uses the method to_u3_params to translate each gate into a pulse. Qililab uses a class CircuitToPulses that is responsible of translating a Qibo Circuit class into a PulseSequence.

Qilimanjaro Code Guidelines

Leaving the code functionality aside, in Qilimanjaro we are putting a lot of effort in writing clear, understandable and maintainable code. For this reason, we constituted the Qilimanjaro Code Guidelines, and we make use of the pre-commit framework to make sure that Qililab follows them thoroughly.

These are some of our code guidelines:

1. OOP: Use an Object Oriented Programming approach to develop code as DRY as possible.
2. Code readability and maintainability:
   • A class has one single responsibility.
   • Use a file per class.
   • A function cannot have more than three parameters.
   • Use of dataclasses.
   • Use keyword arguments when calling functions func(a=a, b=b).
3. Typing: All functions are typed for the input parameters and the returning output statement.
4. Testing: Use of unit, integration and end-to-end tests that cover more than 80% of the code.
5. Documentation: We document our functions following Google style docstrings.
6. We follow the S.O.L.I.D. principles.
7. We avoid as much code smells as possible.
8. We make use of design patterns as much as possible.

On result return from scheduler, check type of result to see how to input into MeasurementRegister (e.g. for single-shot, use number of occurrences, else call with probabilities), refs. #14.

In 410ba9b, qblox_instruments was added to being imported at the top of the qblox driver. Currently, qblox_instruments is not a part of the core qibolab dependencies. So, this causes an import error on an installation without the tiiq flag as the instrument library will attempt to import all the instrument drivers.

  File "c:\qibolab\src\qibolab\instruments\__init__.py", line 1, in <module>
    from qibolab.instruments.qblox import ClusterQRM_RF, ClusterQCM_RF      
  File "c:\qibolab\src\qibolab\instruments\qblox.py", line 5, in <module>   
    from qblox_instruments import Cluster
ModuleNotFoundError: No module named 'qblox_instruments'

Add an installation note concerning the issues with python3.8 and anaconda for the tiiq setup.
@andrea-pasquale could you please add the warning note.

The minimal example from README

from qibolab import Platform
from qibolab.pulses import Pulse, ReadoutPulse, PulseSequence, Rectangular, Gaussian

# Define PulseSequence
sequence = PulseSequence()

# Add some pulses to the pulse sequence
sequence.add(Pulse(start=0,
                   frequency=200000000.0,
                   amplitude=0.3,
                   duration=60,
                   phase=0,
                   shape="Rectangular",
                   channel=0))

sequence.add(ReadoutPulse(start=70,
                          frequency=20000000.0,
                          amplitude=0.5,
                          duration=3000,
                          phase=0,
                          shape="Rectangular",
                          channel=0))

# Define platform and load specific runcard
platform = Platform("tiiq")
# Connects to lab instruments using the details specified in the calibration settings.
platform.connect()
# Configures instruments using the loaded calibration settings.
platform.setup()
# Turns on the local oscillators
platform.start()
# Executes a pulse sequence.
results = platform(sequence, nshots=10)
# Turn off lab instruments
platform.stop()
# Disconnect from the instruments
platform.disconnect()

fails using the latest main and the qw5q runcard:

[Qibo 0.1.8.dev1|INFO|2022-07-06 15:07:10]: Loading platform tiiq from runcard /nfs/users/stavros.efthymiou/qibolab/src/qibolab/runcards/qw5q.yml
Traceback (most recent call last):
  File "minimal_example.py", line 25, in <module>
    platform = Platform("tiiq")
  File "/nfs/users/stavros.efthymiou/qibolab/src/qibolab/platform.py", line 22, in Platform
    return Device(name, runcard)
  File "/nfs/users/stavros.efthymiou/qibolab/src/qibolab/platforms/abstract.py", line 33, in __init__
    InstrumentClass = getattr(import_module(f"qibolab.instruments.{lib}"), i_class)
AttributeError: module 'qibolab.instruments.qblox' has no attribute 'ClusterQRM_RF'

The existing runcards also don't work with the current configuration.

Currently, the readout is hardcoded for two-qubit joint readout with tomography

Changes to be done

• Hardware Circuit

  • Remove readout data processing
  • Add scheduler check to see if tomography is required (call with number of qubits measured)
  • Handle new scheduler return result {"states": {"00": n or p, ...}, "raw_signal": [[y1, y2, ... ,], ] (optional), "density_matrix": [] (optional, if tomography has to be performed)}
  • On result return from scheduler, check type of result to see how to input into MeasurementRegister (e.g. for single-shot, use number of occurrences, else call with probabilities)
  • Change execute call to remove measurement_level (this will be moved to experiment as a configuration)

@scarrazza On the subject of removing measurement_level for compatiability with qibo.model.circuits, I think that there should be a method for tomography to be performed on the circuit regardless of system requirement, though as we've discussed yesterday, this should not be put as a part of circuit.execute.
E.g. with single-shot readout, we do not need to perform tomography to obtain the correlated states, but we might want to do it anyway to get the density matrix.
Maybe we can reuse a density_matrix=False at circuit initialization?

• Experiment

  • Add methods to process data (process_readout_data and process_tomography_data)
  • Add is_tomography_required(nqubits) method
  • Add new flag to static configuration single_shot
  • Refactor StaticParameters

• Scheduler

  • Add scheduler method to check if tomography is required for this experiment (call with number of qubits measured)
  • Add scheduler method to check if experiment uses single-shot measurement
  • Add execute method with tomography flag and readout qubit register that maps the pulse sequence to the right method (single shot/1 qubit to execute_pulse_sequence and tomography to execute_batch_sequence) and maps the data to the right method (single shot/1 qubit to process_readout_data and tomography to process_tomography_data)

In https://github.com/qiboteam/qibolab/blob/main/src/qibolab/circuit.py#L57, the phase of the measurement pulse uses the phase of single qubit control sequence. I'm not sure if this is intended behaviour.

Some mixer calibration steps adjust and fix the phase to promote the intended sideband, so maybe we can use the phase from the runcard instead.

We have to update the backend selection mechanism in qibo given that

• simulators may have multiple engines, e.g. cupy vs cuquantum relying on a specific backend
• qibolab must support multiple hardware platform

So far we can control the default behaviour of qibo using the profile.yaml, most likely we need a similar mechanism in qibolab.
However, from the user's point of view, we should provide a simple way to specify backends and engines/platforms.
Following @stavros11 suggestion, let me suggest a specific layout:

import qibo
qibo.set_backend('qibojit', engine='cupy') # or engine='cuquantum'
qibo.set_backend('qibolab', platform='tiiq') # or platform='qili'

@andrea-pasquale @stavros11 @mlazzarin what do you think?

This issue is meant as an open forum where we can discuss the best way to interface logical gates to the hardware backends.

As I see it there are two main avenues:

• Each backend defines a custom pulse sequence for all available logical gates suited to their device. The circuit will read from the specific backend and create the pulses from there.
• Each backend defines one general U3 gate-to-pulse sequence. Qibo will translate the circuit to U3 (maybe include U1, U2) and then the specific pulse conversion will be made.

The second one is similar to the the Qasm language purpose, while the first one requires a lot more hardware backend specific code. Maybe a middle path is possible?

Different single qubit pulse decompositions ( RX RY RZ / RZ RX RZ RX RZ / etc ) might have different requirements that we might need to take into account from the backend perspective.

Implement a simple flask webapp which generates a yaml/json file with the required configuration for the agnostic platform loading approach #26.

While writing some basic tests for the code I noticed the following: The circuit.execute method takes a measurement_level argument that controls the form of the outcome. Particularly:

• measurement_level = 0 returns the raw data as they are returned from the scheduler after execution,
• measurement_level = 1 does some kind of post-processing using circuit._parse_result,
• measurement_level = 2 returns a MeasurementResult object that contains shots, similarly to when doing classical simulation with measurement gates and nshots.

All measurement levels start from the raw data and perform some kind of post-processing on it. The suggestion is to remove this functionality from the circuit and create a separate Output object to handle it. The circuit will always return this object which contains the raw data only and the user can then query this using different methods to obtain the level 1 or 2 results. This is more inline with simulation circuits that always return a state object containing the state and the user can get measurements using result.samples(), etc..

In addition, this way we can remove the measurement_level argument from circuit.execute, which creates a disagreement with the qibo simulator versions.

In order to execute the calibration procedure using the cluster we need a to disable plotting otherwise the program will crash with:

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb.

0.0.1.dev4
Connected to: Rohde&Schwarz SGS100A (serial:1416.0505k02/113301, firmware:4.2.76.0-4.30.046.295) in 0.08s
Connected to: Rohde&Schwarz SGS100A (serial:1416.0505k02/113300, firmware:4.2.76.0-4.30.046.295) in 0.08s
Traceback (most recent call last):
  File "/nfs/users/stefano.carrazza/qibolab/src/qibolab/calibration/calibration_script.py", line 13, in <module>
    p.run_calibration()
  File "/nfs/users/stefano.carrazza/qibolab/src/qibolab/platforms/qbloxplatform.py", line 67, in run_calibration
    ac = calibration.Calibration(self)
  File "/nfs/users/stefano.carrazza/qibolab/src/qibolab/calibration/calibration.py", line 31, in __init__
    self.mc, self.pl, self.ins = utils.create_measurement_control('Calibration', True)
  File "/nfs/users/stefano.carrazza/qibolab/src/qibolab/calibration/utils.py", line 133, in create_measurement_control
    plotmon = PlotMonitor_pyqt(f'Plot Monitor {name}')
  File "/opt/anaconda3/lib/python3.9/site-packages/quantify_core/visualization/pyqt_plotmon.py", line 44, in __init__
    self._remote_quantify = self.proc._import("quantify_core", timeout=timeout)
  File "/opt/anaconda3/lib/python3.9/site-packages/pyqtgraph/multiprocess/remoteproxy.py", line 548, in _import
    return self.send(request='import', callSync='sync', opts=dict(module=mod), **kwds)
  File "/opt/anaconda3/lib/python3.9/site-packages/pyqtgraph/multiprocess/remoteproxy.py", line 487, in send
    return req.result()
  File "/opt/anaconda3/lib/python3.9/site-packages/pyqtgraph/multiprocess/remoteproxy.py", line 661, in result
    raise ClosedError()
pyqtgraph.multiprocess.remoteproxy.ClosedError

Hi,
I believe you are aware of the issue and I'm not sure if you have already a solution.
When executing import qibo on qpu5q slurm queue

I get the following error:
Traceback (most recent call last): File "/nfs/users/alvaro.orgaz/qibolab/examples/tii/minimum_working_example.py", line 1, in <module> import qibo File "/home/users/alvaro.orgaz/.conda/envs/qibolab/lib/python3.10/site-packages/qibo/__init__.py", line 4, in <module> from qibo.backends import set_backend, get_backend File "/home/users/alvaro.orgaz/.conda/envs/qibolab/lib/python3.10/site-packages/qibo/backends/__init__.py", line 180, in <module> K = Backend() File "/home/users/alvaro.orgaz/.conda/envs/qibolab/lib/python3.10/site-packages/qibo/backends/__init__.py", line 63, in __init__ self.active_backend = self.construct_backend(default_backend) File "/home/users/alvaro.orgaz/.conda/envs/qibolab/lib/python3.10/site-packages/qibo/backends/__init__.py", line 117, in construct_backend backend_instance = self._get_backend_class(backend)() File "/nfs/users/alvaro.orgaz/qibolab/src/qibolab/backend.py", line 17, in __init__ self.set_platform(os.environ.get("QIBOLAB_PLATFORM", "tiiq")) File "/nfs/users/alvaro.orgaz/qibolab/src/qibolab/backend.py", line 20, in set_platform self.platform = Platform(platform) File "/nfs/users/alvaro.orgaz/qibolab/src/qibolab/platform.py", line 16, in Platform from qibolab.platforms.multiqubit import MultiqubitPlatform as Device File "/nfs/users/alvaro.orgaz/qibolab/src/qibolab/platforms/multiqubit.py", line 2, in <module> from qibolab.platforms.abstract import AbstractPlatform File "/nfs/users/alvaro.orgaz/qibolab/src/qibolab/platforms/abstract.py", line 4, in <module> from qibo.core import circuit File "/home/users/alvaro.orgaz/.conda/envs/qibolab/lib/python3.10/site-packages/qibo/core/circuit.py", line 4, in <module> from qibo import K ImportError: cannot import name 'K' from partially initialized module 'qibo' (most likely due to a circular import) (/home/users/alvaro.orgaz/.conda/envs/qibolab/lib/python3.10/site-packages/qibo/__init__.py)

In https://github.com/qiboteam/qibolab/blob/main/src/qibolab/backend.py#L16, the platform is initialized with the backend. An incoming change in #79 (comment) is to connect the instruments with Platform.init.

This becomes a problem with initialization via qibo as https://github.com/qiboteam/qibo/blob/master/src/qibo/backends/__init__.py#L203 reinitializes the platform and reconnects to the instrument. Since there was no instrument closure, this can lead to instrument connection issues.

import qibo
qibo.set_backend("qibolab", "icarusq")

Logger

[Qibo 0.1.7|INFO|2022-02-21 13:17:42]: Using tensorflow backend on /device:GPU:0
[Qibo 0.1.7|WARNING|2022-02-21 13:17:42]: qibotf library was not found. `tf.einsum` will be used to apply gates. In order to install Qibo's high performance custom operators for TensorFlow please use `pip install qibotf`. Alternatively, consider installing the qibojit backend.
[Qibo 0.1.7|INFO|2022-02-21 13:17:42]: Loading platform icarusq
[Qibo 0.1.7|INFO|2022-02-21 13:17:42]: Loading runcard c:\users\atomicguest\documents\github\qibolab\src\qibolab\runcards\icarusq.yml
[Qibo 0.1.7|INFO|2022-02-21 13:17:42]: Connecting to icarusq instruments.
[Qibo 0.1.7|INFO|2022-02-21 13:17:45]: Loading platform icarusq
[Qibo 0.1.7|INFO|2022-02-21 13:17:45]: Loading runcard c:\users\atomicguest\documents\github\qibolab\src\qibolab\runcards\icarusq.yml
[Qibo 0.1.7|INFO|2022-02-21 13:17:45]: Connecting to icarusq instruments.
[Qibo 0.1.7|ERROR|2022-02-21 13:17:45]: Cannot establish connection to icarusq instruments. Error captured: ''Another instrument has the name: Alazar1''

Add scheduler method to check if experiment uses single-shot measurement, refs. #14.

Hi,

The platform has some attributes like platform.ro_port[qubit].lo_freq which don't change the frequency. It got us confuse to why it was not working. We had to use platform.ro_port[qubit].lo_frequency .
I don't know what platform.ro_port[qubit].lo_freq is being used for but maybe it could become private (platform.ro_port[qubit]._lo_freq`.

@aorgazf

I can communicate directly with AD9959 using the cypress microcontroller(CY7C68013), however programming individual registers on the USB is still an issue.

This is essential for 2 reasons:

• Use the memory associated with the microcontroller to store waves as lists, so that faster output from the waves can be generated, which is independent of the main computer.
• Use an external source for modulation, with the PC mode turned on. This allows amplitude/phase/frequency modulation using an external source, while the original signal is modifiable using the PC.

The reason I know that it is possible to program this is that I can do the same thing using the .exe application provided by Analog Devices.

There is no separate datasheet from the Analog Devices that elaborates on the interface between the USB I/O and AD9959 chip.

The datasheets that I am referring to are located here. Cypress, AD9959

I have tried the following things:

• Using the similar method that is being used for writing into the AD9959 chip. Not able to read/write on USB. Also, the register addresses are of 4 hexadecimal digits for USB whereas for AD9959 it is with 2 hexadecimal digits.
• Directly write it on the mentioned register using the to_ctrl command.

Is there any method apart from using a C wrapper for python? Any additional references explaining the same will also be helpful as I am not able to find resources on communicating on Cypress microcontroller using python.

Thanks

Some Qibo modules require to call the platform from qibolab, e.g. qcvv or qibo-simulation.
We should keep open the possibility to introduce a platform "emulator" (realistic or not) in qibolab.

Based on the user's requested number of qubits and connections, we need to select the appropriate qubits for the quantum circuit.

We may also need to entangle distant qubits (more than 1 edge away) based on the user's requirements.

This is the current layout for the 10 qubit chip.

import networkx as nx
import matplotlib.pyplot as plt

G = nx.Graph()
edges = [(1, 2), (1, 4), (1, 3), (1, 8), (1, 10), (2, 4), (2, 3), (2, 5), (2, 6), (3, 4), (3, 9), (3, 10), (4, 6), (4, 7), (5, 6), (6, 7), (8, 10), (9, 10)]
G.add_edges_from(edges)

nx.draw(G, with_labels=True, font_weight='bold')
plt.show()

I think we should consider the implementation of a pulse simulator for IcarusQ.

We have deployed qibolab 0.0.1.dev4 in the cluster, however we are noticing the following error:

PermissionError: [Errno 13] Permission denied: '/opt/anaconda3/lib/python3.9/site-packages/qibolab/instruments/data

because this data folder is created and populated at runtime.

In order to solve this issue we should store runtime data in user's workspace, e.g. in a ~/.qibolab folder.
We have already implemented something similar for qiboclient in here.

@aorgazf @DavidSarlle could you please let us know if moving this folder outside the package data is safe and possible?
(I remember that in previous versions this folder was created in user's workspace but please confirm)

Add handling single_shot measurements, refs. #14.

I'm currently working on the qcvv project as mentioned in #119.
I would like to include the latest calibration procedures.
Where can I find them in this repository, @maxhant @DavidSarlle @aorgazf?

Hi Team,

I am unable to activate myself as a user on Codecov. Upon linking my git hub account, I receive this error message.

Related issue #63. When we execute a pulse sequence or a circuit we obtain a readout dictionary that looks like

{0: {"ReadoutPulse(142, 2000, 0.900, 20000000, 3.142, 'Rectangular()', 10, 'ro')": (0.0017713258742787735, 1.9431535617144184, -0.0006444298566706158, 0.0016499410634083118)}}

A theory user would probably like to extract some of the following:

1. Raw measurement shots as bitstrings,
2. Measurement frequency from each bitstring (can be calculated from 1),
3. Probabilities for each bitstring (can be calculated naively from 2, unless there is a more sophisticated procedure that uses the readout voltages directly).

The number of shots that are returned should be what the user specifies as nshots when executing the circuit. Eg. if the user asks for 1000 shots he should get back 1000 bitstrings, not a single average voltage.

@DavidSarlle is this implemented in any branch of the code?

If we execute:

from qibolab import Platform
p = Platform("tiiq")

the code crashes with:

ImportError: cannot import name 'QBloxPlatform' from partially initialized module 'qibolab.platforms.qbloxplatform' (most likely due to a circular import) (/opt/anaconda3/lib/python3.9/site-packages/qibolab/platforms/qbloxplatform.py)

While if we try:

from qibolab import Platform
from qibolab.pulses import Pulse, ReadoutPulse
from qibolab.circuit import PulseSequence
from qibolab.pulse_shapes import Rectangular, Gaussian

p = Platform("tiiq")

This issue disappears.