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

Clean up backend.run(...) interface #1297

Closed
blakejohnson opened this issue May 24, 2023 · 8 comments
Closed

Clean up backend.run(...) interface #1297

blakejohnson opened this issue May 24, 2023 · 8 comments
Assignees
Labels
enhancement New feature or request Epic priority: high High priority issue (must have for current release)

Comments

@blakejohnson
Copy link
Contributor

The backend.run(...) interface has accumulated a lot of cruft over the years. We need to start paring down this interface to only things which are essential.

Some things that I think can go (should validate all of these):

  • remove Schedule and List[Schedule] from the allowed types of circuits. We nominally stopped supporting these types already in January 2022.
  • qubit_lo_freq
  • meas_lo_freq
  • schedule_los
  • noise_model - should be attached to the Backend, not to the call to run().
  • seed_simulator - again should be an argument on the simulator/backend

More controversial, but I think still worthwhile:

  • drop the memory argument and only expose the behavior of memory=True. Rationale: if you really want statistics, use the Sampler instead.
  • meas_return - if we only support memory=True, then it only makes sense for this to be 'single'

For future consideration:

  • meas_level - OpenQASM 3 allows expressing different measurement levels with separate measure commands in the OpenPulse grammar. I think it makes sense to develop equivalents in Qiskit and then read out the requested measurement level from the circuit itself
@blakejohnson
Copy link
Contributor Author

@coruscating could you validate whether or not the LO parameters are used by qiskit-experiments?

@coruscating
Copy link

@blakejohnson We don't use these LO parameters in experiments.

Regarding only supporting single-shot memory by default: will the memory keyword being overloaded between level 1 and 2 be addressed? Or are we disabling the ability to get single-shot counts?

@blakejohnson
Copy link
Contributor Author

@coruscating if we only expose a memory-like interface, then I think that would imply that we only support single-shot values. I suspect that many qiskit-experiments probably expect average values, though.

@wshanks
Copy link
Collaborator

wshanks commented May 25, 2023

I think the LO parameters only work for schedule jobs that we don't support any more any way.

I don't have a strong opinion on the memory change. I would like qiskit-experiments to be able to handle single and average return formats seamlessly for analysis that works with the average any way. I think the main concern is data volume for parallel single qubit experiments. You can save a factor of a few hundred (the number of shots) when running something like Rabi across a device. If running a multi-qubit circuit, I think you care about the individual shots or could use the Sampler any way (because you likely have a discriminator).

I never use the online simulators, but why attach an option like seed_simulator to the backend rather than passing it with run? I am curious because any run() option you could choose to make something that you set on the backend instead.

@jyu00 jyu00 added the priority: high High priority issue (must have for current release) label Aug 7, 2023
@jyu00
Copy link
Collaborator

jyu00 commented Aug 21, 2023

but why attach an option like seed_simulator to the backend rather than passing it with run?

I think the rationale is that noise_model and seed_simulator are options to configure a backend. Whereas the rest are execution time options.

In addition to what @blakejohnson suggested, we should also mention that one can use backend.configuration().meas_levels to determine which levels are supported (the vast majority doesn't support 0 anymore).

@merav-aharoni
Copy link
Contributor

I've been looking at adding noise_model and seed_simulator to the IBMBackend cot'r. This doesn't really make sense, because no one is supposed to directly call this cot'r. The IBMProvider only "gets" a backend, but does not actually construct it.
The idea is that the backend is an object in itself, with all its properties. Therefore it makes sense to add these either through the IBMBackend.options or through IBMBackend.run(), which is the way it is now.
Any thoughts? @jyu00 , @kt474 , @blakejohnson ?

@jyu00
Copy link
Collaborator

jyu00 commented Sep 19, 2023

Therefore it makes sense to add these either through the IBMBackend.options

Yeah that's what we meant by "attached to the Backend", sorry for the confusion.

By the way, these options should only be available to simulator backends. For reference, this is how it was done in ibmq-provider: https://github.com/Qiskit/qiskit-ibmq-provider/blob/master/qiskit/providers/ibmq/ibmqbackend.py#L845-L853

@kt474 kt474 mentioned this issue Oct 24, 2023
13 tasks
@drew-distefano drew-distefano transferred this issue from Qiskit/qiskit-ibm-provider Dec 31, 2023
@drew-distefano drew-distefano added the enhancement New feature or request label Dec 31, 2023
@jyu00
Copy link
Collaborator

jyu00 commented May 22, 2024

Closing since backend.run is deprecated.

@jyu00 jyu00 closed this as completed May 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Epic priority: high High priority issue (must have for current release)
Projects
None yet
Development

No branches or pull requests

6 participants