On choosing GRIDIT in the main menu, you will first see some information on the maximum size of node file which can be handled with your implementation, then be prompted for the name of the file containing the set of nodes for the depth grid (NODE format). The next prompt suggests spatial sorting of the interior nodes prior to triangulation. Sorting can speed up triangulation if a large number of nodes is involved and more importantly, may prevent GRIDIT from 'hanging up' when dealing with especially complicated grids. Next, enter your choice of name for the file to be output containing the depth grid. This file will be in NEIGH format, so use of extension .ngh is recommended for the file name.
Answer 'N' to the next prompt, 'Is triangle list available?'. Normally, of course, a valid triangle list is not available prior to triangulation. This prompt covers a secondary use of some code in the output section of GRIDIT when both a node list and corresponding triangle list are available from some external source and there is a requirement to convert this information into a grid in NEIGH format.
The next prompt asks if a triangle list should be output. Normally, no list is required at this stage, but answer 'Y' and choose a filename for the list; the extension .tri is recommended. GRIDIT will now carry out the triangulation which should take 2 to 3 seconds on a 486 with dep.nod as input. Messages will indicate when the triangle list and grid file are being output, after which the run is complete. The triangle and grid files output should prove to be identical to dep.tri and dep.ngh in trigrid/demodata (see Figure 2.3). The next step is to check the depth grid output by GRIDIT, using the EDITOR program.
The reason for checking the output of GRIDIT is that although the triangulation algorithm is fairly robust, it can produce various errors, some immediately obvious and some not. For instance, when the coordinate datum is poorly positioned, remote from the domain being modelled, consequent error in single precision subtractions in GRIDIT can lead to very obvious misconnections between nodes far removed from one another.
On the other hand, less obvious but serious error can occur if the first few nodes on a boundary are collinear or approximately collinear. Then some or all of the nodes involved, and even some nodes further along the boundary, may have surplus connections to nodes which are not their immediate neighbours in the input node set. Detection and correction of this type of error is possible with the help of the EDITOR, but it is better to prevent it by modifying the arrangement of the corresponding block of nodes in the input file. Since each boundary corresponds to a closed curve, collinear nodes at the beginning of a boundary block can be moved to the end of the block (using a text editor), where they normally cause no problem.
The triangulation algorithm can be confused by certain complicated coastal geometries. When an island lies partly in a coastal bay and both features have relatively few boundary nodes, spurious connections may be set up; the island coastline may be erroneously incorporated into the outer boundary. Another common error occurs along some nearly-straight boundary segments. There are boundary connections that lie outside the boundary and define long,thin triangles that are difficult to see. These errors can generally be detected by using option {.TEST}CHECKNODES in the EDITOR, as will be explained later.
These errors are not peculiar to the Renka algorithm. All methods of triangulation used so far by the authors suffer from some problems similar to those mentioned, so it is advisable to have good error-checking capability, no matter what triangulation method is used.