debugging handy implementation

[pkozlows]

I'm confused as to what is being meant in the instructions manual here?

As suggested in the first step, I have already made functions that are dealing with the individual FCI strings, and now I am working with the whole H**C operation. Debugging using my original diagonalization via NumPy would be helpful, but I'm not sure how I would do it. With my original NumPy diagonalization, I was using my whole Hamiltonian matrix that I generated to transform my set of inputted CI vectors, but now I am not generating an entire Hamiltonian matrix. Do I just want to compare my original CI vector transformation using the Hamiltonian matrix NumPy implementation with my new handy one, or do I also need to continue to step with the preconditioner involved to observe its effect? let me know if I an not making enough sense here. And then in the second step in the attached image, what do they mean by evaluating Hamiltonian matrix elements using FCI strings? But this, are they meaning to check whether something like the Brillouin theorem, where <hf_gs|H|single_difference_from_ground_state> = 0, using FCI strings (didn't I already do something of this kind when I was avoiding using the Slater-Condon rules or is this something different?).

[pkozlows]

I recognize that my previous question was pretty incoherent and so probably didn't deserve much of a response. I am slowly beginning to understand elements of the handy algorithm more now, debugging my new implementation would certainly be helpful using what I have done but I'm not sure how I would do it. What exactly is meant in the first portion of the image that my original implementation using diagonalization, with numpy will be helpful for debugging? And then is the part about evaluating Hamiltonian matrix elements using the FCI strings just the same as the unit tests (HF energy...brillouins thm for <hf_gs|H|single _replacement_from_hfgs>=0) that I was doing in my original Slater, implementation. If you are able to recall I switch to an FCI string based implementation of the determinants when evaluating the Slater rules. In the end that helped me get a correct FCI energy. Or are what day referring to somewhat different.

[Walter-Feng]

numpy -> numpy.eigs It's just making sure that the eigenvalues you get from Davidson diagonalization correspond to numpy's diagonalization.

I would guess what you implemented is what is desired here.

[pkozlows]

I am not getting the following assert statement to pass, and I'm not sure why. https://github.com/pkozlows/fci/blob/053927a21b23ab1ba401704a439e930d5d6f2d80/timed_testing.py#L21 from reading the paper, shouldn't my handy function just be performing the same task as the hamiltonian matrix multiplication:

[pkozlows]

There is one point that I'm still failing to understand, and I want to better understand this point before I implement the preconditioner to be able to generate a new configuration interaction vector in the Davidson algorithm. I imagine that when I get to the latter part, I will be able to debug my program using my previous NumPy implementation, but I am not there yet. Should the Handy Transformer be performing the same exact task as the Hamiltonian matrix multiplication mentioned above? If not, why is this the case?

[Walter-Feng]

You should be expecting the same result from Handy transformer and the Full CI matrix transformer. Otherwise you are getting different eigensystems.

[pkozlows]

Let's say that you are Patrick, and you are a little sad that your handy transformer is not working. To start with, my understanding is that the first "unit test" for the handy implementation should be getting the same result from my handy transformer and my full CI matrix transformer on a CI vector outputted by NumPy, by checking that the norm of the two vectors are equal. I have been stuck on this "asserting" for a while now. I know that you definitely do not know exactly the issues that I am dealing with, but I was just hoping to see if you would be able to provide some inspiration for how I could go about this. I am kind of running out of ideas, so I was hoping you could inject some new ones :) I don't know if the same concepts apply here, but in my original implementation, you were saying that I should think about the spins, range of summation, and the face factor and that was really where I needed to look. Is there something like that here?

[Walter-Feng]

Reading the article, I have two new concepts - one is relatively technical, which is the address array, one is relatively physical, which is one-particle excitation matrix. Between these two the address array is easier to debug, as I can just need to check the address and the determinants are mutually mapped.

Then I would be thinking, why is address array important. Looking into the name of one-particle excitation matrix, it would actually be sparse - the total number of determinants that can be counted as a single excitation from a particular determinant is super limited. So I would only need to iterate over determinants instead of a nested for loop, and each determinant should point to only a few determinants that correspond to non-trivial elements in the one-particle excitation matrix.

But recalling the practice of core hamiltonian (one-body operator), it's not that simply easy - there is spin, there is "diagonal element" ( <i | H | i> ), there is sign problem. I need to double check what one-particle excitation matrix actually means, how that can be attributed to a Full-CI matrix, then I need to make sure the address array is correctly reflected in generating this matrix.

If I prepared one-particle excitation matrix and address array correctly, then it looks to me that all the remainder is tensor contraction, that should not be causing any problems. If I have any issues, it can only be either address array or one-particle excitation matrix.