theochem / modelhamiltonian Goto Github PK

@gabrielasd we can use https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.load_npz.html this function for load npz sparse matrix and this https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.save_npz.html function for saving npz sparse matrix

It might be good to add wrap of these function to the the utils.py file for saving/loading not the entire hamiltonian, but one body/ two body terms of it

Packaging guide is here

It would be a good idea to support input from command line.
We can do this by leveraging .toml files
@adsrichards has already made a pull request, however all the existing models needs to be
supported

ToDo:

• Support CLI
• #84

We need to be able to

• parse atom types
• assign appropriate α and β values based on Rauk's atom types (attached, page 94).
• compute appropriate α and β values using distance/overlap.

Mulliken-1949-Formulas-and-numerical-tables-for-o.pdf
simple-hckel-molecular-orbital-theory.pdf

According to this paper the per-site ground-state energy at half-filling can be written as a function of U:

However, the ground state for the two-site Hubbard model can be solved directly and the ground state for half filing band is written as

The problem

It turns out, that if I run the code to check the values obtained by these formulas are different.

So expression 1 is:
-1.04036865

Expression 2:
-1.561552812

Results obtained by calculating hamiltonian via my code and further solving with PyCI
-1.56155281

In addition to this, when I test results for a 3, 4 ... n site 1-d chain using hubbard model results should be in agreement with the expression 1, but they aren't :(
Overall it's clear that something is wrong with the interpretation of using expression 1. Even though the 2-site Hubbard model is tested already, I can't test it for the 1-d chain, because I'm not sure if there is a problem with a code or it's just not the right case for using expression 1
@PaulWAyers any ideas on how can I test it?

I added a sphinx-doc build to the repo. Currently, github-pages just takes the README.md from the main branch. We can change this to have it build and deploy the sphinx website to github-pages instead, and we should do this.

@gabrielasd @AYSE-GOCER so basically we are working with this and this methods. You can use my garbage-like code
This paper might be helpful

We need to support saving electron integrals as npz files where user gets e0, h1 and h2 electron integrals.
Method can be invoked by calling ham.savez('<filename.npz>')

A preliminary specification for the API of the Huckel Hamiltonian, together with basic scientific background, has been uploaded.

See html. There is also a markdown version of this document.

For some reason, for the general XXZ Heisenberg model we sometimes can't get the same result in energy, as proposed in papers. First of all we need to figure out if authors using different definition of one-/two- electron integrals to solve FCI (such as factor of 1/2 in front of 2 electron integral, or there is something else); or there is an issue with our code.

This is a good starting paper to test our code. Authors provide exact solution of the Bethe ansatz (p. 24). It would be interesting to see if our code converges in the infinite limit to the same answer.

Maybe we can wrap the one and two electron integrals, so it's supported by triqs. Specifically, we can interface to this function: https://triqs.github.io/triqs/latest/documentation/python_api/triqs.operators.util.hamiltonians.h_int_slater.html#triqs.operators.util.hamiltonians.h_int_slater

One way of doing it is wrapping 1 electron integral into the two electron integrals, using outer product:

$$V_{I, j, k, l} = \hat{h} \otimes I + I \otimes \hat{h} + v_{i,j,k,l}$$

This repository uses pre-commit hooks for upstream commit validation, but this has not been included in the README.md or requirement.txt files.
It can be frustrating for any beginner contributor to see some github workflow check fails because of pre-commit.

• Steps to reproduce the issues:
  Make a Pull request to this repo without configuring pre-commit will throw errors in gihub workflows.
  

I suggest we have a small section on how to install pre-commit and get started with this project.

1. We need a function that convert a one and two body integral into anti-symmetrize for two body integral
   @gabrielasd has this function
   @PaulWAyers can help with math

Description

Improve API and tests and code utilities of the existing Model Hamiltonian package.

📚 Package Description and Impact

In many cases, the true many-electron Hamiltonian is intractable to solve, so model Hamiltonians that capture key features of the physicochemical system qualitatively. Classic examples include the (extended) Hubbard, Ising, and Heisenberg model Hamiltonians. The goal of the package is to build a framework for constructing Model Hamiltonians and outputting them into a format that is conducive to traditional packages for solving the quantum many-body problem.

👷 What will you do?

