Evolved operator functions

[Cryoris]

Summary

Part of #13046: The evolved_operator_ansatz and qaoa_ansatz functions.

This is based on #13295, so that PR will need merging first.

Details and comments

• After Prepare PauliEvolutionGate for Rustiq & port it to Rust #13295, the EvolvedOperatorAnsatz is already pretty performant since it does the Pauli evolution in Rust. However, with these functions we still gain a speedup since we can do all evolution at once in Rust and don't need go back and forth.

  This benchmarks the construction of an evolved operator ansatz for an Ising Hamiltonian on a square grid with side length n
  (so n ** 2 qubits), which has 2 operators; the ZZ-interactions and the X-field. For 100 qubits we get a speedup of 1.33x,
  which is increasing with the number of qubits (e.g. we get 1.83x at 10'000 qubits).

  -- n = 10, speedup 1.33x
  main: 0.033 +- 0.014
  this: 0.025 +- 0.009
  
  -- n = 50, speedup 1.64x
  main: 6.218 +- 0.200
  this: 3.792 +- 0.105
  
  -- n = 100, speedup 1.83x
  main: 100.487 +- 2.275
  this: 55.007 +- 1.139
  

• This also adds a new function called hamiltonian_variational_ansatz (HVA), which automatically splits an input Hamiltonian into commuting terms. This is slightly different to evolved_operator_ansatz, which requires you to manually do this split, but IMO the HVA is the form most users would be interested in. We could've changed the default behavior of evolved_operator_ansatz to do the splitting, but I didn't want to change behavior for a class that users are already used to.

[qiskit-bot]

One or more of the following people are relevant to this code:

• @Cryoris
• @Qiskit/terra-core
• @ajavadia

[coveralls]

Pull Request Test Coverage Report for Build 11726840442

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 82 of 86 (95.35%) changed or added relevant lines in 3 files are covered.
• 77 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.02%) to 88.936%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/circuit/library/n_local/evolved_operator_ansatz.py	69	73	94.52%

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	5	92.98%
crates/accelerate/src/synthesis/clifford/utils.rs	25	74.32%
qiskit/transpiler/passes/synthesis/hls_plugins.py	47	84.59%

Totals
Change from base Build 11725030912:	0.02%
Covered Lines:	79038
Relevant Lines:	88871

---

💛 - Coveralls

[Cryoris]

I'm not sure why this fails, the docs build is complaining about

/home/vsts/work/1/s/docs/apidoc/circuit_library.rst:: ERROR: Anonymous hyperlink mismatch: 1 references but 0 targets.

My best guess so far is that it doesn't like that the evolved_operator_ansatz function has the same name as the module its coming from?

[alexanderivrii]

I think this is in a good shape. Though I would like to take another look after #13295 is merged.

[alexanderivrii]

This looks good. I have left a few minor in-place comments and questions.

[alexanderivrii]

@Cryoris, one question just came up in a slack discussion with @raynelfss: why do you need the Rust changes at all? I do like the (small) cleanup that moves Instruction and StandardInstruction to some common place, and I don't mind this being a part of this PR, but we technically don't need it, correct? Could you also please comment why we need the change to radd_param.

[Cryoris]

The changes to Rust are artifacts from developing off a non-merged PR 😄 The Rust changes are not needed, I'll revert them.

[ShellyGarion]

LGTM. I have a minor comment about the docs.

[raynelfss]

I'm not too familiar with PauliEvolution or what the evolved_operator_ansatz tries to achieve specifically but the logic here is sound to me. I'll let @alexanderivrii have the last word on approving, but great job regardless!

[alexanderivrii]

LGTM!

[raynelfss]

Looks okay, we'll fix the removals with #13407