Qiskit Circuit Library deprecations

[woodsp-ibm]

There are circuit library classes from qiskit used in algorithms, which were based on a BlueprintCircuit base class that provided more a template capability where for instance number of qubits could be changed. These classes are now deprecated (since 1.3) and are replaced by functions that build out the circuit but where the circuit is now fixed at construction time.

E.g for circuit library RealAmplitudes anstaz

    @deprecate_func(
        since="1.3",
        additional_msg="Use the function qiskit.circuit.library.real_amplitudes instead.",
        pending=True,
    )

As such code that attempts to set the number of qubits (Such as VQE and VQD try to do for the anzsatz) would not have the possibility now to work with such circuits. The attempt to change/check should stay but we should add deprecation message saying this adjustment is deprecated, should it succeed, as circuits based on BlueprintCircuit that can do this are themselves deprecated and in the future, when such circuits are removed from Qiskit it will not be possible to set num_qubits at all any more.

This affects main code, unit tests and tutorials where uses of these classes should be replaced by the new function equivalent.

[tnemoz]

In qiskit_algorithms/minimum_eigensolvers/adapt_vqe.py, what shall happen to the following check?

        if not isinstance(self.solver.ansatz, EvolvedOperatorAnsatz):
            raise TypeError("The AdaptVQE ansatz must be of the EvolvedOperatorAnsatz type.")

EvolvedOperatorAnsatz is based on NLocal, which is itself based on BluePrintCircuit, which, if I understand correctly, is deprecated. So, should we simply remove this check?

This question may also be related to the fact that an EvolvedOperatorAnsatz becomes a simple QuantumCircuit upon transpilation and thus fails this check 😄

More generally, AdaptVQE uses some attributes that are specific to EvolvedOperatorAnsatz, such as operators if I'm not mistaken. What is the best way to perform the migration here?

[woodsp-ibm]

I imagine, when all that is left are the functions to create the circuits that AdaptVQE would have to manage building the ansatz itself in order to update operators (which before could be set via the EvolvedOperatorAnsatz class). The ansatz can be given to VQE (ie set into the instance) as it was done before. A user building out a VQE instance it would more become the ansatz gets overwritten rather than needing to be the specific type. I guess, as it stands VQE needs to be passed an ansatz and allowing it to be None and requiring it to be set by the time its needed is not going to be so easy as optimizer exists after it. Maybe we can say in AdaptVQE that a simple QuantumCircuit can be provided - we could even add a static method to VQE (or AdaptVQE) to supply such a thing for the user to pass. Not sure what else can be done aside from say making AdaptVQE more standalone including aspects of VQE which would be a rather more radical change to AdaptVQE. The "dummy" circuit is perhaps the most compatible though a bit ugly!

As to migration, maybe if VQE's ansatz is an EvolverOperatorAnsatz it goes with that else it uses evolved_operator_ansatz to create it itself and discard whatever the user passed instead of raising an error. Maybe need to have a few words in docstring about this.

Unless you have any better ideas. Given the V2 change is more a breaking change versus a migration maybe things should just be switched over to use the functions - tutorials, tests etc and anywhere in the code that might create such a (blueprint) circuit. Hopefully its mostly transparent and a user could still use the Blueprint ones while they still exist.

[tnemoz]

I'm not familiar at all with how AdaptVQE works, so what i'm going to say may not be worth much!

If I understand correctly, the user would have to provide a VQE instance, which requires an ansatz to be set. However, this ansatz would be immediately overwritten by the AdaptVQE algorithm using either EvolvedOperatorAnsatz or evolved_operator_ansatz, which would be kind of weird.

In that case, wouldn't that be more convenient/practical to instead have AdaptVQE ask for parameters at initialization that would later be used to initialize the inner VQE solver? That is, the logic of the algorithm remains the same with an inner VQE solver, but it would be created internally. By doing so, instantiating VQE could be done once the ansatz would be ready. And by doing so, we'd have full control on the ansatz, so that we don't have to check the type.

AdaptVQE would also require the user to provide it with the evolution operators instead of getting them from the EvolvedOperatorAnsatz.

In that case, we could still support passing a VQE instance directly, but then add a warning that the ansatz would be overwritten, and deprecate this approach.

Would that make sense?

[woodsp-ibm]

I happened to see that the deprecation messages in these circuit classes have been updated. E.g the one in RealAmplitudes, that was as I copied it above (and still is that way on until 2.0) has been changed in 2.1 thus

@deprecate_func(

    since="2.1",
    additional_msg="Use the function qiskit.circuit.library.real_amplitudes instead.",
    removal_timeline="in Qiskit 3.0",
)

So it looks like the classes will be around longer but the issue remains the same really in that usage of those classes ideally should be replaced in Algorithms here by the functions.

I am not so familiar with the exact details of AdaptVQE either but to my knowledge it already "overwrites" the VQE ansatz. It basically takes the ansatz from VQE, makes sure its of evolved operator type and if not errors out. If it is it takes the initial state from that evolved operator ansatz and also the set of operators. It then updates the VQE in a loop, starting with the initial state it then updates the ansatz operators from the set it got based on a gradient computation that I believe selects those that most affect the outcome.

Yes it uses VQE as a solver and before let the user create that since it runs that algorithm a number of times as it updates the ansatz. It would be possible for AdaptVQE to create it instead but then whats needed to do so, outside of the ansatz, would need to be passed to AdaptVQE, So instead of taking solver, it would, in its place, need estimator, optimizer and gradient, as well as callback if we want to allow the user to monitor the VQE behavior. Maybe AdaptVQE building a VQE is 'cleaner' but its going to be a bigger change to AdaptVQE. A different thought might be to allow VQE to take None as an ansatz and check/require it to be non-None at the point its needed - the VQE ansatz can be updated/replaced - maybe thats better than a dummy circuit just to keep VQE happy. There is already a check - but at present it just checks the num qubits match to the operator given that the ansatz is not supposed to be None (if it happened to be it would error trying to get its num_qubits).

Also, in using circuit functions instead of the EvolvedOperator class one thing that had was the notion of an initial state, a circuit that prepended the ansatz so as when the anstaz starts as an identity its evolving from that state. This would have to be separately supplied and prepended to ansatz circuit when built from the function.

AdaptVQE would also require the user to provide it with the evolution operators instead of getting them from the EvolvedOperatorAnsatz.

Yes, but note all the other inputs it had to create the ansatz (which are mostly there in the function replacement too) which would need to be supplied too by the user to AdaptVQE with it having now to build the circuit from the function going forwards.

I guess it might be possible to have the user supply some function that builds out the solver so all AdaptVQE needs is say a function that is passed an ansatz and this goes to VQE along with whatever the other estimator, optimizer parameters etc the user supplies. This way it would be more a factory function to build a VQE solver, ie a solver_factory, instead of a solver itself.

At the end of the day its going to be a choice in how to alter AdaptVQE for once the EvolvedOperatorAnsatz no longer exists and it has to use the function to create the ansatz instead. The circuit in this latter case is fixed unlike the BlueprintCircuit based EvolvedOperatorAnsatz that could be updated. Hope this discussion helps rather than confounds things further. If VQE solver and evolved operator ansatz are all called/created internally then its certainly quite a few more parameters than AdaptVQE has today. Maybe the VQE ones are not so bad - but the other parameters that a user would supply for the evolved operator ansatz thats quite a few cluttering up things - could have user supply a factory function - ie a partial over the original that just needs operators as that is all AdaptVQE is changing right. Hopefully things become clearer when the conversion is attempted as to what seems best.