In our group we have already implemented API for generating occupation- and spin- based Hamiltonians. However, there are other type of so-called occupation-and-spin based hamiltonians that play a crucial role in research. Your main goal would be to implement these types of model Hamiltonins. Fear not, contributor, you don’t need to know all the frustrating details of quantum chemistry.

🏁 Expected Outcomes

1. Implement dictionary-base database to integrate some standard constants that describes various atoms and connectivity types between them
2. Create an API that integrates together existing pieces for building occupation- and spin- based hamiltonians.
3. Write tests for implemented API.
4. Code utilities to output model Hamiltonians into formats conducive to external programs, including FCIDump and Triqs.

🙋 Mentors

Inputs to a Model Hamiltonian instance can be arbitrary, so I won't worry about those now.

Outputs are well-defined; one and two -particle integrals, and overlaps, in some file format (or in memory as an array?).

I think the best way to implement this is to have functions for outputting results in the following formats:
FCIDUMP
dense arrays
sparse arrays
whatever else we can think of
(other Python APIs, like PySCF? <- my idea)

These should be free functions, which can use methods of our Model Hamiltonian objects, written according to a well-defined interface, to generate the appropriate one or two -particle integral entries when writing the file/array. The interface should also allow us to determine the symmetry of the integrals and write them according to that (if the format supports it... FCIDUMP supports it, dense arrays don't, etc).

Hamiltonian types themselves can be written with the appropriate class hierarchy: PPP -> Hubbard -> Ising, or however it goes.

The important part is, the abstraction should go:
output writer functions
<--(used by)-- HamiltonianInterface
<--(subclass)-- SpecificHamiltonianSuperclass
<--(subclass)-- SpecificHamiltonianSubclass

The Python abc library can be used to write the Hamiltonian interface.

This would then allow us enough separation to split the work between writing output types and developing specific model Hamiltonians.

Anyone else want to comment on the API?

Few hamiltonians can be inherited from XXZ Heisenberg model:

• Ising model
• Richards-Gaudin model

For twoelectronmatrix
both of u_matrix and v_matrix
Used to construct it
But v_matrix will over write u matrix
But they must added
So I think instead of
two_electron_matrix[I,j]=v_ij
Must be
two_electron_matrix[I,j]+=v_ij

1. Create function called reduce_sym(integral, current_sym)
   So it should duplicate pairs of indices to a "None" symmetry format

We can support chat gpt-like input from user.
To eliminate hallucinations, we can map input from user such as "generate Hubbard model hamiltonian with U = 1 and t = 0.5 and save it to fcidump file with the name "Hubbard.fcidump"" to the .toml script with specific keywords.
Here is the way to integrate ChatGPT into the python code

If we want to include this functionality in the paper, we need to:

• #82

What types of output should we support?

1. 1- and 2-electron integrals as numpy arrays. (Should we support sparse formats?).
2. 1- and 2-electron integrals with a wrapper from IOData to generate FCIDUMP. (IODATA object -> FCIDUMP)
3. what sorts of formats to support other (non-electronic-structure-theory) codes.

These functions, which do not use self or reference the parent object, should probably be free functions in utils, and then added to __init__.py.

So far there are implemented (not int the best way):

1. PPP Hamiltonian (superclass)
2. Hubbard Hamiltonian (child class)
3. Huckel Hamiltonian (child class)

The main method is get_hamilton which returns zero, one and two body integrals as Numpy arrays.

Problems appears when testing an existing code. So far, there are couple of tests.

1. lTwo site Hubbard model which works great and available as test_1
2. According to this paper the per-site ground-state energy at half-filling can be written as a function of U:
   
   The values of this expression is -1.04036865, however proposed code doesn't return this answer.
   A good idea is test the same half-filling band but with more sites.

All code is available here: https://github.com/theochem/ModelHamiltonian/blob/upd/upd/Huckel_Hamiltonian.py

It seems like conversion of 2-body term from spinorbitals to spatial orbitals ends up adding values of alpha and beta spinors.
The problem is that such behaviour is inconsistent with the conversion of 1 electron integral to spatial basis -- instead of adding values of alpha and beta spinors, it returns just alpha part.

• check the behaviour of the to_spatial method in the api.py file. Make sure that return not the sum of spinors, but average.