Added decompose to the returned circuit of TrotterQRTE

[tnemoz]

Summary

This PR fixes the TrotterQRTE tests that are failing in the nightly CI.

Details and comments

The nightly CI is currently failing because of the TrotterVQE tests. This is due to Qiskit/qiskit#14934, which added a to_matrix method to PauliEvolutionGate.

This PR has been done because there was a discrepancy between the documentation of PauliEvolutionGate and its actual implementation. Namely, when calling Statevector or the likes on a circuit using a PauliEvolutionGate, what would be returned would actually be the implementation of the evolution (using a Lie-Trotter formula for instance), whereas PauliEvolutionGate in itself represents the exact evolution.

In our case, this meant that some tests were testing for the implementation, but were checked against the exact evolution when using the latest Qiskit version, which of course resulted in errors, especially since the tests only use a few time steps.

Similarly, when printing the evolved_state of a TimeEvolutionResult, the PaulIEvolutionGate representation would appear, which may by misleading. Indeed, in the [5] cell of the associated tutorial, one can see that the label of the gate on the right of the circuit is the exact operator, while this is really its approximation.

The fix for this is to decompose the evolved_state before returning it, or before using it to evaluate the aux_operators. If having a custom gate representing the time step approximation was desirable, we could define a custom gate defined using the decomposed version of the PauliEvolutionGate.

[coveralls]

Pull Request Test Coverage Report for Build 17728641718

Details

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.001%) to 90.195%

---

Totals
Change from base Build 17632079532:	0.001%
Covered Lines:	6660
Relevant Lines:	7384

---

💛 - Coveralls

[ElePT]

The fix LGTM. If I have understood correctly, this would "unlock" full compatiblity with qiskit 2.2.0, but there would still be some failing tests with the 2.1.x series because of the issues discussed in #244 (comment). Would you say this is accurate? Or am I missing additional issues with 2.2.x that would prevent this full compatibility?

[tnemoz]

The fix LGTM. If I have understood correctly, this would "unlock" full compatiblity with qiskit 2.2.0, but there would still be some failing tests with the 2.1.x series because of the issues discussed in #244 (comment). Would you say this is accurate? Or am I missing additional issues with 2.2.x that would prevent this full compatibility?

If I'm not mistaken, you're correct on this! The failing tests do so because of bugs introduced in 2.1.0 and that will be fixed in 2.2.0. As far as I'm aware, there's no other problems with the 2.2.X series, so it should provide full compatibility.

[ElePT]

Great, LGTM

[Cryoris]

It seems the coveralls report failed (though on coveralls.io all looks fine) -- maybe try pushing an empty commit to re-trigger the CI run? 🙂

[ElePT]

I think that our coveralls action might be out of date and that's why the check is failing. I will try to look into it within the next couple of days.

[ElePT]

I am going to merge this PR in the meantime, I have tested a couple of coveralls fixes but they didn't work, so I wouldn't really block progress on it.