orbital reordering in FermionOperator class about openfermion

[jarrodmcc]

To clarify, when you say re-order, you are just talking about relabeling rather than actually permuting the operators to something other than normal ordering right? Can you talk a bit more about the application you had in mind? As the orbital labels usually only matter relative to coefficients of tensors defining some action on the space, like the Hamiltonian coefficients. Those objects are perhaps easier to permute in a lot of cases. Just trying to help brainstorm potential paths towards what you want. The even-odd choices for expanding orbitals into spin orbitals can be re-defined in a few places as well.

…

On Thu, Feb 22, 2018 at 4:23 PM, Isil Ozfidan ***@***.***> wrote: We would like to add a function to FermionOperator class that reorders the orbitals as 0,1,2,3,4,5,... -> 0,2,4,...,1,3,5... (from updownupdown... to upupupupdowndowndown) two ways we can do this: 1. just writing a function that takes in a FermionOperator and spits out a reordered FermionOperator. which is what I did to begin with but @msteudtner <https://github.com/msteudtner> raised the following concern: the FermionOperator does not know its order inherently and a user may end up adding/multiplying two differently ordered FermionOperators 🙀 2. we can make it a class method and let the FermionOperator know its order. This way it can check if its being added/multiplied with a another FermionOperator with the same order and if not - raises an error. This seems to be the *right* way of doing it to me but it would require overloading basic class methods. (unless there is some magic trick we can pull off 🎆) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#216>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHXFPGL4S7pOQxPKs-Zz5jvcNUGhjc2Aks5tXgUfgaJpZM4SQM-8> .

[msteudtner]

Hi @jarrodmcc
We want to relabel the indices.

Maybe to highlight a bit the relevance of this problem:
Let's say we have a molecule with spatial orbitals labeled ( A, B, C, ... ). The multiplicity of the spin will give you a spin-up version of A, let's call it A0, and a spin-down version of A, called A1. Similar for all other orbitals.
Now in OpenFermion, we consider (when we talk about a Fermion basis state) that it is generated by creation operators like in the following example:

a^{+}_0 a^{+}_1 a^{+}_2 a^{+}_3 ... |vac> .

Here the indices (0, 1, 2, 3, ... ) are short for the labels (A0, A1, B0, B1 , ... ).
That's a good choice: in Jordan-Wigner transform, Hubbard-like terms will probably be local i. e. ~ Z2 Z3 .
However: hopping terms from e.g. A0 to C0 will run over some orbitals with opposite spin, so here yield operators ~ X0 Z1 Z2 Z3 X4.
In arXiv:1403.1539 it is argued that one can save gates if we switch the ordering to
(A0, B0, C0, ... A1, B1, C1, ... ). Its true that the same hopping is then ~ X0 Z1 X2.

[babbush]

I am not a big fan of increasing the complexity of FermionOperator for this purpose. So I would vote against any solution that involves letting FermionOperator "know" its order. While it is conceivable that users could make the mistake mentioned in (1) by @conta877 , I don't have a lot of sympathy for such users. If one reorders FermionOperator A but not FermionOperator B and then adds them, that's sort of their fault (from my perspective). One should never need to reorder until immediately before mapping to qubits. In that sense, this problem should not be such a concern.

[kevinsung]

I agree with Ryan. Right now our approach is that users can specify the spin-indexing in functions that generate Hamiltonian models; the default is the even-odd scheme, but you can also specify other schemes (right now this is true for the functions in hamiltonians/_special_operators.py but #217 makes this true for Hubbard and mean-field as well). @conta877 @msteudtner is this approach is good enough for your purposes?

[msteudtner]

Would it perhaps be more practical to define a function somewhere that takes a FermionOperator and the number of modes as input and outputs the reordered FermionOperator (+ a function to undo this)?

The advantage would be that you wouldnt need to define it into every model, also not for any model in the future. Furthermore it allows me to do this reordering to a custom Hamiltonian. The disadvantage would be though, that it is faster to do this when creating a Hamiltonian rather than going over every index again afterwards.

What do you think ?

[kevinsung]

Do you have an example of a situation where you would want to use different spin-indexing schemes for different parts of the computation? If not, then I think it's better to just initialize all of your FermionOperators using the indexing scheme that you intend to use.

I just noticed that the even-odd scheme is hard-coded into the MolecularData data structure, but I think we can change that too.

[msteudtner]

Actually, if we could build in a 'half up'-option for the molecules, I would be deeply satisfied.

[babbush]

Sure, this should be fairly straightforward. I think this is a good solution.

[conta877]

So we are allowed to embed it into molecularData instead of a separate function? maybe initialize with a half_up = bool toggle?

[msteudtner]

[wrong chat, sorry]

[babbush]

Yes I think that is okay. @jarrodmcc or @kevinsung do you have any specific thoughts about that?

[kevinsung]

I think a boolean toggle to indicate which spin-indexing scheme to use is fine.

[jarrodmcc]

Such an option seems okay. I have no strong feelings between allowing arbitrary mappings in this sense vs the even odd or up then down ordering. You may just want to write a general permutation routine for tensors though, otherwise it may require modifications throughout MolecularData including the code that manually reads in RDMs from certain packages in their spinful representations.

…

On Fri, Feb 23, 2018 at 12:53 PM, Kevin J. Sung ***@***.***> wrote: I think a boolean toggle to indicate which spin-indexing scheme to use is fine. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHXFPEcLc_dolgAjoJfi0s-64IEh-ZLpks5tXyU-gaJpZM4SQM-8> .

[idk3]

@msteudtner @conta877 a while back I implemented something that can generically reorder fermionic modes in OpenFermion-ProjectQ. But looking at the discussion you might not need it after all :)

https://github.com/quantumlib/OpenFermion-ProjectQ/blob/master/openfermionprojectq/_ffft.py#L242 has swap_adjacent_fermionic_modes, the other half you'd need is some of the parallel bubble sort routines in OpenFermion-ProjectQ/_parallel_bubble_sort.py. Let me know if you have any questions.