Qiskit-terra: remove BasicAer

[ajavadia]

BasicAer is not needed anymore now that the quantum_info module can be used to simulate circuits. quantum_info has a more flexible workflow as you are not tied to the job/result interface and is nice for small circuit calculations. It is also faster as it bypasses serialization.

Operator(qc) (unitary) or zero.evolve(qc) (statevector) or zero.evolve(qc).probabilities_dict() (counts)

The only thing that BasicAer supports in addition to quantum_info is conditional operations I think, but I think that can be added too?

[1ucian0]

I think there is some value in keeping BasicAer API as a backend included in terra, using the quantum_info module under. It makes terra battery-included and allow us to test quantum_info as yet another backend.

I dont feel super strong about this, but just my two cents.

[chriseclectic]

I agree with removing for a separate reason: I think the main reason for it existing was due to C++ build issues with early version of Qiskit Aer, which are a lot better now.

If we do decide to keep BasicAer, we should only keep the QasmSimulator and remove the Unitary and Statevector simulators since as mentioned they provide nothing over the Operator and Statevector classes other than a less convenient interface.

The QasmSimulator has functionality not in the qi classes such as intermediate measurements and conditionals. I don't think these should be added to those classes because to do so you are basically rebuilding the qasm simulator (by adding classical registers and logic and notion of shots and results). I think it would be better to keep a specialized simulator class for this but have that simulator work directly with circuit and gate objects and not require going through the provider/qobj/job/result execution model.

[jaygambetta]

I agree it is time for basis aer to go as aer works and the quant-info should replace it

[Cryoris]

If we do decide to keep BasicAer, we should only keep the QasmSimulator and remove the Unitary and Statevector simulators since as mentioned they provide nothing over the Operator and Statevector classes other than a less convenient interface.

The one advantage BasicAer has, is that you can run circuits containing Barrier/Measure/Reset instructions. If we'll run algorithms from Aqua on quantum_info, we'll have to work around some of these (mostly to replace BasicAer's QASM simulator).

Alternatively, we could require Aer to be installed for any QASM simulations, but "Terra, batteries included" for both statevector and QASM seems nicer to me too.

[mtreinish]

I think it still provides value. Primarily it lets us exercise the entire execution path inside of terra itself. Personally it's been very useful for me as I've been implementing the v2 provider interface to be able to test using it directly in terra itself. It also serves as a decent example for implementing local simulator based providers because Aer is much more complicated.

There are also platforms where Aer still doesn't run that it is actively used (thinking mainly about ibm i per: #3362 and #3183 and my subsequent conversations with them).

I think we should promote the use of quantum_info instead of BasicAer for most use cases, but having basicaer still provides value. We could probably refactor the basicaer simulators to just use quantum_info inside, that would probably make it pretty small