Error when using custom target_device

[bachase]

Describe the bug
When attempting to specify an edge-list as the target_device argument to compile, the code errors with

TranspilerError: 'A target must be specified or a coupling map and properties must be provided'

To Reproduce
Run the following code

import cirq
from ucc import compile

qubits = cirq.LineQubit.range(3)
cirq_circuit = cirq.Circuit(
    cirq.H(qubits[0]),
    cirq.CNOT(qubits[0], qubits[1]),
    cirq.CNOT(qubits[0], qubits[2]) # <- 0 <> 2 not natively supported by topology
)
cirq_compiled_circuit = compile(cirq_circuit, target_device=[[0,1], [1,2]])

Expected behavior
I would expect the above code to run without error.

Additional context
This appears to be a consequence of #256, which removed a custom version of the qiskit VF2PostLayout class. In the custom version, the pass was changed to allow only specifying a coupling map without properties, as the optimization was using the number of multi-qubit gates in the optimization cost function. However, the qiskit versions uses gate error rates as part of cost function, so if a coupling map is provided, it also needs error properties specified.

We could consider restoring the custom version, but that would lose any benefits of continued improvements in the qiskit version. qiskit also looks to be deprecating the coupling map + properties in favor of Target.

As it stands, the interface to ucc.compile mixes these, taking in a target_device but only extracting its coupling map. Although this was intentional given the custom passes, that does break the user experience I would expect if I were to supply a full target_device.

The simplest fix for now is to only allow a target_device and pass that through to UCCDefault1.

[jordandsullivan]

Yeah I think only allowing a target_device for now is fine. In the longer term, we do want to collaborate with the broader quantum OS ecosystem in defining how devices pass their properties (and which ones to pass).

[Misty-W]

I didn't realize the VF2 custom passes were removed in #256- they shouldn't have been.

[bachase]

I didn't realize the VF2 custom passes were removed in #256- they shouldn't have been.

Can you share more on the motivation to add back? Is there a measured benefit we can point to relative to the latest qiskit versions? Or perhaps better posed -- is there a benchmark we should include that demonstrates the impact of the customizations?

[bachase]

@Misty-W closing this for now with #290 , but will open a new issue to track adding custom VF2 pass back.