Proposal for slight modification to function generate_hamiltonian
#1373
michaelkaicher
started this conversation in
Features and ideas
Replies: 2 comments
|
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. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
All reactions