Add timing information to `mitiq.ddd`

[natestemen]

Dynamical decoupling is more effective when the pulses (or gates) take into account the duration of each gate. Our implementation assumes that every gate is the same duration since we solely use the concept of "moments" to schedule DD sequences. This is, unfortunately, not true. Multi-qubit gates often take longer than single-qubit gates which means a qubit might be sitting idle for longer than needed when a DD sequence overlaps a multi-qubit gate.

Adding timing information to mitiq.ddd is not going to be straightforward since it is purely digital and gate times vary over time.

Idea 1: Allow the user to report gate times.

Add an option to mitiq.ddd.execute_with_ddd (such as gate_times: dict[str, float]) with explicit gate times defined. We could then use this timing information to more appropriately schedule sequences while other gates are running.

Example

If a CNOT takes twice as long as single qubit gates, and the user wants to schedule an XX sequence, we could transform a circuit as follows:

Before	After
a --@----- | b --X----- c --------	moment 1 | | moment 2 | | ▼ ▼ a --@----- | b --X----- c --X--X--

Here, qubit a and b are intentionally left "idle" after the CNOT to account for the fact that the actual duration of CNOT[a, b] is twice that of X[c] and X[d].

Downsides

The downside of this approach is that users have to report gate times, which adds an extra step for them (if they want to). We would also want to check to ensure that a machine handles the above circuit transformation above as expected. Do qubits a and b actually "idle" for zero seconds after the CNOT if there is a moment 3 with gates on a and b?

Idea 1a: Figure out gate times

We could run a sequence of experiments to figure out gate times, and feed that data into Idea 1. This is made annoying by long queue times.

Idea 2: Use pulses.

Use one of the pulse libraries to rewrite mitiq.ddd.

The downsides to this approach are mostly unknown (to me), but I'd worry that this can not be done at a hardware agnostic level. I'd love to learn that's not the case, however.

Any thoughts @Misty-W @nathanshammah? (this was a feature request of Greg Quiroz)

[Misty-W]

I support investigating adding timing info to DDD, investigating both options and potentially brainstorming others! After all, multiplatform =/= "hardware ignorant". It might not work for every frontend/backend combination, but making it optional should alleviate that concern.

[Misty-W]

Also, many thanks to Greg for participating and giving a feature suggestion! 💯