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

Transpiler padding #1429

Open
alecandido opened this issue Aug 28, 2024 · 7 comments
Open

Transpiler padding #1429

alecandido opened this issue Aug 28, 2024 · 7 comments

Comments

@alecandido
Copy link
Member

Currently, the transpiler is already providing some padding

def __call__(self, circuit: Circuit) -> Circuit:
physical_qubits = self.connectivity.number_of_nodes()
logical_qubits = circuit.nqubits
if logical_qubits > physical_qubits:
raise_error(
ValueError,
"The number of qubits in the circuit can't be greater "
+ "than the number of physical qubits.",
)
if logical_qubits == physical_qubits:
return circuit
new_circuit = Circuit(physical_qubits)
for gate in circuit.queue:
new_circuit.add(gate)
return new_circuit

but just applying the basic approach, i.e. padding at the end.

However, there is not much more that can be done at the moment, since Qibolab does not support using its own qubits' names in circuits.
qiboteam/qibolab#1009

As soon as that will be available, it would be interesting to offer the option to choose which subset of qubits should be targeted. And applying padding only at the end.

This last part could be done even immediately: sometimes it may be interesting to route a circuit on a subset of the whole qubits and connectivity (even though some subsets will make impossible to execute some circuits), so padding as preprocessing and padding as postprocessing are truly two different features, and only the first is currently available (unless I'm missing something).

@alecandido
Copy link
Member Author

@Simone-Bordoni can you take a look at the description? I'm not asking you to implement anything of what I described. And maybe it's not even urgent to anything at all. But at least I would have a consistent issue for when someone will be able to take over the project.

@csookim
Copy link
Member

csookim commented Aug 28, 2024

Similarly, I'd like to open an issue about the naming of qubits and nodes in the connectivity graph. Would it be better to discuss this here, or should I create a separate issue?

@alecandido
Copy link
Member Author

Similarly, I'd like to open an issue about the naming of qubits and nodes in the connectivity graph. Would it be better to discuss this here, or should I create a separate issue?

The two things are related, and they will be most likely solved together. Feel free to discuss it even here :)
(but if you have a different opinion, do what you consider best)

@csookim
Copy link
Member

csookim commented Aug 29, 2024

Currently, the transpiler is designed to interpret integer connectivity graph nodes i as string physical qubit names "q" + str(i).

:math:`{\\textup{"q0"}: 1, \\textup{"q1"}: 2, \\textup{"q2"}:0}`
to assign the physical qubits :math:`\\{0, 1, 2\\}`
to the logical qubits :math:`[1, 2, 0]`.

For example, consider the connectivity graph:

Screenshot 2024-08-29 at 19 56 06

and the physical-to-logical mapping:

{'q0': 4, 'q1': 0, 'q2': 2, 'q3': 1, 'q4': 3}.

If we want to enable custom string names for qubits, the naming scheme will need to be updated.

Possible options are:

  1. Use the same names for connectivity graph nodes and physical qubits.
  2. Only allow numerical names for hardware qubits.
  3. Continue using the current method when hardware qubit names are numerical; otherwise, use the same names for both nodes and qubits.

@Simone-Bordoni
Copy link
Contributor

At the moment it is possible to select a subset of qubits in the connectivity when defining a transpiling pipeline (PR #1121).
You can't restric the connectivity if using a single transpiler step, however in that case it would be just sufficient to manually remove the nodes from the connectivity graph.
On the other hand, i think it would be important to allow for general names of the names of the graph (not only "qi").
However, i think it is important to have the requirement that the names of the connectivity graph match the names of the hardware qubits in order to avoid confusion.

@alecandido
Copy link
Member Author

However, i think it is important to have the requirement that the names of the connectivity graph match the names of the hardware qubits in order to avoid confusion.

Yes, indeed. That's why I linked immediately qiboteam/qibolab#1009, as a "dependency" of this issue (there are parts of this issue that could be worked on before, but that has to be solved first to complete this).

@csookim
Copy link
Member

csookim commented Aug 30, 2024

Thanks, then I will update the Placer and test files to use the same names for connectivity graph nodes and hardware qubit names (wire_names) in qibo side.

This was referenced Oct 10, 2024
@alecandido alecandido mentioned this issue Oct 24, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants