How do I organize these related indices into something that can be looked up efficiently in Rust?

Question

Background

In an algorithm called finite element method, a continuous region is discretized into repeated sections with consistent geometry, over which linked equations are formed based on the assumption of continuity between them.

In this case, I have chosen to divide a shape up into an arbitrary grid, and am now trying to connect the elements' values together as I iterate through the elements. Here is an example of the kind of grid I am talking about:

Indices

There are a bunch of related indices:

• The element index (teal numbers), linear, row-major, range 0..ROWS*2.
• The node index (brown numbers), linear, row-major, range 0..ROWS*COLS.
• The local element vertex index (lavender numbers), counter-clockwise by element, range 0..2.
• The coordinates of the actual point in space (stored with the element's struct, as well as the grid's struct)

Problem

In order to get to the next step in the algorithm, I need to iterate over each node and compute some sums of values indexed by local element indices and store them in another matrix. If, for example, I'm on node 8, my element lookup/access function is generically V(el_index, start_vertex, end_vertex), and my matrix of outputs is S(start_node, end_node):

1. S(8,8) = V(el_14, vert_1, vert_1) + V(el_15, vert_1, vert_1) + V(el_04, vert_0, vert_0) + V(el_03, vert_0, vert_0) + V(el_2, vert_2, vert_2) + V(el_13, vert_2, vert_2)
2. S(8,9) = V(el_15, vert_1, vert_2) + V(el_4, vert_0, vert_2)

and so on, for all of the connections (teal lines) from node 8. (The connections are symmetric, so once I compute S(7,8), I don't need to compute S(8,7).)

The problem is, the grid (and therefore everything else) is parameterized at runtime, so which node index + adjacency direction corresponds to which element index is dynamically determined. I need to tell the program, "Get me the element indices where the node index of vert_x is my current node index." That's the instruction that tells the program which element to access in V().

Is there a way I can relate these indices in a simple and transparent manner in Rust?

Attempts

1. I tried computing some simple arithmetic functions modulo the row stride of the node matrix, but the result is messy and hard to debug, as well as requiring verbose bounds checking.
2. I tried creating three HashMaps keyed by the different vertices of each triangular element, holding the values at each vertex, but the problem is that adjacent triangles share vertex numbers as well as spatial coordinates.
3. I considered keying a HashMap with multiple keys, but the Rust docs didn't say anything about a HashMap with multiple keys.

Answer 1

I think this is a possible workaround, but I hope there's something better:

Nest one HashMap in another as per this question, with the node index as the first key, the element index as the second key/first value, and the element itself as the second value.

So, the iteration can look like this:

1. Iterate through grid node index N
2. Get all elements with N as the first key

3. Note that the vertex indices and (relative) element indices have the following patterns, depending on where you number from:

   Node index numbering beginning from matrix top-left (usual in this programming domain):

   | Element (index ordinal) | Vertex |
   |-------------------------|--------|
   | 0 (min)                 | 1      |
   | 1                       | 2      |
   | 2                       | 1      |
   | 3                       | 2      |
   | 4                       | 0      |
   | 5                       | 0      |
   

   Node index numbering beginning as picture, from lower-left:

   | Element (index ordinal) | Vertex |
   |-------------------------|--------|
   | 0 (min)                 | 2      |
   | 1                       | 0      |
   | 2                       | 0      |
   | 3                       | 2      |
   | 4                       | 1      |
   | 5                       | 1      |
   

Since you can hardcode the relative order of elements like this, it might be better to use a HashMap<usize, Vec<Element>>, or even HashMap<usize, [Element; 6]>.

This method brings up the question of how to relate node index to element indices dynamically. How do you know which elements to insert into that HashMap? One way to accomplish this is to record the nodes the element vertices correspond to in the element struct as well, in the same order.

At that point, you can compute a list like adjacent_elements as you iterate through the matrix, and use the above patterns to figure out what to access (sadly, with bounds checking).