Qiskit Target supports gate definition for multiple discrete angles. However our convert_to_target converter doesn't nicely support this mechanism. This PR overhaul the converter to support this feature.
Details and comments
Transpiler (translation) requires gate definition (e.g. matrix), which is directly attached to the Qiskit Gate object in the standard library. On the other hand, GateConfig in the V1 configuration model doesn't have this definition. The definition is obtained by the name matching, and thus GateConfig.name must be defined in the dictionary returned from the get_standard_gate_name_mapping function, e.g. sx, x, rx, ...
However, when we define new operation in the Qiskit Target via the .add_instruction method, one must specify the unique name argument when the entry is defined for a specific gate angle. This indicates GateConfig must also define unique label for fixed gate angle entries. Since original Qiskit model is not flexible, this PR redefines the similar model with .label field in the qiskit-ibm-runtime (to avoid version mismatch issue).
Alternatively, we can still use the Qiskit model with custom name with regex, e.g. rx_30, but we need to mange this regex pattern both on client and server side. Also this pattern becomes complicated when the gate has more than one parameters; gate with two parameters and only one parameter is fixed, u2_1.23_p1 -> U2(1.23, Parameter("P1")). In my opinion this approach is easy to implement but hard to maintain.
I prefer using the custom model with new label field, because this approach allows the client software (qiskit-ibm-runtime) to be agnostic to the gate naming convention in IBM Quantum systems.
I also introduced new backend configuration implementation with pydantic since this is already required package and much more performant and robust compared with the Qiskit implementation (I needed to update configuration to use new GateConfig model).
Summary
Qiskit Target supports gate definition for multiple discrete angles. However our
convert_to_targetconverter doesn't nicely support this mechanism. This PR overhaul the converter to support this feature.Details and comments
Transpiler (translation) requires gate definition (e.g. matrix), which is directly attached to the Qiskit
Gateobject in the standard library. On the other hand,GateConfigin the V1 configuration model doesn't have this definition. The definition is obtained by the name matching, and thusGateConfig.namemust be defined in the dictionary returned from theget_standard_gate_name_mappingfunction, e.g. sx, x, rx, ...However, when we define new operation in the Qiskit
Targetvia the.add_instructionmethod, one must specify the uniquenameargument when the entry is defined for a specific gate angle. This indicatesGateConfigmust also define unique label for fixed gate angle entries. Since original Qiskit model is not flexible, this PR redefines the similar model with.labelfield in the qiskit-ibm-runtime (to avoid version mismatch issue).Alternatively, we can still use the Qiskit model with custom name with regex, e.g.
rx_30, but we need to mange this regex pattern both on client and server side. Also this pattern becomes complicated when the gate has more than one parameters; gate with two parameters and only one parameter is fixed,u2_1.23_p1->U2(1.23, Parameter("P1")). In my opinion this approach is easy to implement but hard to maintain.I prefer using the custom model with new
labelfield, because this approach allows the client software (qiskit-ibm-runtime) to be agnostic to the gate naming convention in IBM Quantum systems.I also introduced new backend configuration implementation with pydantic since this is already required package and much more performant and robust compared with the Qiskit implementation (I needed to update configuration to use new
GateConfigmodel).