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

Deprecate Qobj in unitary_simulator.py #11046

Closed
1ucian0 opened this issue Oct 19, 2023 · 3 comments · Fixed by #11395
Closed

Deprecate Qobj in unitary_simulator.py #11046

1ucian0 opened this issue Oct 19, 2023 · 3 comments · Fixed by #11395
Milestone

Comments

@1ucian0
Copy link
Member

1ucian0 commented Oct 19, 2023

I also just realized that qiskit.providers.basicaer.UnitarySimulatorPy.run() (https://github.com/Qiskit/qiskit/blob/main/qiskit/providers/basicaer/unitary_simulator.py#L206) never deprecated a Qobj input and will still support it while the qasm simulator and statevector simulator will not. I still think we should move forward with your PR, but it's something we'll want to clean up in a subsequent PR.

Originally posted by @mtreinish in #10872 (review)

@rupeshknn
Copy link
Contributor

rupeshknn commented Dec 1, 2023

Hi, I'd like to work on this. the description isn't very clear, though, could you help me with what needs to be done? Should I just deprecate Qobj input or remove this functionality?

@rupeshknn
Copy link
Contributor

rupeshknn commented Dec 4, 2023

When a QasmQobj is supplied to QasmSimulatorPy.run or StatevectorSimulatorPy.run, the error raised is:

QiskitError: 'bad input to assemble() function; must be either circuits or schedules'

And when a QasmQobj is supplied to QasmSimulatorPy.run, it complains that there's no n_qubits property for QasmQobj rather than clearly stating that only circuits are supported. (as the assemble call is tucked under a conditional)

Since a Qobj input cannot be used anyway, I think it's better to remove Qobj support directly rather than deprecate it and remove it in a later release. What do you think @1ucian0 @mtreinish?

@rupeshknn
Copy link
Contributor

Based on the conversation here with @1ucian0 I'll start with a deprecation PR to stable\0.46 and once that's done, I'll do a removal PR to main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants