Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable interaction ranges that coincide with lattice periodicity #8

Open
arayyan0 opened this issue Oct 25, 2022 · 3 comments
Open
Labels
enhancement New feature or request

Comments

@arayyan0
Copy link

While using SpinMC.jl to study a ferromagnetic system, I found a bug in the trivial case of a one-site cluster, that is, one basis site in one primitive unit cell. Let there be zero onsite or field interactions, but allow for a finite two-spin interaction. The function getEnergy() in Spin.jl initializes an energy of value 0.0 on Line 16 but never updates this value on Line 26; this is because site > interactionSites[i] can never evaluate to true for a one-site cluster, as both sides have the value 1.

I believe this restriction is to avoid double-counting each bond's energy contribution. One fix could be to remove this restriction, sum over all sites, and divide by two.

@fbuessen
Copy link
Owner

Good catch, thanks! It shouldn't have been possible to instantiate a lattice with spin self-interactions in the first place.
A check to prevent this from happening already existed for on-site interactions, but the check overlooked cases in which self-interaction is induced by seemingly non-local terms that are mapped back by periodic boundary conditions.
I have added the extra check in b7d4dd6.

The problem with self-interactions is that they result in quadratic contributions to the energy change upon updating the spin configuration -- however, the getEnergyDifference() function in Spin.jl that is used for Monte Carlo sampling neglects such terms to increase performance.

@arayyan0
Copy link
Author

Thanks for the quick reply. However, the modification to Line 25 of Lattice.jl prevents one from constructing certain clusters. For example, consider a cluster consisting of one basis site per unit cell, with linear dimensions L = (2, 1, 2). Introduce a two-spin interaction with offset = (0, 1, 0); then b1 == b2 && offset .% L == Tuple(zeros(D)) evaluates to true, and the lattice is not constructed.

I think it would be beneficial to allow for spin self-interactions via periodic boundary conditions so that one has the freedom to construct lattices that are "short" in one direction without modifying the form of the interactions. For example, one may wish to study an incommensurate magnetic order by considering a long cluster in one linear dimension with L=(1, 3, 30). Another example is if one would like to perform a linear spin wave analysis of a Monte Carlo run at finite temperature, where one analyzes a cluster of size equal to the magnetic unit cell (which can be as small as one site per atom).

@fbuessen
Copy link
Owner

While currently not possible in the naive way, there is a workaround for your use case: For a small cluster, you could manually replace any two-spin interaction whose interaction range coincides with the periodicity of the lattice with explicitly local interactions, using the setInteractionOnsite!(unitcell, b, M) command. The latter adds a local interaction $S_b \cdot M \cdot S_b$ to basis site $b$ for some interaction matrix $M$. Local interactions added in this way are treated differently in order to properly account for the quadratic energy terms.

It would, of course, be nice to make this replacement automatically upon lattice instantiation.

@fbuessen fbuessen reopened this Oct 26, 2022
@fbuessen fbuessen added the enhancement New feature or request label Oct 26, 2022
@fbuessen fbuessen changed the title Edge case: getEnergy() returns 0 for a 1-site cluster Enable interaction ranges that coincide with lattice periodicity Oct 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants