Lattice QED Hamiltonian for Quantum Computing

[ariannacrippa]

#Summary
In my doctorate, I have been interested in studying Lattice Gauge Theories (LGT), especially Quantum Electrodynamics, or QED, with quantum computing. That is the reason why I have developed a Python code that can define the Hamiltonian up to 3-dimensional systems. The idea of this code is to start from a lattice, define the electric, magnetic and, in the case of matter fields, mass and kinetic Hamiltonians. The output can be used for further studies of lattice systems and computing observables, like the spectrum, static potential or other observables. The user should provide only the input values of the parameters in the Hamiltonian (like mass, or coupling values), and which size of the lattice wants to compute. I have also considered two bases: electric and magnetic (NB:the magnetic basis that I have considered was developed in this paper: https://arxiv.org/pdf/2006.14160.pdf )

#Details
The code is compatible with exact diagonalisation libraries and Qiskit library.
In the directory, there are the following files:
'HC_Lattice.py' A python code that builds a lattice in generic N dimensions, with periodic or open boundary conditions. It finds the set of links and sites, build plaquettes and chain for Jordan_Wigner definition (version up to 3D).

'Hamiltonian_QED_sym.py' A python code that builds a symbolic expression of QED Hamiltonian N-dimensional lattice, both with open and periodic boundary conditions. The formulation is from Kogut and Susskind (staggered fermions) and the Gauss’ law is applied. By doing so, we will get a gauge invariant system, reduce the number of dynamical links needed for the computation, and have a more resource-efficient Hamiltonian suitable for a wide range of quantum hardware.

'Hamiltonian_QED_oprt.py' A python code that imports the Hamiltonian from symbolic expression and build the operator form (sparse matrices or PauliOp, suitable for qiskit quantum circuits). It considers two types of encoding: 'ed' returns sparse matrix, 'gray' (also called logarithm encoding) with option sparse=False it returns PauliOp expression, otherwise a sparse matrix.

'class_H_QED_test_sym_oprt.ipynb' notebook with two examples.
In this notebook one can also visualize the Hamiltonian expression (printed also in latex format, useful for external documents) and then decide which encoding to use and if the final expression must be written in terms of Qiskit's Pauli operators. It is also possible to put static charges on the sites and study the static potential.

I need to mention that I have tested the 1d and 2d cases with external works,however, I have not tested 3d case yet, since I don't know anyone that is working on that at the moment.

I wanted also to mention that this is the first draft of the code, in order to explain the idea behind it. In case it is considered useful for qiskit-nature, I will provide more details and tests for external users and, of course, any external help/contribution is more than welcome!(e.g. consider Wilson and not staggered fermions)

In conclusion, I think being able to have the expression of the QED Hamiltonian in qiskit, can be useful for a lot of researchers that are interested in LGT and in studying them with quantum technologies.

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[mrossinek]

Thank you for opening this PR and for considering open-sourcing your work!

I did not dive into the code yet, but read your description above. This triggered the following thoughts which I will write down in no particular order:

• I think it would be best if your code would re-use the HyberCubicLattice rather than implement its own lattice generator class
• reading your description, it sounds like you hard-coded the mapping from second-quantization to qubit-space. It would be better if your code would rely on the qiskit_nature.second_q.mappers module for this task. First proposal for the MixedMapper and MixedOp #1188 might be relevant for this.
• I also think that this code would be best aligned with Qiskit Nature if the Hamiltonian interface were followed, in the sense that it acts as a generator of some SparseLabelOp (or possible MixedOp; see previously linked PR).

These are some implementation-specific thoughts which come to mind reading your description. These may or may not require a significant development effort as I did not inspect your code itself as of yet.

Overall, I think this would be a great addition to Qiskit Nature! See also ElePT#2 for a possibly related prior work in this direction.
#556 also suggested an addition like this and has two references that might of interest here.

Seeing that this PR adds more than 3000 lines of code in its current form and given my comments above, do you think we can split this implementation into multiple smaller (and thereby easier-to-review) additions to Qiskit Nature?
Will #1188 be relevant to this at all? If so, it might make sense to finalize that first, and revisit this implementation based on that work, after it has been merged.

Please let me know what you think 🙂

[ariannacrippa]

Hi, thanks for the quick reply. Here are my comments:

• I did not use the HyberCubicLattice because I wanted to be more specific and have more features that I can exploit for defining the Hamiltonian and representing the lattice. If you look at the notebook that I added you can see that I am drawing the lattice by considering different colors for sites (so I can distinguish between particles and antiparticles), by also defining the dynamical and fixed gauge fields, when Gauss law is applied and the positions of static charges, if one is interested in studying them.

-I also did not consider the Jordan Wigner mapper on qiskit because there is no phase in the code in qiskit and also the JW choice influences the definition and thus the value of the dynamical charges in the Hamiltonian.

-Concerning the last comment, I did not really understand what the idea behind is.

I understand that the code is quite long, so I agree that maybe it is better to split the additions, in case.

Of course, any comment/observation is more than welcome, so let me know what you think.

[mrossinek]

Sorry for the late response. There really is a lot of pieces in this PR and in the current form of adding a "dangling" class (in the sense that it is not tied to any other parts of Qiskit Nature) combined with a number of Jupyter notebook inside of a builtin module, this is simply not possible/compatible with Qiskit Nature as such.

That said, I think there are some valuable pieces which would need to be analyzed one-by-one with more appropriately sized PRs to add the functionality that they provide into the corresponding parts of Qiskit Nature.

I think that ElePT#2 is possibly related and it set out quite a good start in what is aligned with Qiskit Nature (at the time; it would need some updates to be integrated today; but that requires #1188 to be finalized and merged, first). Let me try to break down a few parts that I see here:

• using the HyperCubicLattice should be possible. Either directly, since you can store arbitrary information on each node of the lattice (since this is just using a PyGraph under the hood); or you make a specialized subclass of the HyperCubicLattice if your use case warrants that. The point being: we should not duplicate so much code and stick to the interfaces of Qiskit Nature which ensures that users who are familiar with what is already there, will have minimal trouble learning to use the new parts which we may add.
• I think I might be glossing over some details with the mapper here, but if a specific mapper has wide-reaching affects on parameter choices or the definition of the problem, I would question how transferable/applicable to other inputs the code truely is. I am also not 100% sure I know what phase is missing but that is probably because I am not familiar with this particular application. That said, if such a phase were added (assuming that this is compatible with all existing use cases) would this allow you to leverage the existing JordanWignerMapper? This could be one PR on its own once we discuss the exact change that this entails.
• the last comment was regarding the Hamiltonian interface. This is the main thing: this new feature needs to be integrated into Qiskit Nature as a Python library. We cannot add a jupyter notebook like this. Instead, we need to extract clean class implementation which fit with the rest of Qiskit Nature, and that means it should follow the class interfaces that are set out by the module. You can see an example in LatticeGaugeTheory (WIP) ElePT/qiskit-nature#2 where the WilsonModel implements the LatticeModel interface (although not exactly what things look like today, this gives you an idea of what I mean). You can also see other examples of this directly in Qiskit Nature by taking a look at any of the files in this module: https://github.com/qiskit-community/qiskit-nature/tree/main/qiskit_nature/second_q/hamiltonians

To summarize: since this PR cannot be merged in its current form, why don't we switch over to #556 to try and identify the key features that would be required inside of Qiskit Nature for your application. I will not be able to work on this much myself, but I am happy to discuss how/where things could fit and point you in the right direction with additional explanation of how things fit together.

[ariannacrippa]

I am sorry to not come back to you. It seems that considering adding the entire Hamiltonian code is quite costly. Maybe I can consider to add a small part of it or work on the existing versions on qiskit and apply changes there. What do you think?