4
2
5
1
6
3
10
11
7
8
9
1
3
8
24
1
4
000
4
2
(= 5)
8
(= 11)
4
(= 7)
3
(= 6)
4
7
(= 10)
2
(= 5)
8
(= 11)
1
(= 4)
4
5
(= 8)
6
(= 9)
3
(= 6)
4
(= 7)
1
2
2
2
1
2
1
3
2
1
3
1
3
1
3
1
2
2
2
1
Figure 5: Mesh file representing three square elements, with unity vertex and edge
weights. Elements are defined before nodes, and numbering of the underlying graph
starts from 1. The left part of the figure shows the mesh representation in memory,
with consecutive element and node indices. The right part of the figure shows
the contents of the file, with both element and node numberings starting from 1,
the minimum of the element and node base values. Corresponding node indices in
memory are shown in parentheses for the sake of comprehension.
to the graph dimensionality.
Vertices can be stored in any order in the file. Moreover, a geometry file can have
more coordinate data than there are vertices in the associated graph or mesh file;
only coordinates the labels of which match labels of graph or mesh vertices will be
taken into account. This feature allows all subgraphs of a given graph or mesh to
share the same geometry file, provided that graph vertex labels remain unchanged.
For example, Figure 6 shows the contents of the 3D geometry file associated with
the graph of Figure 4.
3
8
0
0.0
0.0
0.0
1
0.0
0.0
1.0
2
0.0
1.0
0.0
3
0.0
1.0
1.0
4
1.0
0.0
0.0
5
1.0
0.0
1.0
6
1.0
1.0
0.0
7
1.0
1.0
1.0
Figure 6: Geometry file associated with the graph file of Figure 4.
5.4
Target files
Target files describe the architectures onto which source graphs are mapped. Instead
of containing the structure of the target graph itself, as source graph files do, target
files define how target graphs are bipartitioned and give the distances between all
pairs of vertices (that is, processors). Keeping the bipartitioning information within
target files avoids recomputing it every time a target architecture is used. We are
22
