Introduction
During the parallelisation of MEF++ we needed to develop a method for partitioning MEF++ meshes (.mail files), using the Parmetis library.

We realized that the partitioning process is and will remain time consuming (not so much because of Parmetis' performance but mostly because of algorithm requirements in the data preparation phase). As a consequence, it became useful to provide tools for saving and retrieving a MEF++ mesh partition, once created.

Another reason for willing to preserve partitioning of a MEF++ mesh is being able to provide invariant initial data for numeric experiments with requirements of reproductibility.

As a consequence, partitions of MEF++ meshes are presently written automatically upon creation, in files having as name the name of the partitioned mesh and a double extension: <name>.<np>.part (np = number of processes). E.g. feracheval.8.part is the partition file of a mesh that was named feracheval for a parallel computation of 8 processes.

Format description
The format of a .part file follows closely the format of a .mail file. A brief example is given below:
17 PartitionMaillage
11 Version 1.0
1006
2

191
1 0
1 0
1 0
1 0
1 0
1 0
1 0
1 0
1 0
2 0 1
2 0 1
........
7 PartitionMaillage

The ordered list below gives a detailed description of each line in the .part file. This description is only given for reference. The authoritative information is to be found in the MEF++ code that implements the .part files reading and writing, in the MaillageUtil library.

  • Line 1: opening name of the object class. Mandatory value: 17 PartitionMaillage;
  • Line 2: version number;
  • Line 3: corresponding mesh identifier. Has to be identic with the 3rd line in the corresponding .mail file. This is a loosely coupled insurance that the .part file is read together with the correct .mail file upon partition loading. The coupling is loose because this identifier is not unique for a given mesh and because it is possible that otherwise perfectly valid .mail/.part pairs could have different identifiers;
  • Line 4: number of processes which composed the computing task that generated this .part file;
  • Line 5: empty;
  • Line 6: number of nodes in the mesh NS;
  • Line 7 to Line 7+NS: one line per node, containing the partitioning info of each node. The format of a line is:
    NP NoM NoS_1 ... NoS_(NP-1).
    The first integer on the line gives the number of processes in the partition. The second is the index of the master process which that node belongs to (on which the node is local). The third integer and next until the end, are the indexes of the other processes which contain this same node, but on which the node is non-local. There must be as many slave process indices as indicated by the NP-1;
  • Line 7+NS+1: empty;
  • Line 7+NS+2: number of edges NE;
  • Line 7+NS+2+1 to Line 7+NS+2+NE: one line per edge, containing the partitioning info for each edge. Same format as for nodes;
  • Line 7+NS+2+NE+1: empty;
  • Line 7+NS+2+NE+2: number of faces NF;
  • Line 7+NS+2+NE+2+1 to Line 7+NS+2+NE+2+NF: one line per face, containing the partitioning info for each face. Same format as for nodes;
  • Line 7+NS+2+NE+2+NF+1: empty;
  • Line 7+NS+2+NE+2+NF+2: number of 1D elements N1DE;
  • Line 7+NS+2+NE+2+NF+2+1 to Line 7+NS+2+NE+2+NF+2+N1DE: one line per 1D element, containing the partitioning info for each 1D element. Same format as for nodes;
  • the last 3 items of the format are repeated for triangle, quad, tetra, hexa and triangular prism, in this order.
  • Line before last: empty:
  • Line last: closing name of the object class. Mandatory value: 17 PartitionMaillage;