Question regarding integral factor in hopping terms

[gsilviHQS]

Hello Qiskit community, could someone help me understand the origin of the factor "4.0 ** len(excitation[0])" in: https://github.com/Qiskit/qiskit-nature/blob/b0be0fbe4ece34a643339a1d838a0a86e752a8b1/qiskit_nature/problems/second_quantization/electronic/builders/hopping_ops_builder.py#L114 It suggest one should have a 4 to the power of the number of excitation, but is not clear at all to me why is this the case. I found in older implementation (e.g. in def _build_hopping_operator in https://qiskit.org/documentation/stable/0.19/_modules/qiskit/chemistry/components/variational_forms/uccsd.html#UCCSD.manage_hopping_operators) to just have a factor of 1 or -1. It is unclear to me what changed. Best, Giorgio

[mrossinek]

Hi Giorgio,

I am in contact with one of the original authors of the QEOM code to clarify your question (I did indeed see your comment on the commit yesterday, but thanks for opening this issue to track this a bit easier).

As per your linked code: that is in fact a different piece of code. The code where the factor 4 ** len(excitation[0]) arises, is part of the QEOM code. The code which you are linking to in the old implementation, is merely an implementation of the UCCSD variational form. At that time, the QEOM code did not even exist yet. You can see the modern implementation of UCC here: https://github.com/Qiskit/qiskit-nature/blob/b0be0fbe4ece34a643339a1d838a0a86e752a8b1/qiskit_nature/second_q/circuit/library/ansatzes/ucc.py#L486-L511 where you will in fact see that the unity factor is indeed implemented just like in the past.

If your original question was related to UCC, I hope this answers your question. Nonetheless, I will leave this issue open until I can also provide more details on the factor arising inside the QEOM hopping operators. I hope to have an answer for this next week :+1:

[gsilviHQS]

Hi Mrossinek, thank you for the fast reply! It answers my question on why the previous piece of code was different. I didn't notice it was for a different scope. But I would still look for an answer on why the QEOM case needs this "4.0**" factor. I tried to look into this paper: 10.1103/PhysRevResearch.2.043140 (which I believe to be a prominent paper on the QEOM method) but couldn't find a reference to this factor. The reason I ask this is because I was trying to implement a similar method to QEOM and was wondering if this particular factor is necessary. And to know that, knowing the origin of it would be extremely helpful. Thanks!

[Anthony-Gandon]

Hi Giorgio, I've been working on the QEOM code so I have some intuition to give on that "4.0**" coefficient. The excitation operators at this exact line of code look like this: (one line for one excitation operator)

(4+0j) * (+_0 -_1)
(4+0j) * (-_0 +_1)
(4+0j) * (+_2 -_3)
(4+0j) * (-_2 +_3)
(16+0j) * (+_0 -_1 +_2 -_3)
(16+0j) * (-_0 +_1 -_2 +_3)

And you can see that the qubit_op in the line just after look like this: (just the first two excitation operators)

-1j * IIXY
+ 1.0 * IIYY
+ 1.0 * IIXX
+ 1j * IIYX

-1j * IIXY
- 1.0 * IIYY
- 1.0 * IIXX
+ 1j * IIYX

...

Ultimately, these 'excitation' operators (written as sum of Paulis) will be measured on hardware to build the matrix elements appearing in qEOM . Then the classical diagonalization will find the optimal linear combination of these basis operators leading to the Hamiltonian's excited states. Thus, the coefficient "4**" will keep the coefficients in front of the Paulis composing the basis operators closer to 1. The coefficients of the linear combination of these operators (expansion_coefs) will be equivalently smaller. Without this coefficient, the terms that are sent for measurement have smaller prefactor but will be classically recombined with larger coefficients. Overall the two approaches are equivalent but I think the measurements statistics are better when the prefactor of each Pauli to measure is not shrinking to 0.

I hope this helps!

[gsilviHQS]

Hi Anthony-Gandon, thank you very much! This explains a lot actually and clarifies a mistake I was using in my code. Thank you for the help!

[mrossinek]

Thanks @Anthony-Gandon, for the explanation! Closing this now as resolved :+1: