Fake backends correctly report themselves as simulators

[nonhermitian]

Summary

Since time began, FakeBackends have been reporting themselves as not being simulators because their configuration files come from real systems. This forces people who use these systems for testing to use less than ideal coding practices, e.g. looking for fake in a name string, to identify these instances, and go from there.

This PR makes each backend report that they are indeed simulators, i.e. backend.configuration().simulator = True. This makes using these fake backends easier in downstream packages.

Details and comments

Fixes #

[yaelbh]

While working on #2000, I've noticed something that makes me understand that we have to be careful. In certain respects fake backends are to be treated as devices and not simulators. See this line: https://github.com/Qiskit/qiskit-ibm-runtime/blob/9f2dad538e9165d43bf9a6796eafeb85e963bb20/qiskit_ibm_runtime/base_primitive.py#L175-L176

--> We want fake backends to undergo ISA checks, but not simulators.

So, it seems that we have three types of backends:

1. Devices.
2. Fake backends.
3. Simulators.

In any case, this PR has to make sure that ISA checks will continue for fake backends. Check if additional fixes are required, except for ISA.

Also, possibly such a change (tagging fake backends as simulators) requires some kind of pre-announcement / deprecation etc.

[yaelbh]

To distinguish between devices and simulators, consider checking if the backend is an IBMBackend instance, as done here: https://github.com/Qiskit/qiskit-ibm-runtime/blob/9f2dad538e9165d43bf9a6796eafeb85e963bb20/qiskit_ibm_runtime/base_primitive.py#L178-L179

[nonhermitian]

We want fake backends to undergo ISA checks, but not simulators.

Why not? The simulators have a set of basis gates as well that must be satisfied, e.g. look at the basis gates for the aer simulator

[jyu00]

We want fake backends to undergo ISA checks, but not simulators.

Why not? The simulators have a set of basis gates as well that must be satisfied, e.g. look at the basis gates for the aer simulator

Excellent question. I don't remember exactly why it was done this way, but my first guess is that the cloud-based simulators didn't return correct information for the ISA checks to work.

[nonhermitian]

In this case, I think this is low hanging fruit given that the fake backends are indeed wrappers of the Aer simuilator at the end of the day. Anything that breaks on top is just abusing the current incorrectness of the setting.

[ElePT]

Maybe giving some transpiler context can be useful in this discussion. I am not so familiar with the Aer simulator, but I can say that a plain instance of BasicSimulator (former BasicAer) does behave differently to a fake backend that runs on it. The target from BasicSimulator reports num_qubits==None and no connectivity constraints (coupling map), while a fake backend will report the number of qubits of the snapshot it was built from (reference real device).

I like to see backends as target + run. Following this classification, we have the following categories:

• real backend: real target + real run
• fake backend: real target + simulator run
• simulator backend: simulator target + simulator run

The differences in target mean that, in practice, a BasicSimulator and a FakeBackend instance will trigger different transpilation paths. I believe this was the motivation to originally introduce the simulator property (or at least, how it was used in the transpiler), to set apart this particular exception in the pipeline where the target had no qubits. The fact that this wasn't extended to fake backends made sense, they didn't need to be singled out from the transpilation perspective, because their target is identical to a real backend's. It's very likely though that simulator was used with additional meanings from the "run" perspective, I am just not as familiar with them, and this may be the reason why its meaning is no longer clear.

However, from the pure BackendV2 model perspective, backend.configuration (and therefore simulator) is no longer part of the model. Because of this, the transpilation pipeline was updated not to rely on simulator. Instead, we look for num_qubits==None in the target to know this will behave like a simulator target (we don't care about the run part in transpile). This means that, in a way, the parameter is "free", and it might be possible to give it a new meaning, at least it would not change anything from the transpiler point of view. Nevertheless, I agree with @yaelbh's point in https://github.com/Qiskit/qiskit-ibm-runtime/pull/2005#issuecomment-2454755261 about warning about any change in these implicit assumptions about the meaning of the property, because they are not necessarily incorrect.

As for the isa check, I think that both the "real" and the "simulator" target could be isa-checkable (you'd have to adjust the num_qubits check to accept None), if that helps clear up things. Strictly, I don't think it makes a whole lot of sense for a simulator that doesn't require it, but I don't think it would be a problem to add it for consistency.