Computing the parameter lambda from a MolecularHamiltonian
PabloAMC opened this issue · comments
I'm trying to understand how to compute the lambda parameter of a Molecular Hamiltonian. For example, let us say I have the following Molecular Hamiltonian data
self.molecule_data = openfermion.chem.MolecularData(self.molecule_geometry, self.basis, charge = charge, multiplicity = 1)
One way I had thought of calculating the lambda parameter is as the sum of absolute values of the amplitudes in the Jordan-Wigner operator, eg
self.molecule_psi4 = openfermionpyscf.run_pyscf(self.molecule_data,run_scf=True)
molecular_hamiltonian = self.molecule_data.get_molecular_hamiltonian()
fermion_operator = openfermion.transforms.get_fermion_operator(molecular_hamiltonian)
JW_op = openfermion.transforms.jordan_wigner(fermion_operator)
l = abs(np.array(list(JW_op.terms.values())))
self.lambda_value = sum(l)
On the other hand though, one may use the amplitudes of the Hamiltonian, similarly as suggested in Qubitization of Arbitrary Basis Quantum Chemistry Leveraging Sparsity and Low Rank Factorization, in which case lambda could be computed as
H1 = molecular_hamiltonian.one_body_tensor
eri = molecular_hamiltonian.two_body_tensor
T = H1 - 0.5 * np.einsum("pqqs->ps", eri) + np.einsum("pqrr->pq", eri)
lambda_V = 0.5 * np.sum(np.abs(eri))
lambda_T = np.sum(np.abs(T))
lambda = lambda_T + lambda_V
I think these two values should be then the same but with some examples, one can see that they are not exactly the same, the former being smaller than the latter by a few percentage points depending on the molecule. Is there anything wrong with one of those forms of calculating lambda or does the reordering of terms from physics -> chemistry affect the value of the lambda and that is why I don't get the same result?
Thanks in advance!
So @Emieeel has been working on some code to do precisely this, see #725 - it's based on the work in https://arxiv.org/abs/2103.14753 . I think it's waiting on some reformatting, but you should in principle be able to pull it from his branch. I believe that going straight for einsum misses a few factors, he might be able to elaborate in more detail, but I think I'd trust the first value that you have here.
Thanks @obriente! By the way, a third way I can think of is
lambda_0 = np.sum(np.abs(H1))+0.5*np.sum(np.abs(eri))
To give an example, with water the values I get are
self.lambda_value = 256
lambda = 261
lambda_0 = 268
Indeed, it makes sense that these are all slightly different values. The correct lambda value for a qubit Hamiltonian would be the first one (but you could substract the constant if you want). In https://arxiv.org/abs/2103.14753 appendix C we elaborate on why these values are slightly different, it has to do with the reordering of integrals when writing the Hamiltonian as a weighted sum of Pauli strings (https://quantum-journal.org/papers/q-2019-12-02-208/ actually makes a small mistake in that regard). The QubitOperator in Openfermion actually has an easy way to compute the 1-norm/lambda value, as JW_op.induced_norm(). If you want to compute the lambda values without doing an JW transformation - as these can be costly - you can use the code in #725
@Emieeel I don't think the lambda value in our paper is "incorrect" (if that is what you mean to claim then can you describe this a bit better?). If I understand correctly, you are pointing out there is an additional symmetry in the Hamiltonian that can be taken advantage of. In particular, I think what you are pointing out is equivalent to the following. If you write it out in the normally ordered form, then you can see that there should be antisymmetry swapping p,q or r,s. That is,
V_{pqrs} a'_p a'r a_q a_s + V{rqps} a'r a'p a_q a_s = V{pqrs} a'p a'r a_q a_s - V{rqps} a'p a'r a_q a_s = (V{pqrs} - V{rqps}) a'p a'r a_q a_s
What this means is that if the LCU can take advantage of that symmetry the effective lambda from that term is |V{pqrs} - V{rqps}| rather than |V{pqrs}| + |V{rqps}|. We only get that lambda value if we take advantage of it.
So we're not taking advantage of that particular symmetry and as a result of lambda is slightly higher. It might be a good idea to take advantage of this. But that's different from saying the analysis is incorrect, right?
Hey @Emieeel thanks a lot for your answer. So if I get it right, the reason why self.lambda_value < lambda above, is due to equation C18 in your article, |g_{pqrs} - g_{psrq}| < |g_{pqrs}| + |g_{psrq}|due to the grouping of terms @babbush is mentioning above (thanks also Ryan!).
Do we also know why lambda_0 happens to be even larger than lambda? (sorry for the notation)
@babbush Hi Ryan, thank you for pointing this out. Indeed our main point here was that one could take advantage of this symmetry of the Hamiltonian, such that you get the exact same lambda value for a qubit Hamiltonian (obtained for example by a JW transformation in OpenFermion) written in terms of unique Pauli operators -- for which this symmetry is not apparent -- but I agree that this not incorrect. However as a small sidenote, I believe that the THC paper https://arxiv.org/pdf/2011.03494.pdf pointed out a small mistake concerning a factor 1/2 on page 37 (sorry if I'm a bit pedantic):
Note that these λ definitions differ from those given in [9]. At first glance λV appears to be a factor of 8 smaller.
The first reason for this is because we deviated from the convention of absorbing the factor of 1/2 into V (since
this is just a difference in convention, it is consistent with prior work). However, there is roughly another factor
of 4 difference that comes in because the work of [9] accidentally left out a factor of 1/2 in Eq. (A3). This leads
to a λV that is reduced by a factor of 4.
@PabloAMC Indeed, but I'm not sure if there is such a simple reason that lambda_0 is larger than lambda. It makes sense that they're different though, since you rewrite your Hamiltonian (a'_p a'_r a_s a_q = - a'_p a_s a'r a_q + delta_rs a'p a_q). The lambda value is dependent on how you write the Hamiltonian. Also, beware of the openfermion convention: h{pqrs} = g{psqr}.
@Emieeel yep that is correct, I agree with everything you write in your most recent comment.