juliaphysics / lattices.jl Goto Github PK

Just to let you know I think I should update the README to warn that this package is still at very early design stage.

bd828e3

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.

I wonder if the approach taken in this package "scales" to larger, complex, higher-dimensional lattices. Currently, there is no explicit unit cell concept, all sites are at integer positions (#10) and boundary conditions are implemented explicitly.

Perhaps, we should try implementing a complex lattice, where generating all the lattice iterators is non-trivial to convince ourselves that the abstract concepts hold in such a case. What do you think? @mbeach42 @Roger-luo

(EDIT: We could consider the monster lattice (10,3,c), for example: https://github.com/janattig/LatPhysUnitcellLibrary.jl/blob/master/src/unitcells_3d/10_3_c.jl)

Now that the neighbors iterator is set-up, we can define the bonds iterator

For now we'll focus just on 2-local bonds, but should at least leave the implementation general enough to implement n-local bonds in the future.

I think in a lot places it is called open boundary instead of fixed? But it might be too general to use Open as the name of boundary type.

and I'm wondering if the default boundary condition should be open?

2018-12-26 Updated

Use CartesianIndex instead of Tuple, this will make the returned site position became real indices while indexing real lattice configurations.

• type HyperRect

• sites iterator

• neighbors (aka surround)

  • periodic
  • open (fixed) boundary

• edges

Square should work for the following case:

I don't understand the surround concept. How is it different from neighbors?

I think a static lattice size type parameters can make the compiler unhappy (type polution). Is there any paractical using case that we can get significant performance gain by making it static?

e.g.

I'd like to move discussions around the new lattice design here. So we have something to keep track of.

a few things need to be revised after the move:

• change README
• check CI & doc builds

Update: link to docs is broken...somehow

Currently, we are implicitly assuming a lattice constant a=1.

Would allow users to index an array using the Coordinate type

Naive-but-General Nearest Neighbor Strategy:

• Generate all lattice vectors with maximum component = k
• Compute their lengths wrt some norm
  • for a square lattice, this is the euclidean norm
  • for a rectangular lattice we'd need to take the lattice constants into account
  • other lattices (hexagon, triangular, etc) would involve different metrics
• Select all lattice vectors which correspond to the k smallest (unique) norms

There's optimizations which can be made at each step which can reduce the search space, but I think the asymptotic time complexity can't really get much better than O(k^d) where d is the number of dimensions in the lattice.

It's therefore a good idea to make use of memoization when dealing with translation vectors. I'm thinking of making a function precompute_translation_vectors!(lattice, maximum_k) which computes all the k'th Nearest Neighbor translation vectors up to k = maximum_k and then caches those for later use in a dictionary stored within the lattice struct. I'll require this to be explicitly called for now: neighbors will error out in most cases if you haven't already called the precompute function beforehand, but we can streamline this a bit later.

It's written with an a.

This is useful when we want the iterated configuration satisfy certain property, e.g sum equals to 0 (for Spin)

Iterator API

• surround -> neighbors

Iterator wrapper type

Currently, when use sites/edges/etc. an iterator without any information of the lattice will be returned. This makes it less general and may cause type privacy while supporting the follow interface (useful when generating couplings):

ltc = Chain(10)
rand(Float64, edges(ltc))

ltc = Square(10, 10)
rand(edges(ltc))

We can have a wrapper iterator type for LatticeIterators

struct LatticeIterator{LTC, Iterator}
     lattice::LTC
     it::Iterator
end

and it will directly forward Base.iterate, Base.length, Base.size, etc. to LatticeIterator.it, but we can define rand(::Type{T}, ltc::LatticeIterator) = rand(T, size(ltc)) in general without any type privacy.

Boundary Conditions

• all boundary condition will be defined inside module Boundary
• Fixed -> Boundary.Open
• Periodic -> Boundary.Periodic
• boundary condition will has alias (NOTE: alias are always the lower case of the type name)
• boundary keyword can use symbols

This will allow the follow syntax:

# module Boundary is exported, but not used
using Lattices

ltc = Chain(10; boundary=:open)
ltc = Chain(10; boundary=:periodic)

@mbeach42 @crstnbr comments?

@JuliaRegistrator register

Simplest use case for this would be creating a lattice on a cylinder.

I can help out with this if needed, but it seems like there's a big refactoring going on at the moment.