Add Target.build_clifford_t

[Cryoris]

Summary

Added Target.build_clifford_t to conveniently build a
Target for Clifford+T transpilation. This target includes
all standard Clifford gates (see get_clifford_gate_names)
T and Tdg.

Closes #15632.

Details and comments

This internally uses Target.from_configuration, and maybe should be called from_clifford_t for consistency.

The initial plan was to build the Target Rust-first and expose the same functionality to C, but the C-exposed Target and the Python one have lots of differences which makes using a single Rust-source complicated. I'll add a second PR to expose this to C too.

For example:

      from qiskit import QuantumCircuit, transpile
      from qiskit.transpiler import Target

      circuit = QuantumCircuit(2)
      circuit.rx(0.2, 0)
      circuit.rzz(1.3, 0, 1)

      target = Target.build_clifford_t(num_qubits=2)
      cliff_t = transpile(circuit, target=target)

[qiskit-bot]

One or more of the following people are relevant to this code:

• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 21581584907

Details

• 5 of 5 (100.0%) changed or added relevant lines in 1 file are covered.
• 5 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.02%) to 87.966%

---

Files with Coverage Reduction	New Missed Lines	%
crates/circuit/src/parameter/parameter_expression.rs	1	87.17%
crates/circuit/src/parameter/symbol_expr.rs	1	73.28%
crates/qasm2/src/lex.rs	3	92.29%

Totals
Change from base Build 21575821626:	0.02%
Covered Lines:	100018
Relevant Lines:	113701

---

💛 - Coveralls

[alexanderivrii]

Thanks Julien, the new method is considerably nicer from the API perspective. The PR looks great (modulo some docs errors).

I have a few higher-level questions.

First, we will likely want similar functions but with different basis sets, e.g. Clifford+RZ+T, or just Clifford. Do you envision that we will add similar methods build_clifford_t_rz, etc.?

Second, thinking of our Clifford+T transpiler pipeline work, suppose that we already have a Clifford+T target that we want to compile to, and suppose that we will want to construct a new intermediate target that also contains RZ gates and has CX gates going in both directions. Would it make sense to add a method to Target to produce such an "abstraction" from an existing target?

[alexanderivrii]

Do we want to expose other options of from_configuration to build_target?

[alexanderivrii]

I didn't know that we have this syntax: previously I always wrote release notes as in the suggestion below (this is only for illustration, so do not merge!)

Suggested change

	- Added :meth:`.Target.build_clifford_t` to conveniently build a
	- |
	Added :meth:`.Target.build_clifford_t` to conveniently build a

[jakelishman]

I don't deny this is a shortcut for the current API, but it's not clear to me that leaning all in on the existing Target to represent Clifford+T basis sets longer term is a good idea.

Yeah, the existing Target can represent Clifford+T basis sets, but we always have to re-infer that fact back off it later, which we do in a variety of messy and non-identical ways. Things like gate duration and individualised error rates for particular instructions don't seem like an especially good or meaningful representation, and this Target doesn't allow arbitrary or genericised "clifford" instructions, so it's more like "T and Tdg, plus Cliffords but decomposed to the particular set of built-ins Qiskit actually has", rather than "compile to a structured Clifford and extra 'magic'".

Personally, I don't think this is a clean API addition. It feels more like promoting an existing hack up to being blessed as "public API", especially because the internal code is so simple and so opinionated.

[Cryoris]

Thanks for bringing up these very valid points, I agree we eventually want a more formal separation here -- this PR was less ambitious here and has the main goal of having a convenient way of triggering the Clifford+T pipeline 😄 Maybe there's a way we can make an incremental step towards that here

Yeah, the existing Target can represent Clifford+T basis sets, but we always have to re-infer that fact back off it later, which we do in a variety of messy and non-identical ways.

Yeah it would be better if we could set a Target type or "class" in a generic way (not just near-term vs. Clifford+T). The optimization metric also goes into this direction.

Things like gate duration and individualised error rates for particular instructions don't seem like an especially good or meaningful representation,

Error rates and duration would make likely be important, not only for sub-groups (Cliffords, Paulis, T), but also depending on the locations (Cliffords on specific indices might be more expensive than others).

and this Target doesn't allow arbitrary or genericised "clifford" instructions, so it's more like "T and Tdg, plus Cliffords but decomposed to the particular set of built-ins Qiskit actually has", rather than "compile to a structured Clifford and extra 'magic'".

Agreed that we could add support for e.g. arbitrary Clifford objects, though I'm not sure how heavily used they are right now. I guess we don't want to check custom gates on their "cliffordness" though.

[alexanderivrii]

Thanks Jake. We should definitely at some point improve the code based on the points you raised. This issue is related to how we present the nisqy Clifford+T transpiler pipeline to users. When Julien presented the ongoing FTQC work in one of the meetings, several people have explicitly asked for a more convenient way to invoke the pipeline, without having to be aware of the more obscure get_clifford_get_names method.

[eliarbel]

Seconding Jake’s general feedback about the API aspect, I also think it’s better to keep the Target API generic instead of extending it with domain‑specific constructors. On the other hand, and recognizing the need for a convenience Target builder, how about supporting this using a standalone function? Or maybe a factory class if you see a need for more such convenience builder functions? But still keep Target generic as is.