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

Helical/Snake Boundaries #28

Open
emerali opened this issue Sep 17, 2020 · 7 comments
Open

Helical/Snake Boundaries #28

emerali opened this issue Sep 17, 2020 · 7 comments
Labels
discussion This issue requires some discussion

Comments

@emerali
Copy link
Collaborator

emerali commented Sep 17, 2020

Helical BCs are a fast approximation to Periodic BCs which make use of the linear storage of arrays to scrape off some computational overhead associated with accessing N-dimensional arrays. See Chapter 13 of Newman and Barkema's book: "Monte Carlo Methods in Statistical Physics" for an overview, or Wikipedia for a very brief summary of the HyperCubic case. People familiar with DMRG will recognize this as something similar to the "Snake" boundary condition.

It is, however, difficult to implement in a clean way:

  • For one, there isn't an easy way to mix Helical BCs with other boundary conditions since it's a "global" boundary condition, as opposed to Periodic or Open BCs which can be applied to each dimension independently (though you probably don't want to mix Helical with anything else anyway).
  • Methods dealing with Helical BCs will treat lattice sites as single integers, while methods for Open/Periodic BCs treat lattice sites a Coordinates. This isn't a type-stability issue (since we're dispatching on the BC type anyway), more of a user-experience one.
  • When using Helical BCs we often only want to specify the number of sites in a lattice directly, however, we don't necessarily set this number to be equal to the product of the dimensions. For example, one could represent a 2D square lattice of size 5x4 with only 18 sites. This conflicts with the fact that we're storing the lengths of each dimension separately in the Lattice struct.

So my question is: will people use Helical BCs? Please comment below if you believe you will.

@emerali emerali added the discussion This issue requires some discussion label Sep 17, 2020
@Roger-luo
Copy link
Collaborator

So I think this only makes sense for square/rectangle lattice IIUC?

I'm actually thinking about maybe we can just flatten the configuration array for helical boundaries when someone needs it?

@emerali
Copy link
Collaborator Author

emerali commented Sep 17, 2020

it's applicable for triangular/hexagonal/kagome as well

probably also for higher dimensional bravais lattices, though i don't know how it'd be implemented in those cases

@dpsanders
Copy link

I didn't know about this package -- nice!
I learnt about helical bc's from the Newman book and used them a couple of times if I remember correctly.

It seems like something that a physics lattices package should ideally have, and certainly should be possible to do.

@Roger-luo
Copy link
Collaborator

Roger-luo commented Sep 17, 2020

@dpsanders would you mind showing some more specific case how that was used so maybe we can have a better idea on how to hook it in?
I think currently we are more considering whether making it a special boundary condition type or just let users handle it using some other tools.

It seems like something that a physics lattices package should ideally have, and certainly should be possible to do.

True, I'm more thinking about how to make it compatible with Open and Periodic boundaries, since we need to special-case it everywhere at the moment, I think it is also
why @emerali opened this issue originally...

it's applicable for triangular/hexagonal/kagome as well

I think for the 2D case, Helical boundaries can always be implied by flattening the final configuration/iterator our lattice types generates, e.g if we go column-wise, the sites and edges iterator will return a Matrix/iterator of 2 dims in 2D case, then pushing these items into a Vector will imply the Helical boundary condition.

@emerali
Copy link
Collaborator Author

emerali commented Sep 17, 2020

i'm not quite sure what you mean by flattening?

@Roger-luo
Copy link
Collaborator

e.g when you get the sites of a square lattice, by flattening it to a Vector, you automatically get the Helical boundary. Or if you have a periodic boundary for the square lattice, since Julia's iterator has a shape, it will return a matrix of edges if we collect it, then flatten this matrix to vector will give Helical boundary. But I could be wrong.

@emerali
Copy link
Collaborator Author

emerali commented Sep 20, 2020

Or if you have a periodic boundary for the square lattice, since Julia's iterator has a shape, it will return a matrix of edges if we collect it, then flatten this matrix to vector will give Helical boundary.

not quite, the nearest neighbors for periodic and helical boundaries are fairly different, so you can't get helical BCs from PBC

Consider an L x L square lattice, we'll use (i,j) to denote the cartesian index, and l to denote the linear index. I'll use row-major and 0-based indexing here, since that's what they use in the textbook, but when we implement this we'll of course need to use column-major and 1-based indexing.

The (1st) nearest neighbors for PBC are (cartesian indexes on the left, and the corresponding linear index on the right):
(1) (i +/- 1 mod L, j) -> (i +/- mod L) * L + j
(2) (i, j +/- 1 mod L) -> i*L + (j +/- mod L)

In Helical BCs the nearest neighbors are:
(3) (l +/- 1) mod L*L
(4) (l +/- L) mod L*L

you can show that (1) and (4) are the same, meaning (in the row-major case) the neighbours in the vertical direction for PBC and HBC are the same, but not the neighbours in the horizontal direction (it's the opposite in the column-major case).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion This issue requires some discussion
Projects
None yet
Development

No branches or pull requests

3 participants