Proposal for slight modification to function generate_hamiltonian
#1373
Replies: 2 comments
-
|
allow me to look on this issue @fdmalone |
Beta Was this translation helpful? Give feedback.
-
|
A useful way to frame the fix may be to distinguish tensor coefficient storage from the actual fermionic operator algebra. Even if a two-body tensor entry is nonzero, the corresponding normal-ordered term can still vanish algebraically when it contains repeated creation or repeated annihilation operators on the same spin orbital, e.g. or Possible acceptance criteria:
That would make the invariant explicit: the tensor may contain entries from the integral construction, but the emitted fermionic operator should respect the nilpotency of fermionic creation and annihilation operators. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
when playing with some active space Hamiltonians with pyscf and generating them as FermionOperator objects (or rather InteractionOperator objects), I found that the resulting Hamiltonian included a lot of unnecessary terms: namely, operators such as
h_{kklm} a_k^dag a_k^dag a_l a_m,
where h_{kklm} was different than zero and the operator thus included (but the operator a_k^dag a_k^dag a_l a_m is zero, so one should just set h_{kklm} to zero right away (k,l,m are here spinorbital indices).
Maybe this problem could be solved by just adding:
if not (p==q or r==s):before
# Same spin two_body_coefficients[2 * p, 2 * q, 2 * r, 2 * s] = (two_body_integrals[p, q, r, s] / 2.) two_body_coefficients[2 * p + 1, 2 * q + 1, 2 * r + 1, 2 * s + 1] = (two_body_integrals[p, q, r, s] / 2.)in line 272 of https://github.com/quantumlib/OpenFermion/blob/v1.6.0/src/openfermion/hamiltonians/hartree_fock.py#L245-L291
Would this cause any problems?
Cheers,
Michael.
Beta Was this translation helpful? Give feedback.
All reactions