jvansomeren22 days ago
There used to be a resource in the old OpenQL to prevent this conflict. HvS presented an algorithm in our common meeting that could be used to generate these resource checks. Why is this comment then still here? This suggests that the implementation accepts that it every now and then fails.
Collaborator
Author
@wvlothuizen wvlothuizen 21 days ago
The experimentalists in the lab using OpenQL require full control over pulses (and scheduling), and therefore algorithms automating things aren't easily accepted, especially if they are sensed as a black box. Doing things manually - even if that sometimes results in a compiler error - is perceived as being easier (especially at this stage with 17 qubits only), and it allows exploring new ideas, such as a CZ that not only parks some qubit, but also performs 'refocussing', flux assisted measurement, etc.
Collaborator
@jvansomeren jvansomeren 19 days ago
I appreciate that the experimentalists want to be in full control and need support for that. That is the idea behind making passes visible and all functionality transparent: that 'compiler-intelligence' can always be overridden.
But the code generator passes are kind of inevitable: every compiler for transmon needs to run them.
The experimentalists are not the only ones using transmon and its compiler.
For one, there are the QuantumInspire users that like to use a real machine for some reason.
For them, there should be a more fool-proof but also more open, research-encouraging compiler implementation that doesn't run into errors on some circuits.
Collaborator
Author
@wvlothuizen wvlothuizen 19 days ago
For QI users is may indeed we fruitful to create a separate pass for qubit parking, especially when the number of qubits becomes larger that the current 5 (where conflicts are sort of impossible).
Still I do think it's inevitable that users can construct syntactically sound circuits that still cannot run on some actual hardware, and thus results in an error. The way user/input errors are reported in OpenQL should definitely be improved.
Collaborator
@jvansomeren jvansomeren 1 hour ago
Can you make an issue that a compile setup (with new passes or with existing passes with new options) should be created that is suitable for QI users, i.e. that don't crash on a wrong qubit parking setup?
All circuits that users can write and that cannot be run on some actual hardware must get a decent error message; this requires adding passes that check this and then fail with a clear message.
See discussion below, extracted from https://github.com/QuTech-Delft/OpenQL/pull/433
jvansomeren 22 days ago There used to be a resource in the old OpenQL to prevent this conflict. HvS presented an algorithm in our common meeting that could be used to generate these resource checks. Why is this comment then still here? This suggests that the implementation accepts that it every now and then fails.
Collaborator Author @wvlothuizen wvlothuizen 21 days ago The experimentalists in the lab using OpenQL require full control over pulses (and scheduling), and therefore algorithms automating things aren't easily accepted, especially if they are sensed as a black box. Doing things manually - even if that sometimes results in a compiler error - is perceived as being easier (especially at this stage with 17 qubits only), and it allows exploring new ideas, such as a CZ that not only parks some qubit, but also performs 'refocussing', flux assisted measurement, etc.
Collaborator @jvansomeren jvansomeren 19 days ago I appreciate that the experimentalists want to be in full control and need support for that. That is the idea behind making passes visible and all functionality transparent: that 'compiler-intelligence' can always be overridden. But the code generator passes are kind of inevitable: every compiler for transmon needs to run them. The experimentalists are not the only ones using transmon and its compiler. For one, there are the QuantumInspire users that like to use a real machine for some reason. For them, there should be a more fool-proof but also more open, research-encouraging compiler implementation that doesn't run into errors on some circuits.
Collaborator Author @wvlothuizen wvlothuizen 19 days ago For QI users is may indeed we fruitful to create a separate pass for qubit parking, especially when the number of qubits becomes larger that the current 5 (where conflicts are sort of impossible). Still I do think it's inevitable that users can construct syntactically sound circuits that still cannot run on some actual hardware, and thus results in an error. The way user/input errors are reported in OpenQL should definitely be improved.
Collaborator @jvansomeren jvansomeren 1 hour ago Can you make an issue that a compile setup (with new passes or with existing passes with new options) should be created that is suitable for QI users, i.e. that don't crash on a wrong qubit parking setup? All circuits that users can write and that cannot be run on some actual hardware must get a decent error message; this requires adding passes that check this and then fail with a clear message.