Clean up backend.run(...) interface

[blakejohnson]

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]

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

[coruscating]

@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]

@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]

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]

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]

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]

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

[jyu00]

Closing since backend.run is deprecated.