List support for coupling map in pass manager

[SimonR99]

Summary

Fixes #10920

Details and comments

The preset pass manager previously only allowed the user to provide a coupling map as an object, not as a list. Since the creation of a coupling map is typically a straightforward process, it makes sense to allow users to directly input the list into the preset pass manager generator. This is what this PR is about.

Example :
pm = generate_preset_pass_manager(basis_gates = ['cz', 'sx', 'rz'], coupling_map =[[0,1], [1,2]], optimization_level=3)

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @Qiskit/terra-core

[jakelishman]

Thanks for this! Please could you also add a "feature" release note (reno new --edit preset-passmanager-coupling-map) with a line saying that generate_preset_pass_manager now accepts anything that can be coerced to CouplingMap?

[jakelishman]

we can probably do

Suggested change

	if (
	coupling_map
	and isinstance(coupling_map, list)
	and all(isinstance(sublist, list) for sublist in coupling_map)
	):
	coupling_map = CouplingMap(coupling_map)
	if coupling is not None and not isinstance(coupling_map, CouplingMap):
	coupling_map = CouplingMap(coupling_map)

because the CouplingMap constructor will already have to validate its input, which would just be duplicated and liable to get out-of-sync with this check.

[SimonR99]

Good point, thanks!

[jakelishman]

Minor, but we don't really need to bother with the conversion; we can assertEqual(transpiled_circuit_list, transpiled_circuit_object) and it'll work just as well (and give a better error message on failure).

[SimonR99]

Good, I made the change. I thought it would be good practice since the pass manager doesn't consistently produce the same result. However, this shouldn't be a problem for the test circuit.

[jakelishman]

Oh, the not-the-same output is most likely because we've not set seed_transpiler in the generate_preset_pass_manager - good spot on that. If you set that to the same value, they should always come out the same. The QuantumCircuit equality check actually just delegates to the DAGCircuit one internally, so they're the same, but we have a special hook in QiskitTestCase to make it so that assertEqual draws the circuits in the error message if they both come in as QuantumCircuit.

I think you've ended up with two release notes files here - could you clear out the extra one (-b4f2f0ed...)? Other than that, this is ready to go thanks.

[SimonR99]

Thanks for the guidance and clarification!

[jakelishman]

Thanks for the quick changes! I pushed a little fix up to the release note to add Sphinx cross-references to various objects, and to highlight that the allowed formats are more legacy-related.