Add a new argument concurrent_measurements to target class

[to24toro]

Summary

Make the Target class be aware of meas_map (concurrent_measurements is an alias). I added a new attribute concurrent_measurements to the from_configuration function and we can prepare for the Target class that has the info of the ScheduleConfig.

Details and comments

Need to review after #10150.
related to #10200.

[qiskit-bot]

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

• @Qiskit/terra-core
• @nkanazawa1989

[TsafrirA]

I have some minor suggestions for the doc strings which relate to the next point.

This goes beyond the scope of this PR, but I am not a fan of the fact that we use meas_map to describe two different representations (list vs. dict). At the very least, I think we should be clearly documenting this - What is accepted as input? What is the actual format used later on?

[TsafrirA]

The two representations of meas_map are accepted as input, but only one is documented here.

[to24toro]

So far, most part of the meas_map type is list and this is converted into Dict in inner codes. However, I think that 'meas_map' accepts Dict, e.g. macros.measure, in some cases because Dict of meas_map is easy to understand intuitively rather than List if there exist hardware constraints.

I treated the meas_map type as Dict and implemented macros.measure in backendV2. (It seems that format_measmap was implemented because it is easier to use for Dict than for List.)
So, if the input is a List, I would like to use format_measmap to convert the List to a Dict, and accept both List and Dict as input.

[TsafrirA]

Again, only one of the two accepted formats is documented here.

[to24toro]

As you pointed out, the document is not easy for users or developers to understand.
I fixed at 407f87d .

[TsafrirA]

Despite documenting the list option in the doc string, we actually convert to the dictionary option here.

[nkanazawa1989]

Do we need to convert the data format here? Probably this is bit confusing to users if input data is implicitly modified. Since formatted meas map is useful for implementing pulse scheduling, probably we can do this format in the scheduler. Then we can restrict the input to list format.

[to24toro]

I fixed at dc45405.

[TsafrirA]

And again, the inconsistency between the doc string and the actual format used later.

[coveralls]

Pull Request Test Coverage Report for Build 5597675106

• 4 of 5 (80.0%) changed or added relevant lines in 3 files are covered.
• 17 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-0.007%) to 86.048%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/providers/fake_provider/utils/backend_converter.py	0	1	0.0%

Files with Coverage Reduction	New Missed Lines	%
qiskit/extensions/quantum_initializer/squ.py	2	80.0%
crates/qasm2/src/lex.rs	3	91.14%
crates/qasm2/src/parse.rs	12	96.18%

Totals
Change from base Build 5597428209:	-0.007%
Covered Lines:	72684
Relevant Lines:	84469

---

💛 - Coveralls

[nkanazawa1989]

This looks good to me. Just to make sure

@mtreinish Are you fine with updating the Target model at Qiskit level? Alternatively we can do this in IBM provider, however pulse and circuit scheduler may rely on this constraint and exposing this in general Target makes sense to me (as long as Qiskit provides schedulers).

@wshanks We assume concurrent_measurements (aka meas_map) is just a static list of sub qubits measured together. Can future/non-IBM backend expose different constraints? If so probably we should make Target.concurrent_measurements a method so that we can do some formatting/operation in future.

[wshanks]

We assume concurrent_measurements (aka meas_map) is just a static list of sub qubits measured together. Can future/non-IBM backend expose different constraints? If so probably we should make Target.concurrent_measurements a method so that we can do some formatting/operation in future.

@nkanazawa1989 Do you have anything specific in mind? The current status is that all IBM hardware backends currently put all qubits into one measurement group. I think this is mainly a software constraint left over from how the system was originally designed with a single acquisition trigger. Beyond that, I could imagine qubits being split into groups based on multiplexed readout -- requiring qubits on the same output line to be measured simultaneously (I could also imagine not having this constraint). Those are the most concrete constraints I can suggest. I don't know other qubit architectures that well though.

[mtreinish]

@mtreinish Are you fine with updating the Target model at Qiskit level? Alternatively we can do this in IBM provider, however pulse and circuit scheduler may rely on this constraint and exposing this in general Target makes sense to me (as long as Qiskit provides schedulers).

I'm fine with adding it. I'll defer to both you and @wshanks on how common you think it'll be. If you guys think it's a common constraint that is not just a custom implementation detail for IBM hardware then I'm fine adding it as an optional field to the target. My thinking is for multiplexed readout it feels like this would be a common thing if other hardware does that and we want to support scheduling for that. But I'm also much less familiar with these hardware constraints.

[nkanazawa1989]

Thanks @wshanks , @mtreinish sounds like we can go with current assumption. What I had in mind was some edge case that cannot bootstrap sub-qubit lists, e.g. qubit group may change depending on inclusion of a particular qubit -- in this case concurrent_measurements should take some input (it's pretty tough to promote attribute to method). Likely this is just an overengineering.

I'll merge this PR as-is. Thanks for your input!