Implement pass checking for multiple measurements on the same qubit

[Travis-S-IBM]

What is the expected enhancement?

Right now, as far as I can tell, if a circuit has multiple measurements on the same qubit, that error is not caught until the circuit hits the backend (generating a 7004 IQX error).

In the absence of the ability to handle such circuits on the backend checking that a transpiled circuit does not have multiple measurements on the same qubit would be wise.

This issue is particularly salient given the behavior of the StochasticSwap pass, which, according to its own documentation, could trigger this kind of problem.

Notes:

1. Measurements may occur and be followed by swaps that result in repeated measurement of the same qubit. Near-term experiments cannot implement these circuits, so some care is required when using this mapper with experimental backend targets.

Having some kind of AnalysisPass that checks for multiple measurements on the same qubit, and raises some warning if there are, would be useful for preventing users from submitting jobs that won't run on the backend.

My naive solution in debugging some code has been to emit the circuit to QASM and then use re to parse it for instances where the same qubit is measured. I don't quite know what properties of the underlying DAG the pass would need to check for, though.

[ajavadia]

In normal usage all current preset passmanagers run BarrierBeforeFinalMeasurement before StochasticSwap to ensure this does not occur. However if the swapper is used in isolation, yes, this could occur. The circuit is not wrong though, just not runnable on current hardware. On next gen hardware it may actually be desirable to measure early, rather than later. So this falls within the realm of qobj validation, and I think @taalexander @itoko are working on formalizing the constraints of the backend to be verified against. This is an example of a constraint.

[1ucian0]

Is #3251 another example?

[Travis-S-IBM]

@1ucian0 In spirit, yes.

@ajavadia Insofar as this problem is being addressed through the qobj validation project, I wonder if a soft solution in the form of more documentation would be useful.

I'm collaborating on a project where we wrote our own pass manager that's loosely based on the level 3 pass manager in Terra, except we didn't include the BarrierBeforeFinalMeasurements pass. I'm surmising the issues we're running into are caused by that.

Perhaps we could include a comment in any default pass manager using StochasticSwap that says something to the effect of "We use BarrierBeforeFinalMeasurements to prevent StochasticSwap from accidentally introducing multiple measurements on the same qubit".

In addition, the "notes" for StochasticSwap should include a warning, or at least, a suggestion, to include BarrierBeforeFinalMeasurements as a pass before StochasticSwap itself.

Of the two proposed ideas, I think the first is the more important one to do, as explaining to developers why the defaults are the way they are is a good practice to help them build intuition.

Do these ideas seem reasonable?

[ajavadia]

Yes a comment in the preset passmanagers explaining why they are built like that would be good.

On Oct 12, 2019, at 4:31 PM, Travis-S-IBM notifications@github.com wrote:

@1ucian0 In spirit, yes.

@ajavadia Insofar as this problem is being addressed through the qobj validation project, I wonder if a soft solution in the form of more documentation would be useful.

I'm collaborating on a project where we wrote our own pass manager that's loosely based on the level 3 pass manager in Terra, except we didn't include the BarrierBeforeFinalMeasurements pass. I'm surmising the issues we're running into are caused by that.

Perhaps we could include a comment in any default pass manager using StochasticSwap that says something to the effect of "We use BarrierBeforeFinalMeasurements to prevent StochasticSwap from accidentally introducing multiple measurements on the same qubit".

In addition, the "notes" for StochasticSwap should include a warning, or at least, a suggestion, to include BarrierBeforeFinalMeasurements as a pass before StochasticSwap itself.

Of the two proposed ideas, I think the first is the more important one to do, as explaining to developers why the defaults are the way they are is a good practice to help them build intuition.

Do these ideas seem reasonable?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Travis-S-IBM]

@ajavadia Great!

@1ucian0 Is this a task I can open a PR on? I'm not terribly familiar with the default pass managers, so I wouldn't do a very good job explaining the reasoning...

[1ucian0]

I think we need to come up with a semantic qobj validator. Let's think over it...

[taalexander]

This is exactly the case that an RFC would be excellent for since it has sweeping consequences. I believe the validation should happen at the quantum circuit and pulse schedule level operating on the configuration+(circuits/schedule). I will be opening a PR for RFC later today to the qiskit meta-repository. I do not mind at all first formalizing the Qiskit layer of constraints and then figuring out how we will serialize them for transport.

[nonhermitian]

So the jobs also get validated on the API side of things. This cannot be avoided due to the fact that people can submit jobs independent of qiskit. So one must be careful here as the overhead from checking things twice will get expensive as the size of the submitted jobs grow.

Now that jobs are beginning to return proper errors, it may be best just to let the API checker do its thing and error the job from there.

Similar with #3251

[taalexander]

I disagree that this is the right place to implement validation. It may be a useful second-check, but the majority of the framework should at least be based in qiskit (turned off by default) and run on the API. For example, consider some of these cases:

• Pulses must have a certain sample alignment, we may wish to automatically pad out pulses to this alignment
• Devices may only support a certain amount of instruction memory and trading off between unrolling loops or branching loops
• We may require buffering times between certain pulses and may wish to adjust a schedule to be valid if it fails the constraints
• A number of cycles may be required between measurements in a quantum circuit, and we will need to insert NOPs to properly align the circuit.
• Accessing memory out of supported range All of these (and more) can be formulated as constraints and can envision situations where we insert/update are instructions to obey constraints. Maybe a backend doesn't want to communicate all of its constraints, and there could be a separate per-backend way of handling constraints here. Maybe a better word than constraints is required since they typically have a different meaning in compilers (https://gcc.gnu.org/onlinedocs/gcc/Constraints.html). Something like machine property constraints. At the end of the day it is important we start to formalize this information with structure, we've started to do this with things like n_qubits and coupling_map and we should continue to. Something like https://llvm.org/docs/WritingAnLLVMBackend.html#target-machine

[jakelishman]

I'm going to close this issue as stale now - multiple measurements on the same qubit no longer seems to be a problem on IBM backends. If there's more to discuss about any of the old discussions here about what a backend might report to Terra about its allowed structures of operations, please feel free to open those in new issues.

The idea of having multiple measurements on the same qubit is not an invalid QuantumCircuit of itself, so these restrictions would be being placed only by a backend that could not support them.