JKMN / Neven / Ternary tree qubit mapping

[Qottmann]

What should we add?

It would be very useful to have the ternary tree qubit mapping (sometimes also referred to as the JKMN or Neven mapping after the authors) from this paper Optimal fermion-to-qubit mapping via ternary trees with applications to reduced quantum states learning.

[Qottmann]

Actually, this repository has it implemented in qiskit. The relevant file is here with all the diffs, should be just a matter of copy-paste as far as I can tell :)

[matteoacrossi]

Hi @Qottmann, I'm one of the authors of the repository you cited. We wrote the code for a older version of qiskit, and I'm interested in the development of this Issue.

[woodsp-ibm]

Hi @matteoacrossi as you may have noticed the code has been refactored/changed since the original chemistry in Aqua. You can see the mappers are standalone objects here, and the second quantization FermionicOp is rather different than the similarly named object from the past. Things were made more modular so like adding a new type mapper should just be a new mapper object now unlike in the past. Maybe you have already looked at the code here and know this.

In regards of looking at this, contributions are welcomed, please take a look at the CONTRIBUTING.md file which has some info for nature, also more generally https://qiskit.org/documentation/contributing_to_qiskit.html which applies to Qiskit overall as these may be helpful.

If you have any questions please feel free to ask.

[grossardt]

Hi, @rabinswosti and I used a (very rudimentary) version of tenary qubit mapping recently and we were interested in implementing this properly as a mapper for qiskit-nature. What is the status on this? We both have very little to no experience contributing to qiskit, but would be interested in this as a small project and happy to be assigned to it, if no one else is actively working on it.

[mrossinek]

You are welcome to start working on this! To my knowledge, no work is currently going on in this direction.

That said, you may have noticed that Qiskit Nature was moved into the qiskit-community organization. A more detailed announcement on what this means will come with the 0.7 release but in short this means that there will be some changes to the code-owners and that (at least currently) the bandwidth for reviewing and guiding PRs is kept to a minimum.

If you wish, you can of course start development in a separate repository. You can keep it in that separate repo altogether and add it to the Qiskit ecosystem to raise its visibility.

If you want to integrate this into Qiskit Nature (directly or later on from your repo) you should keep the following in mind.

• you should already follow the style guidelines set out by Qiskit Nature to make the move easier
• you should also follow the interface of the QubitMapper if you want this to be an addition that integrates well with the rest of Qiskit Nature (which will also increase the chance of a PR being accepted and merged).

[grossardt]

Follow up thought: The ternary tree mapping is technically not a fermionic mapper but a mapper from Majorana operators to Pauli Ops. In principle, the mapping is a two step process: fermionic op -> Majorana op -> Pauli op. I feel like the best way to embed this in Qiskit Nature would be to reflect this two step process and

1. implement a MajoranaOp class (derived from SparseLabelOp)
2. add a conversion method FermionicOp.to_majorana()
3. implement a base class MajoranaMapper
4. then implement the TernaryTreeMapper derived from MajoranaMapper

I am happy to work on all four points, but wanted to discuss if this is truly the best course of action. Of course one could also implement it as a direct mapper FermionicOp -> SparsePauliOp, but to me it seems much cleaner this way, fitting better with the structure of Qiskit Nature, and having the MajoranaOp may be useful for other things as well. (MajoranaOp and MajoranaMapper would obviously be very similar to FermionicOp and FermionicMapper, so I guess a lot of steps 1. and 3. is copy&paste.)

Also wondering if implementing the MajoranaOp class should maybe be its own separate issue (assuming this is the way to proceed).

[mrossinek]

Yes, that sounds like a good idea :+1:

For now, I would prefer a MajoranaOp.from_fermionic_op constructor, but this is a minor technical detail.

I suggest you do this in two PRs:

• [ ] implement a standalone MajoranaOp (incl. a MajoranaOp.from_fermionic_op constructor). This PR should also include unittests which assert that the eigenvalue of a MajoranaOp and FermionicOp are identical (for example).
• [ ] implement a TernaryTreeMapper (this PR can also add the MajoranaMapper interface, since these are basically empty and only used for typing)