Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Example for hardware job #99

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

BrunoLiegiBastonLiegi
Copy link
Contributor

As per title adds and example for running jobs on etna.

Copy link

codecov bot commented Jan 16, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (bbf8cc8) to head (727715d).

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #99   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            7         7           
  Lines          254       254           
=========================================
  Hits           254       254           
Flag Coverage Δ
unittests 100.00% <ø> (ø)

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.

@scarrazza
Copy link
Member

Thanks, however from this example it is not clear when the user should really define and pass wires, e.g. is this mandatory when verbatim is set to False? What happens otherwise?

@scarrazza
Copy link
Member

Now I am puzzled, why do you need the wire names here? The online system is setting 17 qubits to etna, we can reduce it to 16.

@BrunoLiegiBastonLiegi
Copy link
Contributor Author

I tried running the example both with the wire_names I got from the runcard, and without any wire_names specified, and in both cases the transpiler error is raised:

Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/nfs/users/tiiq/webappdaemon/src/daemon/slurm_circuit_computation.py", line 92, in <module>
    main(args.job_folder)
  File "/nfs/users/tiiq/webappdaemon/src/daemon/slurm_circuit_computation.py", line 66, in main
    c, _ = transpiler(c)
  File "/nfs/tools/qibo/lib/python3.10/site-packages/qibo/transpiler/pipeline.py", line 84, in __call__
    circuit = transpiler_pass(circuit)
  File "/nfs/tools/qibo/lib/python3.10/site-packages/qibo/transpiler/optimizer.py", line 23, in __call__
    raise_error(
  File "/nfs/tools/qibo/lib/python3.10/site-packages/qibo/config.py", line 46, in raise_error
    raise exception(message)
ValueError: The circuit qubits are not in the connectivity graph.

with verbatim=True everything runs fine as long as you only use native gates, otherwise an error is raised.

@scarrazza
Copy link
Member

@alecandido is this expected?

@alecandido
Copy link
Member

alecandido commented Jan 17, 2025

@alecandido is this expected?

At first sight, no. It is definitely unexpected.

There has been a bug related, in which the disconnect qubits were not considered at all. But this has been found early and already solved qiboteam/qibo#1540 (though, as you can see, the reported error was the exact same...).

EDIT: that code has been merged after the latest release, so the bug is only solved in master

@scarrazza
Copy link
Member

Thanks, this should probably be fixed by the next release.

@alecandido
Copy link
Member

@BrunoLiegiBastonLiegi by chance, have you tried with the new Qibo release (or previously with master) to confirm whether the error is still there or not?

@BrunoLiegiBastonLiegi
Copy link
Contributor Author

I think right now there is a problem with an ssl error that marco has to address, I will try again once that's solved.

@BrunoLiegiBastonLiegi
Copy link
Contributor Author

Ok I tried some different configurations with etna/qw11q:

  • running a 16 qubits circuit with a Z gate and two measurements with verbatim=True and without specifying wire_names
    --> this passes in the sense that in the job result page I see everything in order, but I get a json error in the shell
  • running a 16 qubits circuit with a Z and a X gate and two measurements with verbatim=True and without specifying wire_names
    --> this crashes correctly stating that no rule is available for X in the compiler (even though the error message might be more explicit for the end user)
  • running a 16 qubits circuit with a Z and a X gate and two measurements with verbatim=False and both by specifying the wire_names that you can see in the example here (which I copied from the runcard in qibolab_platforms_qrc), and by not specifying any name
    --> this crashes in the second case which is expected (no wires_names), but unexpectedly crashes in the first case as well (with wires_names set), with the following error
Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/nfs/users/tiiq/webappdaemon/src/daemon/slurm_circuit_computation.py", line 92, in <module>
    main(args.job_folder)
  File "/nfs/users/tiiq/webappdaemon/src/daemon/slurm_circuit_computation.py", line 66, in main
    c, _ = transpiler(c)
  File "/nfs/tools/qibo/lib/python3.10/site-packages/qibo/transpiler/pipeline.py", line 87, in __call__
    circuit = transpiler_pass(circuit)
  File "/nfs/tools/qibo/lib/python3.10/site-packages/qibo/transpiler/optimizer.py", line 23, in __call__
    raise_error(
  File "/nfs/tools/qibo/lib/python3.10/site-packages/qibo/config.py", line 46, in raise_error
    raise exception(message)
ValueError: Some wire_names in the circuit are not in the connectivity graph.
  • running a 5 qubits circuit with verbatim=False and specifying the wires_names --> crashes as expected, due to the mismatching number of qubits

@BrunoLiegiBastonLiegi
Copy link
Contributor Author

@alecandido can you double check whether I am doing everything right? Because I am still getting the transpiler error above even when specifying the correct wire_names. The qibo version in use should be the latest 0.2.15.

@alecandido
Copy link
Member

@BrunoLiegiBastonLiegi since the transpiler seems not to be invoked on the client side, are you sure that the qibo version is actually the latest even on the server side? (since it's the one which will actually apply the transpilation, and then generate the error)

Most likely, that's the case. But it's worth checking the simplest issues first, even if unlikely.

@BrunoLiegiBastonLiegi
Copy link
Contributor Author

Ok by running directly on the cluster in my environment with qibo==0.2.15 it seems to work fine. I wonder then what's going on, because the daemon logs 0.2.15 as qibo version. @marcorossi5 @scarrazza can you double check that the daemon is using 0.2.15 indeed?

@alecandido
Copy link
Member

because the daemon logs 0.2.15 as qibo version.

At this point, I wonder whether the version logged is related to the daemon itself, or rather the client that sent the request...

@scarrazza
Copy link
Member

The daemon is using module load qibo, @BrunoLiegiBastonLiegi could you please retry via ssh using this module?

@BrunoLiegiBastonLiegi
Copy link
Contributor Author

Everything seems to be alright even with module load qibo:

andrea.papaluca@saadiyat:~$ module load qibo
(qibo) andrea.papaluca@saadiyat:~$ pip list | grep qibo
qibo                            0.2.15
qibocal                         0.1.1
qibojit                         0.1.7
qibolab                         0.1.10
qibosoq                         0.1.3
(qibo) andrea.papaluca@saadiyat:~$ srun -p qw11q python test.py
srun: job 727812 queued and waiting for resources
srun: job 727812 has been allocated resources
A1: ─H─X─M─
A2: ─────M─
A3: ─────M─
A4: ───────
A5: ───────
A6: ───────
B1: ───────
B2: ───────
B3: ───────
B4: ───────
B5: ───────
D1: ───────
D2: ───────
D3: ───────
D4: ───────
2025-02-03 15:17:29,007 - qm - INFO     - Starting session: b9b5d27f-72e9-4772-92e0-2e20ad8aee2c
A1: ─U3─U3─M─
A2: ───────M─
A3: ───────M─
A4: ─────────
A5: ─────────
A6: ─────────
B1: ─────────
B2: ─────────
B3: ─────────
B4: ─────────
B5: ─────────
D1: ─────────
D2: ─────────
D3: ─────────
D4: ─────────
D5: ─────────
2025-02-03 15:17:32,444 - qm - INFO     - Octave "octave2" Health check passed, current temperature 59
2025-02-03 15:17:33,509 - qm - INFO     - Octave "octave3" Health check passed, current temperature 57
2025-02-03 15:17:34,401 - qm - INFO     - Octave "octave4" Health check passed, current temperature 58
2025-02-03 15:17:35,419 - qm - INFO     - Octave "octave5" Health check passed, current temperature 59
2025-02-03 15:17:36,433 - qm - INFO     - Octave "octave6" Health check passed, current temperature 59
2025-02-03 15:17:36,433 - qm - INFO     - Performing health check
2025-02-03 15:17:36,453 - qm - WARNING  - Health check warning: Inter-OPX connectivity issues in OPX: con1. Missing ports are: 12, 11, 10, 9. See QM-App for more info.
2025-02-03 15:17:36,453 - qm - WARNING  - Health check warning: Inter-OPX connectivity issues in OPX: con2. Missing ports are: 12, 11, 10, 9. See QM-App for more info.
2025-02-03 15:17:36,453 - qm - WARNING  - Health check warning: Inter-OPX connectivity issues in OPX: con3. Missing ports are: 12, 11, 10, 9. See QM-App for more info.
2025-02-03 15:17:36,453 - qm - WARNING  - Health check warning: Inter-OPX connectivity issues in OPX: con4. Missing ports are: 12, 11, 10, 9. See QM-App for more info.
2025-02-03 15:17:36,453 - qm - WARNING  - Health check warning: Inter-OPX connectivity issues in OPX: con5. Missing ports are: 12, 11, 10, 9. See QM-App for more info.
2025-02-03 15:17:36,453 - qm - WARNING  - Health check warning: Inter-OPX connectivity issues in OPX: con6. Missing ports are: 12, 11, 10, 9. See QM-App for more info.
2025-02-03 15:17:36,453 - qm - WARNING  - Health check warning: Inter-OPX connectivity issues in OPX: con7. Missing ports are: 12, 11, 10, 9. See QM-App for more info.
2025-02-03 15:17:36,453 - qm - WARNING  - Health check warning: Inter-OPX connectivity issues in OPX: con8. Missing ports are: 12, 11, 10, 9. See QM-App for more info.
2025-02-03 15:17:36,453 - qm - WARNING  - Health check warning: Inter-OPX connectivity issues in OPX: con9. Missing ports are: 12, 11, 10, 9. See QM-App for more info.
2025-02-03 15:17:36,453 - qm - INFO     - Health check passed
Connected to: Rohde&Schwarz SGS100A (serial:1416.0505k02/114167, firmware:4.2.76.0-4.30.046.295) in 0.21s
Connected to: Rohde&Schwarz SGS100A (serial:1416.0505k02/114164, firmware:4.2.76.0-4.30.046.295) in 0.14s
2025-02-03 15:17:38,749 - qm - INFO     - Sending program to QOP for compilation
2025-02-03 15:17:39,169 - qm - INFO     - Executing program
Counter({'001': 18, '110': 15, '100': 14, '011': 13, '101': 12, '000': 11, '111': 10, '010': 7})

the only thing I wasn't expecting is the decomposition in U3 gates, are we not using the GPI2 anymore?

@alecandido
Copy link
Member

alecandido commented Feb 3, 2025

the only thing I wasn't expecting is the decomposition in U3 gates, are we not using the GPI2 anymore?

I would say yes, by default U3 is not native
https://github.com/qiboteam/qibo/blob/45dee852cf4dc2ea34026c7ae77b440a05edba79/src/qibo/transpiler/unroller.py#L61-L64

Though the default transpiler is actually backend dependent
https://github.com/qiboteam/qibo/blob/45dee852cf4dc2ea34026c7ae77b440a05edba79/src/qibo/backends/__init__.py#L139

And Qibolab 0.1 has still compilation for the U3
https://github.com/qiboteam/qibolab/blob/bfb48cc2d9ec5e563110720889dc74acca6e604c/src/qibolab/backends.py#L68
https://github.com/qiboteam/qibolab/blob/bfb48cc2d9ec5e563110720889dc74acca6e604c/src/qibolab/compilers/compiler.py#L45-L59

So, it's not surprising. But U3 will be simply unrolled on the Qibolab side, completing the transpilation.
With Qibolab 0.2 the compiler has no rule for U3 (since it was essentially unrolling to GPI2), and thus the job will be completely on the Qibo transpiler side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants