Use simpler constructors for heavy hex lattice

[JoeyT1994]

Further update to Heavy Hex dynamics example by simplifying the graph construction procedure based on the new features in the PR ITensor/NamedGraphs.jl#37 in NamedGraphs.jl

Also fixed a few bugs in beliefpropagation.jl which cropped up in testing.

[codecov-commenter]

Codecov Report

Merging #109 (7d50eb3) into main (0f96a0a) will increase coverage by 0.14%.
The diff coverage is 100.00%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@            Coverage Diff             @@
##             main     #109      +/-   ##
==========================================
+ Coverage   78.41%   78.56%   +0.14%     
==========================================
  Files          65       65              
  Lines        3693     3695       +2     
==========================================
+ Hits         2896     2903       +7     
+ Misses        797      792       -5     

Files Changed	Coverage Δ
src/beliefpropagation/beliefpropagation.jl	92.75% <100.00%> (ø)

... and 2 files with indirect coverage changes

[mtfishman]

I think eagle_processor_graph would be a better name.

Also, I guess it is easy enough to make it generic to any numbers of loops:

function eagle_processor_graph(dims::Tuple)
  g = hexagonal_lattice_graph(dims)
  g = decorate_graph_edges(g)
  # Define new_x, new_Y
  add_vertices!(g, [(1, new_y), (new_x, 1)])
  add_edge!(g, (1, new_y - 1) => (1, new_y))
  add_edge!(g, (new_x, 2) => (new_x, 1))
end

eagle_processor_graph(dims::Integer...) = eagle_processor_graph(dims)

(I didn't work out what the dangling vertices should be called in general).

[mtfishman]

Ah, I guess I forgot that they refer to "Eagle" specifically as the 127 qubit version.

Maybe we could make a generic ibm_processor_graph(dims) function, and then define eagle_processor_graph() = ibm_processor_graph(3, 6). I suppose that relies on the processors of different sizes having dangling indices in the same generic location, but we could always modify that part as needed.

[mtfishman]

Also, the convention is usually that the dimensions are listed as (nrows, ncols), for example for matrices or grid graphs:

julia> randn(3, 6)
3×6 Matrix{Float64}:
 1.75374    0.733839  -2.31459   0.229901   0.38511    0.763495
 1.07339   -0.246599   1.71149   0.534501   1.16299    1.27957
 0.703778  -1.62359    0.095052  0.68742   -0.662432  -0.0861288

julia> t = ITensorNetwork(named_grid((3, 6)); link_space=2);

julia> @visualize t;
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀t(1, 6)⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀2⡰⠁⠈⠉t(1, 5)⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⡜⠀⠀⠀⠀⠀⠀⢀⠎⠉⠒⠢2⣀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀t(2, 6)⡀⠀⠀⢀2⠀⠀⠀⠀⠀t(1, 4)⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⢀2⠀⠀⠀⠀t(2, 5)⠀⠀⠀⠀⠀2⠃⠀⠀⠉2⠤⢄⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀t(3, 6)⠀⠀⠀2⠎⠀⠀⠈⠉2⠤⢄⡀⡰⠁⠀⠀⠀⠀⠀t(1, 3)⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠈⠑2⠤⣀⢀⠎⠀⠀⠀⠀⠀⠀t(2, 4)⠀⠀⠀⠀⠀2⠀⠀⠀⠀2t(1, 2)⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀t(3, 5)2⠀⠀⠀⠀2⠀⠀⠀⠀⠀2t(2, 3)⠀⠀⠀⠀⠀⢠⠃⠉⠒2⢄⡀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈t(3, 4)⠀⠀⠀⠀⠀⠀⡜⠈⠉⠒⠤2⡀⠀⠀⢠2⠀⠀⠀t(1, 1)⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠑⠒2⣀⠀⠀⢀2⠀⠀⠀⠀⠀t(2, 2)⠀⠀⠀⠀2⠁⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀t(3, 3)⠀⠀⠀⠀⠀2⠁⠀⠀⠈t(2, 1)⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉2⠢⠤⣀⡔⠁⠀⠀⠀⠀⠀⠀⡰⠁⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀t(3, 2)⣀⡀⠀⡔2⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀t(3, 1)⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 

Following that, shouldn't the dimensions of hexagonal_lattice_graph be switched? It seems like they are listed as (ncols, nrows).

[JoeyT1994]

Yeah good name for the function. I have made it a bit more generic and changed the name, although I think making the dangling vertices generic might not be needed as that graph doesn't have much meaning beyond the specific 3 x 6 IBM processor.

[JoeyT1994]

Yeah you're right that the rows and cols naming in hexagonal_lattice_graph should be switched (it names the vertices as (col, row) which is a mistake I made). But at the level here it is all symmetric (one could also call heavy_hex_lattice(6, 3) with appropriate vertex naming). It all just depends in which orientation you look at the processor as to what you define as a row/ a column.

[JoeyT1994]

Okay I see what you mean and they aren't the same. In it's current implementation that drawing of your corresponds to hexagonal_lattice_graph(6, 3) whereas the above pictures I sent are hexagonal_lattice_graph(3, 6).

Obviously that makes it seem like we have rows and columns swapped in the function arguments but if you look at everything from a 90 degree orientation then we actually have them correct. I.e.

is hexagonal_lattice_graph(3, 6)

[mtfishman]

Yeah, I agree we could have different interpretations of what the "rows" and "columns" of a hexagonal lattice mean, depending on the orientation we choose, and that would change what hexagonal_lattice_graph(nrows, ncolumns) means.

It seems like it is usually drawn how you just drew it in your last post, i.e. consistent with https://en.wikipedia.org/wiki/Hexagonal_lattice#Honeycomb_point_set and https://mathworld.wolfram.com/HexagonalGrid.html. So maybe we could go with that definition.

[mtfishman]

So with that definition, I guess the function in NamedGraphs.jl is fine? Or is there still a vertex naming issue, i.e. do the row and column labels of the vertices need to be switched?

[JoeyT1994]

Yeah that makes sense as I took the function from networkx which probably adopts the correct convention.
Nonetheless there is still a vertex naming issue in NamedGraphs.jl because I named the vertices as (col, row) instead of (row, col). Which I will make a PR to change.

[JoeyT1994]

Should be addressed in: ITensor/NamedGraphs.jl#38

[JoeyT1994]

Okay I implemented a more generic naming protocol and a way to determine the dangling indices. Now have functions for creating 3 of the named IBM processors, see:
https://www.oezratty.net/wordpress/wp-content/IBM-hex-lattice.png

[mtfishman]

Looks great, thanks! Nice that it is so simple to make these exotic lattices.