Circuit as reference state in the ansatz definition

[alexfleury-sb]

Circuit as reference state in the ansatz definition

What problem does this feature request help you overcome?

In our stack of Ansätze, located in toolboxes/ansatz_generator, most of them take a string reference_state as an initialization parameter. This determines the reference state of the ansatze, which is commonly HF for an Hartree-Fock state or zero for an empty circuit. As an example, here is the code that handles the reference_state for the toolboxes.ansatz_generator.uccsd.UCCSD ansatz.

https://github.com/alexfleury/Tangelo/blob/9079cb2e8c4b893027a7ff70101e968548000714/tangelo/toolboxes/ansatz_generator/uccsd.py?plain=1#L136-L153

This is restrictive in situations where non-conventional mapping are used, i.e. where HF has no meaning.

Describe the solution you'd like

A workaround would be to add support for a tangelo.linq.circuit.Circuit objects as a reference state. Logics have to be implemented to handle the right number of qubits in some edge cases, and to consider optimization (or not) if the reference circuit contains variational gates.

For some ansatze, it would remove the need of specifying the mapping and up_then_down parameters, as they are only used for reference state preparation.

As a minimal use-case, exploring combinatorial mapping optimization could be easier if this option is available. For e.g., if the code below could work without error, it would be awesome!

from tangelo.molecule_library import mol_H2_sto3g
from tangelo.toolboxes.qubit_mappings import combinatorial
from tangelo.toolboxes.operators import count_qubits
from tangelo.linq import Circuit, Gate
from tangelo.toolboxes.ansatz_generator import HEA

H = combinatorial(mol_H2_sto3g.fermionic_hamiltonian, mol_H2_sto3g.n_active_mos, mol_H2_sto3g.n_active_electrons)
n_qubits = count_qubits(H)

ref_circ = Circuit([Gate("RY", 0, parameter=0.5), Gate("RY", 1, parameter=-0.5)])
ansatz = HEA(n_qubits=n_qubits, n_layers=2, reference_state=ref_circ)
ansatz.build_circuit()

[cburdine]

Hi @alexfleury-sb and @ValentinS4t1qbit ,

I think this would be a good issue for me to work on, but I am in need of clarification on some of the details for this proposed enhancement. Here are a few questions that come to mind:

• My understanding is that if a tangelo.linq.circuit.Circuit object is passed to the ansatz constructor, you would like the circuit to be "prepended" to the variational ansatz circuit, correct? If so, is it safe to assume that the qubit indices in the reference state circuit should always correspond directly to the qubit indices in the generated ansatz circuit? (For example, do I need to worry about keeping any ancilla qubits clean for any of the ansatzes?). Sadly, I'm not familiar with all of the ansatzes supported in Tangelo.

• You mentioned edge cases such as when the reference circuit contains variational parameters. Should I make these parameters "trainable" with the rest of the parameters in the circuit returned by build_circuit? Are there any other pitfalls or important edge cases that I might encounter?

• What kind of validation should we perform on the reference circuit during the call to build_circuit()? For example, if a reference circuit contains more qubits than the ansatz uses, should this be allowed?

I'll keep looking at this issue and let you know if I have any further questions. Thanks! :atom_symbol:

[alexfleury-sb]

Hello @cburdine, here are my thoughts:

• At this time, I would only require the Circuit to be prepended to the ansatz circuit, this is indeed correct. For every ansatz, we usually use the HF reference circuit, which is only a depth=1 circuit with few NOT gates. I would not ask for a comprehensive set of tests to check if all qubit are matching, if the circuit makes sense, etc. The prepend step should be "as-is", i.e. with all the qubit states matching what is parsed to the function.
• Since we can easily optimize the reference state alone before prepending it to the rest of the circuit, I think having a solution where only the ansatz parameters can be trained is sufficient (i.e. you would need to convert the Gate variational flag is_variational off in the reference state circuit, if applicable).
• The only thing I can think of at the moment is to make sure the reference circuit can be prepended to the circuit ansatz (which can be done with different circuit sizes). It would leave a lot of freedom to the user, and he/she would be the best person to ensure the reference circuit is actually making sense (it would be hard to consider all the edge cases).

I hope I gave you enough information to get started. If not, I am happy to elaborate more!

[cburdine]

Thanks for the clarification @alexfleury-sb! I think I'll start working on this issue. Can you go ahead and assign it to me?

[cburdine]

@alexfleury-sb, I have a question related to the ILC and QCC ansatzes, both of which require a QMF state circuit. Since these ansatzes allow for a user to define a QMF circuit in their constructors (via the argument qmf_circuit), how should these ansatzes behave when a Circuit object is passed as the reference_state argument?

I could simply override the value of qmf_circuit with the reference_state Circuit, however this requires that the variational parameters in qmf_circuit must be retained.

This would differ from the behavior of the other ansatzes, where variational gates in reference_state are converted to non-variational gates. It this acceptable? Or, do you have another idea for how you would like me to handle these ansatzes?

(Edited for clarity)

[alexfleury-sb]

Hello again @cburdine, I think your solution is perfectly reasonable. The only thing I would request is an explanation of this in the docstring and in code comments, as it is different from the common behaviour.

[ValentinS4t1qbit]

Thank you so much for your contribution @cburdine

Please do not hesitate if you're interested in working on this project more, or have any feedback for us now that you're acquainted with 🍊 Tangelo 🍊 . Do not hesitate to mention the project around you if you think students or researchers may benefit from it. The package was designed for chemistry simulations but a lot of content can be readily applied to various topics.