Porting emulator to 0.2

[andrea-pasquale]

This PR attemps to port the emulator in 0.2.
Currently the only model supported is just a qubit without a resonator.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 202 lines in your changes missing coverage. Please review.

Project coverage is 49.51%. Comparing base (d36edc8) to head (a849ef0).
Report is 61 commits behind head on main.

Files with missing lines	Patch %	Lines
src/qibolab/_core/instruments/emulator/emulator.py	0.00%	103 Missing ⚠️
...qibolab/_core/instruments/emulator/hamiltonians.py	0.00%	68 Missing ⚠️
...rc/qibolab/_core/instruments/emulator/operators.py	0.00%	17 Missing ⚠️
src/qibolab/_core/instruments/emulator/utils.py	0.00%	11 Missing ⚠️
src/qibolab/_core/instruments/emulator/__init__.py	0.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1158      +/-   ##
==========================================
- Coverage   52.65%   49.51%   -3.15%     
==========================================
  Files          71       76       +5     
  Lines        3179     3381     +202     
==========================================
  Hits         1674     1674              
- Misses       1505     1707     +202     

Flag	Coverage Δ
unittests	49.51% <0.00%> (-3.15%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[alecandido]

The code is already very clean, but here is a first batch of suggestions extracted while reading it.

They are all minor comments, other than the role of the embedded platform.

[alecandido]

I know that dummy is already an exception (and, possibly, we should also get rid of that one), but the emulator is even different from dummy, since you may want to create multiple platforms, corresponding to different parameters (while dummy was not supposed to be really used outside that single platform - but even that was naive...).

Practically, I'd propose to:

• drop emulator/{platform.py,parameters.json} (at least from inside src/, possibly keeping them in tests/, if relevant)
• scope the emulator/ folder within instruments/, and treat it as a driver on its own
• remove these lines from here, and rely on the default platform loading mechanism

[andrea-pasquale]

I have addressed all points in 513619f.
I wasn't sure where to put an example platform with the emulator, since probably qibolab_platforms_qrc is not the ideal place given that we have only real platforms there. As a temporary solution in qiboteam/qibocal@47f0320 I have added a platforms folder in Qibocal that loads all platforms inside at import time and I have defined there a platform emulator1q. Other proposal are welcome.

[alecandido]

We used to have a /tests/dummy_qrc for testing. We dropped it, since it was mostly outdated with the 0.2 transition (and, since long, we wanted to drop references to QRC from this repo - since it's just a special case).

I have in mind two main options:

• for tests or documentation purposes, you can certainly place a platform in here, either within /tests/ or /doc/ themselves
• for actual platforms, to be properly calibrated, we could actually have a qibolab_platforms_emulators repository

However, even the second option is mainly meant to make some emulator examples, and for common use cases.
Instead, for practical applications, the platform should be placed in the specific project where it is needed. E.g. as an aid (~digital twin) for QRC platforms calibration, it certainly makes sense to store them aside the other platforms they're emulating, i.e. in qibolab_platforms_qrc. While for standalone projects with their own repos, those repos are actual the best location on their own.

[andrea-pasquale]

We used to have a /tests/dummy_qrc for testing. We dropped it, since it was mostly outdated with the 0.2 transition (and, since long, we wanted to drop references to QRC from this repo - since it's just a special case).

I remember that we used to have this folder in 0.1, which was originally where the emulator platforms were stored https://github.com/qiboteam/qibolab/tree/0.1/tests/emulators

This is fine to store example or for testing purposes, however if we want to rely on the default platform loading mechanisms we will then need to copy and paste the platforms either in qibolab_platforms_qrc or to another folder which will then need to add to QIBO_PLATFORMS which could be annoying.

• for actual platforms, to be properly calibrated, we could actually have a qibolab_platforms_emulators repository

Personally I would avoid to add yet another repository. As you said it might be better to add the platforms directly in the project folder. Perhaps it might be useful to have an helper function in Qibolab to ease the addition of new platform folders, which is what I was trying to do directly in Qibocal.

[alecandido]

I went through everything but the EmulatorController. However, as I wrote in a comment, I'm going to propose a separate array-oriented refactor for that. But it's just simpler to propose it as a commit.

[andrea-pasquale]

Thanks for the review @alecandido.
I agree with all the proposed changes, I'm only not sure about removing the assertion.