This is an optional file which can be used in conjunction with models which have rotational or translational computational symmetry (or periodic boundary conditions). It is invoked in the GEOMETRY section of the EnSight casefile, using the "match: filename" line. EnSight 6 Case file allows the use of the periodic matchfile which uses the matchfile in the border process to eliminate the matched symmetry faces at the shared boundary between the faces. EnSight Case Gold allows the optional [add_ghosts] parameter after the filename which will produce ghost cells across the match file boundary which will provide continuity for variable calculations across the boundary, and for computational symmetry/mirroring, etc. Only use the add_ghosts option if you can afford the penalty of the additional ghost cells and you need the computational continuity that they provide.

When a model piece is created with periodic boundary conditions, there is usually a built-in correspondence between two faces of the model piece. If you transform a copy of the model piece properly, face 1 of the copy will be at the same location as face 2 of the original piece. It is desirable to know the corresponding nodes between face 1 and face 2 so border elements will not be produced at the matching faces. This correspondence of nodes can be provided in a periodic match file as indicated below. (Please note that if a periodic match file is not provided, by default EnSight will attempt to determine this correspondence using a float hashing scheme. This scheme has been shown to work quite well, but may not catch all duplicates. The user has some control over the "capture" accuracy of the hashing through the use of the command: test: float_hash_digits. If this command is issued from the command dialog, the user can change the number of digits, in a normalized scheme, to consider in the float hashing. The lower the number of digits, the larger the "capture" distance, and therefore the higher the number of digits, the smaller the capture distance. The default is 4, with practical limits between 2 and 7 or 8 in most cases.)

The transformation type and delta value are contained in the file. The periodic match file is an ASCII free format file. For unstructured data, it can be thought of as a series of node pairs, where a node pair is the node number of face 1 and its corresponding node number on face 2. For structured blocks, all that is needed is an indication of whether the i, j, or k planes contain the periodic face. The min plane of this "direction" will be treated as face 1, and the max plane will be treated as face 2.

The file format is as follows:

rotate_x/y/z / translate

theta / dx dy dz

np
n11 n21
n12 n22
. .
. .
. .
n1np n2np

blocks bmin bmax i/j/k

Simple unstructured rotational example:

Figure 10.6: Model Duplication by Rotational Symmetry

The periodic match file for a rotation of this model about point 1 would be:

rotate_z

45.0

3

1 1

2 8

3 9

Thus, face 1 of this model is made up of nodes 1, 2, and 3 and face 2 of this model is made up of nodes 1, 8, and 9. So there are 3 node pairs to define, with node 1 corresponding to node 1 after a copy is rotated, node 2 corresponding to node 8, and node 3 corresponding to node 9.

Simple structured translational model:

Figure 10.7: Model Duplication by Translational Symmetry of Structured Blocks (3 Instances)

translate2.0 0.0 0.0blocks 1 1 i

blocks 2 3 j

Since block 1 is oriented differently than blocks 2 and 3 in terms of ijk space, two "blocks" lines were needed in the match file.

Special Notes / Limitations