Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Target.instruction_schedule_map().has_custom_gate() always returns True #9595

Closed
mtreinish opened this issue Feb 15, 2023 · 0 comments · Fixed by #9597
Closed

Target.instruction_schedule_map().has_custom_gate() always returns True #9595

mtreinish opened this issue Feb 15, 2023 · 0 comments · Fixed by #9597
Labels
bug Something isn't working mod: pulse Related to the Pulse module performance stable backport potential The bug might be minimal and/or import enough to be port to stable
Milestone

Comments

@mtreinish
Copy link
Member

Environment

  • Qiskit Terra version: 0.23.1
  • Python version: 3.11
  • Operating system: Linux

What is happening?

When using the InstructionScheduleMap returned from a Target object's (specifically from a FakeBackend object, but I think this occurs generally) .instruction_schedule_map() method the .has_custom_gate() method is always returning True. This wasn't the case pre-0.23.0 (and I expect means this is related to #8885 ). This leads to a transpiler performance regression because the transpiler thinks we need to evaluate pulse gates despite not having a custom calibration set.

How can we reproduce the issue?

from qiskit.providers.fake_provider import FakeGeneva

backend = FakeGeneva()
instmap = backend.instruction_schedule_map
assert not instmap.has_custom_gate()

What should happen?

The above code snippet should not raise an assertion error because no custom gates are defined in the instruction schedule map.

Any suggestions?

I think this is being caused by a type mismatch and differing expectations between the Target/BackendV2 path and the InstructionScheduleMap class. I originally thought this was just a case of a differing type being used in the target path post-#8885 to represent the default calibration from the defaults file now that we're lazy loading it. But looking at it a bit more closely the InstructionScheduleMap's entries from the fake backend are all ScheduleDef which would be the same as a manually created Schedule object. I"m not sure the best way to resolve this though.

@mtreinish mtreinish added bug Something isn't working performance mod: pulse Related to the Pulse module labels Feb 15, 2023
@mtreinish mtreinish added this to the 0.23.2 milestone Feb 15, 2023
@mtreinish mtreinish added the stable backport potential The bug might be minimal and/or import enough to be port to stable label Feb 15, 2023
@mergify mergify bot closed this as completed in #9597 Feb 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working mod: pulse Related to the Pulse module performance stable backport potential The bug might be minimal and/or import enough to be port to stable
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant