-
Notifications
You must be signed in to change notification settings - Fork 32
Implement AlternativeSpinHamiltonian for Issue #179 - #186
Implement AlternativeSpinHamiltonian for Issue #179 #186smandal21-pixel wants to merge 10 commits into
Conversation
...dded pytest suite.
for more information, see https://pre-commit.ci
smandal21-pixel
commented
Apr 2, 2026
Note for reviewers: I am aware this Draft PR slightly exceeds the recommended 3 commits / 50 lines of code limit mentioned in the contributing guidelines. The extra lines are entirely due to the inclusion of the required pytest suite to verify the Heisenberg energy levels. I have kept the core logic as minimal as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to manually code spin operators, as we have introduced mapping from spin-operators to fermion creation/annihilation operators
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review and the guidance, @RichRick1! I completely understand. Since I was working from a ground-up approach, I missed that the spin-to-fermion mapping was already introduced.
I see the existing HamHeisenberg class in moha/hamiltonians.py. I will scrap my manual dense matrix generation and pivot to utilizing the built-in fermion creation/annihilation operators instead. Could you point me to the specific file/module where the spin-to-fermion mapping functions are stored so I can review them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Following up on my previous message—I’ve just reviewed the newly updated docs/spin.rst and the HamHeisenberg / HamIsing classes. I see that the library is already set up to handle these as one-body and two-body integrals. I am currently refactoring my implementation to remove the manual dense matrix Kronecker products and instead utilize the alpha/beta fermion mapping to generate the integral equivalents. This will ensure full compatibility with the existing moha solvers.
...onian into issue-179-spin-hamiltonians
...amHeisenberg and update test suite
smandal21-pixel
commented
Apr 28, 2026
Hi @RichRick1, I've pushed the final refactor. AlternativeSpinHamiltonian now inherits the fermion mapping directly from HamHeisenberg, fully bypassing the dense Kronecker products. I also resolved the merge conflicts and updated the test suite. All CI checks are passing green! Let me know if you need anything else before merging
ca729ae to
29128e5
Compare
for more information, see https://pre-commit.ci
smandal21-pixel
commented
May 15, 2026
Hi @RichRick1, I hope you're having a good week! I know things are probably settling down post-GSoC, but I just wanted to gently bump this PR whenever you have some free time to review it. The AlternativeSpinHamiltonian refactor is completely finished, merge conflicts are resolved, and all CI checks are green. Let me know if any further tweaks are needed!
Uh oh!
There was an error while loading. Please reload this page.
I have refactored the
AlternativeSpinHamiltonianto inherit directly fromHamHeisenberg. This allows the class to act as an adapter that maps custom spin topologies to the existing integral-based architecture, successfully avoiding dense Kronecker product constructions and leveraging the library's built-in fermion creation/annihilation operator mapping.Changes include:
Updated
AlternativeSpinHamiltonianto utilizeHamHeisenbergfor integral generation.Added a new
pytestsuite inmoha/test/test_alternative_spin.pyto verify site connectivity and integral tensor shapes.Ensured compatibility with downstream solvers by providing proper one-body and two-body integrals.
This is part of my GSoC 2026 application for Issue #179. All CI checks are passing.