makepoin1 is a pre-processor that is required when using grids generated with ICEM-CFD meshing tools. makepoin1 takes as input the ICEM generated cell file (usually named with a .bin extension) as input and calculates the first point distance from solid bodies required by the turbulence models in NSU3D.
A sample input file for makepoin1 is shown below:
The meshcut utility cuts the mesh based on distance function and/or layer.
Run this code before runing extract.
dist_cut > 0: cut node's dist > dist_cut
layer_cut > 0: cut node's layer > layer_cut
The setwallbc utility provides a means to 'hard-wire' surface boundary conditions into a NSU3D grid file. A typical use for this would be to specify surface temperature on a patch by patch basis. This utility is for advanced users since it requires modifying parameters in the source code and compiling. It is mainly intended to provide a means to set custom values on boundaries that are not available through the existing boundary condition types.
Comments in the source code indicate where the custom definitions should be placed, but it is up to the user to ensure that the resulting boundary conditions are valid.
The ugcombine utility combines various input grids into a single unstructured grid data set.
To get an example input file, run the utility, type 'input' and press enter.
ugcombine takes the following files for each component grid:
*.mcell.unf --> Mixed cell grid file
*.poin1 --> Boundary Layer Lines from VGRID or makepoin1 code
*.bcs --> Boundary condition file
Note that these are NSU3D grid file formats.
If a grid has been generated in VGRID, then it must
be passed through merge1/merge2 to get a mixed element mcell file
before proceeding to ugcombine.
If a grid comes from ICEM or other mesh generator which generates
mixed element grids, it must be passed through makepoin1 to get a poin1 file.
The bcs file for each component must be built manually as if each
individual grid file were to be run with NSU3D.
The poin1 is optional and may be omitted for inviscid grids.
The bcs file can be omitted but one will need to be created manually
for the combined grid in this case.
Because VGRID and other parts of the NSU3D preprocessor make
assumptions about node ordering, the grid nodes must be re-ordered
The ordering is such that all boundary vertices appear first and then all
prizm layer nodes (ie. the poin1 vertices) appear next, with the remainder
of the vertices appearing afterwards.
The number of bodies in the mcell file :nbod
is used to tag the number of component grids, and each
grid point has a tag to identify the component grid
to which it belongs. This tag list is written to the
bottom of the new mcell file, which is then
read in by extract and re-written at the end of the
edge file created by extract. This info is then partitioned
later by pre_nsu3d.
*****NOTE: For this, versions of extract.2.9d and higher are required.
Older versions will not read the tag id.
*****NOTE: Requires version pre_nsu3d.3.b.3d
The number of patches and components are concatenated from
each individual component grid.
ugform is a facility to reformat a VGRID grid file into a *.cell file for NSU3D. ugform can also be used to define components and rescale a VGRID grid file, or an existing *.cell grid file. ugform will convert VGRID files directly to consistent *.cell files, even in the case of viscous grids generated from VGRIDns. In this case, the surface triangulation connectivity specified in the VGRID file *.bc is incorrect, although the surface patch information contained in this file is correct. ugform accounts for this and recomputes the correct surface triangulation connectivity.
A sample input file for ugform is given below:
Line 1 contains a descriptive title. Various input file formats are supported. The most common is the cogsg VGRID file format. In this case, the file FORMAT on Line 3 is set = 3.0 and the file name refers to a VGRID cogsg unformatted file. The entry on line 5 is then not read. Older VGRID *.int and *.grd files can be read in by setting FORMAT=1 (formatted *.int *.grd) or FORMAT = 2 (unformatted *.intu, *.grdu) on line 3 and 5, while specifying the appropriate file names on these lines. Finally, existing *.cell files can be read in, in order to rescale them or redefine the components. This is achieved using FORMAT = -2 on line 3, with the entries on line 5 being ignored.
For grids generated from VGRID, the bound (*.bc) file must be specified on line 7. This file is always formatted, IFORM = 1.0
The patch to BC file is obsolete and should be set to "none" on line 9.
The component file, described in the next section, is specified on line 11. This is always a formatted file, IFORM = 1.0.
The output *.cell file name is specified on line 13. This should be an unformatted file, using IFORM = 2.0
A scaling factor is specified on line 15, which can be used to rescale the grid by multiplying all coordinates by this factor. In general, grids with dimensions near unity are preferred, since this may prove more robust in subsequent pre-processing operations. To avoid rescaling the grid, use a scaling factor of 1.0
The name of a component file can optionally be specified as input to ugform, on Line 11 of the parameter input list. If no component file is available, the entry none on Line 11 will cause ugform to automatically create a single component and a single body for the entire grid. To specify various components and bodies on the grid, a component file is created by the user the name of which is specified on Line 11 of the ugform input list. A sample component file is shown in Figure 6. Components are specified as groups of surface patches, and bodies are specified as groups of components. Each component/body must be assigned a name, and all patches/components must belong to only one component/body.
Components are listed first, this is done in lines 1, through 30 in the component file. Line 6 denotes the number of components. The names of these components are listed consecutively beginning on line 8.
The patches which constitute each component are then listed beginning on line 15 (in this example), with possible exceptions beginning on line 26 (for this example). Each definition line contains the component number, and a beginning and ending patch number. All patches between these two values are assigned to that component. Patches can be listed multiple times in this assignment. Their component assignment is overwritten with the latest assignment value when they are specified multiple times. The EXCEPTIONS specification also overwrites the component numbers for particular patches. This portion of the file can be deleted (i.e. Lines 23 - 30 inclusively) if no exceptional patches are listed.
The specification of bodies begins on Line 35. This specification is similar to that of components except that bodies are composed of sets of components rather than patches. The number and range of the components must of course be consistent with that specified in the first portion of the component file.
post_nsu3d is a facility for reassembling partitioned restart files generated from parallel nsu3d runs into a single restart file which can then be used as input to other post-processors such as slice and tecform. post_nsu3d can also be used in reverse mode, to partition an existing assembled restart file into a form suitable for use as input to a parallel nsu3d run. Two applications of post_nsu3d can be use to convert a partitioned restart file into restart file partitioned into a different number of partitions by first assembling the existing partitioned restart file, and then repartitioning this file.
post_nsu3d not only assembles or partitions the restart files, but also reorders the data internally in order to correspond to the architecture-optimized ordering imposed by prensu3d on the grid data. For this reason, post_nsu3d must be invoked even for restart files resulting from non-parallel nsu3d runs.
To achieve these functions, post_nsu3d requires as input the restart directory produced by the flow solver, (or the single restart file, when using the reverse mode) and the directory of partitioned grid data produced by post_nsu3d. In actual fact, only the order.n files from this directory are required by post_nsu3d, but it is most often simplest to supply the entire directory without separating out different files.
A sample parameter input file for post nsu3d is given below:
tecform is a post-processor which constructs a file for input to a visualization program. tecform can be used to view a grid and its associated patch system or components, to check the validity of a boundary condition (*.bcs) file applied to a particular grid, or to view a computed solution on a surface grid or in the interior volume grid.
Beginning with Version 4.3, binary output files for TECPLOT are supported. This format is specified by setting the IFORM variable for the tecform output file to 2.0. (IFORM = 1.0 produces a formatted output file.) Binary files are desirable because they are much smaller and faster to read and write. Binary TECPLOT files usually have a *.plt suffx. In order to write binary TECPLOT files, the tecutil.a library must be linked by tecform.
For cases where this library is not available, the tecform makefile provides a compile option which omits linking the library, while disabling the binary file output option. This is achieved by setting the TECIO variable in the makefile as TECIO = TECIO_OFF. When TECIO = TECIO_ON is specified, the tecutil library will be linked. In this case, the location of the library must be specified in the TECLIB make file variable.
Output files suitable for the FieldView and Ensight visualization packages is also possible as described below.
A sample input file for tecform is given below:
Line 1: A title describing the particular case. This title is written to the TECPLOT binary (only) files and appears on in the TECPLOT window when the file is read in.
Line 3: Name of grid input file, this is a *.cell file (mixed element unstructured grid cell file). Format should be 2.0 for a mixed element unstructured grid cell file (most common), or -2.0 for old obsolete tetrahedral-only cell files.
Line 5: Name of NSU3D restart file. Format should be 2.0. If only viewing grid and no solution or restart file is available, this file name can be skipped by specifying 0.0 plot variables on Line 13, and deleting lines 14 through 18.
Line 7: Name of output file to be written. Formatted (IFORM = 1.0) files and binary (IFORM = 2.0) files are supported along with Ensight (IFORM = 3.0) and Fieldview unformatted (IFORM = 4.0). The creation of binary TECPLOT files requires linking to the tecutil.a library upon compilation.
Lines 8-11: For time-dependent cases, these controls allow the user to select the range of solutions to include in the tecform output. Must be paired with the equivalent solution range when running post_nsu3d.
Line 13: For surface plot only use 1.0, for a volume plot set equal to 2.0. Surface plots are most often used due to the much smaller amount of data. Surface plots can be divided up into multiple zones, whereas volume plots are always treated as a single zone (see Line 21).
Line 16: This is the number of variables to be output for plotting in TECPLOT. There can be a maximum of 5 variables, and a minimum of 0 variables. The number of lines under the heading of Line 14 (lines 15 through 18 in this case) must be equal to the specified number of plotting variables. In the event that no plotting variables are desired, this value can be set to 0.0, and lines 14 through 18 can be omitted. In this case, no solution/restart file is read in.
Lines 18 - 21: Specify plotting variables. Number of lines must be same as stated number of variables on Line 13. IPLOT value is a dummy counter. Variable name must be selected from one of the following: density, rhou, rhov, rhow, energy, mach, cp, cptotal, entropy. The first five of these names correspond to the values in the five locations in the solution/restart file (usually conserved variables). The other variables are computed from these variables within tecform.
Line 24: Number of zones for surface plotting. For volume plotting this should be 1.0. For surface plotting, this can be any positive whole number, or -1.0, or 0.0 A value of -1.0 will automatically list each surface patch as a separate zone. No entries in the input file are required after this line in the case where the number of zones is set to -1.0. If this entry is set to 0.0, then a boundary condition (*.bcs) file must be specified on the next line (Line 22). A separate zone is then created for each boundary condition. No entries in the input file are required after the specification of the boundary condition (*.bcs) file. This option is useful for checking the correctness of a particular boundary condition file.
Lines 26-29: If the number of zones is greater than 0, then the appropriate number of zones must be defined under the heading on Line 24. IZONE is a dummy counter. ZONE_NAME is the name to be assigned to each zone.
Line 32: Zones can be defined either by patches (1.0) components (2.0) or bodies (3.0).
Lines 34 - 41: Zones are defined on these lines. IZONE refers to the zone number. All patches (or other defining entities) between BEG_NUM and END_NUM will be assigned to the zone IZONE. These entities may be listed multiple times. Their parent zone is updated at each new listing. They may also be overwritten by listing them under EXCEPTIONS starting at Line 45.
Lines 51 - 55: These lines are optional and may be deleted. They provide the possibility for computing force coefficients based on particular zones. The zone is defined by IZONE, and a reference area for force coefficients, and reference length for moment coefficients are required for each zone, as well as the location of the moment axis, and the ISPAN variable which is used to set the span-wise coordinate (see NSU3D input).
slice is a post-processor which takes two-dimensional slices of data defined by a grid (*.cell) file and a solution (restart.out) file. The output can consist of one-dimensional line data along the intersection of the three-dimensional surface grid and the slicing plane, or two-dimensional field data at the intersection of the slicing plane and the volume grid. slice can compute coordinate-aligned as well as oblique planar cuts and can also be used to produce files for plot13d andplot23d (unsupported 1D and 2D plotting packages), or for TECPLOT (both 2D and 3D).
Beginning with Version 2.5, binary (3D only) files for TECPLOT are supported. This format is specified by setting the format variable on Line 9 in the input list to 2.0. Binary files are desirable because they are much smaller and faster to read and write. Binary TECPLOT files usually have a *.plt su x. In order to write binary TECPLOT files, the tecutil.a library must be linked by slice. For cases where this library is not available, the slice make file provides a compile option which omits linking the library, while disabling the binary file output option. This is achieved by setting the TECIO variable in the make file as TECIO = TECIO_OFF. When TECIO = TECIO_ON is specified, the tecutil library will be linked. In this case, the location of the library must be specified in the TECLIB make file variable.
A sample input file for slice is given below:
Line 1: A title describing the particular case
Line 3: Name of grid input file, this is a *.cell file (mixed element unstructured grid cell file). Format should be 2.0 for a mixed element unstructured grid cell file (most common), or -2.0 for old obsolete tetrahedral-only cell files.
Line 5: Name of NSU3D restart file. Format should be 2.0
Line 7: Name of boundary condition (*.bcs) file. This file is required only if surface types are picked by boundary condition type (see Lines 22-24), otherwise it is not read in.
Line 9: Format for output files. Select 0.0 for surface and volume slice files compatible with plot13d and plot23d (unsupported line and 2D plotting packages). Select 1.0 for formatted 2D and 3D TECPLOT files. Select 2.0 for binary 3D TECPLOT files (2D surface file remains formatted). When binary output is selected, the tecutil.a library must be linked at compile time using the TECIO and TECLIB variables in the makefile.
Line 11: Select surface (= 1.0) or volume (= 2.0) plot, or both (= 3.0) A surface only plot will produce data of conserved variables on the one dimensional surface/plane intersection. This data can either be viewed with the unsupported program plot13d, or by reformatting for TECPLOT. Volume intersections produce two-dimensional planar data that is output in a format consistent with the unsupported program plot23d. This data can also be reformatted for TECPLOT. When a surface and volume cut are selected ( = 3.0), the surface plot will include skin friction data at the surface-planar cut intersection. This is not done in the case where a surface plot only is selected ( = 1.0) since this requires information from the interior volume grid (i.e. the first point off the wall for a gradient), which cannot be assumed to exist if only a surface values are supplied.
Line 13: Tolerance for search: The intersection routines are performed in real arithmetic (64 bit). A tolerance is required to test for intersections. A small value should be specified here. If anomalies in the output are detected, this value can be altered to a effect the outcome of the intersection test. In general, this should not require adjustment.
Lines 15 - 16: A bounding box for the intersection test can be specified in order to clip extraneous data. This is specified as a range on the three coordinate axes outside of which data is ignored. Line 13 specifies the minimum x,y,z values for this range, and Line 14 specifies the maximum x,y,z values. To avoid any clipping, these values should be set larger than the extent of the grid.
Line 18: The cutting plane is defined on this line. There are two ways of defining the cutting plane. For cuts aligned with one of the coordinate axes, a coordinate direction and value are defined. The coordinate direction is defined by the first entry FKIND. FKIND = 1.0, 2.0, or 3.0 denotes a planar cut at x= constant, y = constant, or z = constant. The location of the planar cut is then defined by the second input, FPOSITION, which corresponds to the constant value of the x,y, or z coordinate. Oblique planar cuts can be specified with a negative entry for the first variable on Line 16, i.e. FKIND = -1, -2, -3, or -4. In this case, a series of 6 real numbers must follow, specifying the x,y,z coordinates of the plane origin, and the direction cosines of its normal. The resulting intersected data will be projected onto one of the coordinate axes depending on the value of FKIND:
Line 22: A rotation of the resulting intersected data may be applied to obtain a desired orientation. Specified in degrees.
Line 24: A reflection of the resulting intersected data about the x-axis may be applied to obtain a desired orientation. Reflection is applied if the value 1.0 is entered on Line 22. If 0.0 is entered, no reflection is performed.
Lines 26 - 28: These lines determine which portions of the surface grid are to be intersected by the planar cut. These can be chosen based on boundary condition type (enter 0.0 on line 26), patch type (1.0 entry), component type (2.0 entry) or body type (3.0 entry). If boundary condition type is specified, then a valid boundary condition (*.bcs) file must be listed on Line 7, and a valid boundary condition type must be listed on line 28. In all other cases, the numerical id of the patch/component/body must be listed on line 28.
Line 30: The number of plot variables to be output is specified here. The maximum number is 5 and the minimum 0.
Lines 32-36: List the desired plot variables, one per line.
Coordinate Plane Definition:
fkind = 1 ---> Plane defined by : x = fposition
fkind = 2 ---> Plane defined by : y = fposition
fkind = 3 ---> Plane defined by : z = fposition
Oblique Plane Options:
fkind = 0 ---> Physical Coordinates (x-y-z)
and x/c,y/c,z/c, (c= local chord(min-max))
fkind = -1 ---> Projected onto x-axis (y-z coords)
fkind = -2 ---> Projected onto y-axis (x-z coords)
fkind = -3 ---> Projected onto z-axis (x-y coords)
fkind = -4 ---> No projection, plane coords
centered at xpos,ypos,zpos
Plane Defined by point: xpos,ypos,zpos
and Direction Cosines : fn1,fn2,fn3
AVAILABLE VARIABLE TYPES:
When the NSU3D tool suite is installed as detailed above, there is a shell script called PRENSU3D.sh that can be used in lieu of running the individual post-processing tools in order to prepare a supported mesh type for running in NSU3D, as well as performing other tasks, such as re-partitioning or defining a new set of multi-grid levels for the model.
Executing the script with no arguments produces a brief summary of usage options:
In most cases, the default options will produce a valid set of case files for running the flow solver as long as the values of NMESH and NPART are appropriate where:
NPART = Number of mesh partitions for parallel execution. The parallel solver will run as long as the number of partitions is evenly divisible by the number of mpi processes launched.. i.e. 8 partitions will run on 8, 4, 2, or 1 processes, but not on 3, 5, 6, 7 or more than 8 processes.
NMESH = Number of grid levels to construct for the multigrid convergence acceleration scheme employed by the flow solver. Typical values are 4 or 5, but this may be reduced if there are problem areas in the mesh.
amg3d is the pre-processor which builds the coarse multigrid levels for the agglomeration multigrid algorithm employed by NSU3D
amg3d employs a graph algorithm to construct the coarse grid levels. Therefore, amg3d takes as input a *.edge grid file. The implicit lines are constructed either with a weighted graph algorithm, or by using information in the *.poin1 file which defines the normal structure of the prismatic layers. The output of amg3d consists of a *.amg file which contains all the necessary information for running the multigrid algorithm with NSU3D.
A sample input file for amg3d is given below:
The input (*.edge) file and output (*.amg) file and their formats are listed on lines 3 and 5respectively on the amg3d input list. While various options for these file formats are available, FORMAT = 2.0 should be used exclusively in all cases for both files.
The number of coarse levels to be generated is specified on Line 7. If too many levels are specified, such that too few points exist for adequate coarse level construction, amg3d may fail on these levels. If a failure occurs, simply reduce the number of levels until the code completes satisfactorily. Note that the total number of grid levels available to the multigrid algorithm in the solver is NLEVELS + 1, since the fine grid is not included in NLEVELS. Thus the parameter NMESH in the NSU3D input list may be set less than or equal to NLEVELS + 1. If NMESH exceeds this value, NSU3D will terminate before the multigrid solution process begins.
The parameters on lines 9, 11, and 13 determine the specifics of the agglomeration algorithm for constructing the implicit lines and the coarse levels.
ILINE (Line 9): Determines line construction algorithm.
ILINE = 0 omits any construction of implicit lines. Solver will run point implicitly only.
ILINE = 1 creates lines using weighted graph algorithm on each level.
ILINE = 2 creates lines using weighted graph algorithm on fine level. On coarse levels,
only edges which contain fine grid line edges can become lines.
ILINE = 3 creates lines using *.poin1 file information. Edges listed in this file are given
large weight to ensure they get chosen as a line edge by the weighted graph algorithm.
ILINE = 4 creates lines using *.poin1 file information exclusively.
IWEIGHT (Line 11): Controls weighting of graph algorithm.
IWEIGHT = 1: Use regular weighted graph.
IWEIGHT = 0: Do not use any edge weights. Line weights are still used.
IWEIGHT =-1: Do not use any edge or line weights.
IFRONT TYPE (Line 13): Governs the agglomeration front.
IFRONT TYPE = 1: Use aspect ratio priority queue. High aspect ratio points are
IFRONT TYPE = 2: Use number of fine grid points as priority queue. Agglomerated
cells containing the fewest number of fine grid points are considered first.
IFRONT TYPE = 3: Regular front. Based on neighbors of previously agglomerated
While there are various options for controlling the agglomeration specifics, in practice, only two settings are used:
For highly stretched viscous grids: ILINE=3.0, IWEIGHT=-1, IFRONT TYPE=3
For isotropic inviscid grids: ILINE=0.0, IWEIGHT=-1, IFRONT TYPE=3
These two individual settings should be used exclusively for most users.
distf3d is the pre-processor which computes the distance function required by certain turbulent models in the flow solver, such as the Spalart-Allmaras one equation model. distf3d reads in a grid *.edge file and a boundary condition *.bcs file, and outputs a distance function *.dist file. The *.dist output file contains the distance for each grid point to the nearest boundary face on a Navier-Stokes no-slip boundary, as defined in the boundary condition file. Additional information, such as the identity of the nearest boundary face for each grid point is included in the *.dist file, but is not required by the turbulence model. The *.dist file is subsequently used as input for the flow solver or its pre-processor pre_nsu3d.
The computation of the distance function for large grids can become unacceptably expensive if a brute force search technique is employed. For this reason, a sophisticated octree searching technique is implemented. For smaller grids, or cases where the octree method may fail, the brute force technique can be used as a backup method.
There are three phases to the computation of the distance function. The first phase finds the closest boundary point for each field point. The second phase finds the closest location on a boundary face for each field point, using the neighboring faces of the closest point. The third phase checks and updates these distances if they are not the true minimum distances (for example if a closer face which is not a neighbor of the closest point can be found). Because this last phase can be very expensive, and only results in minor corrections, it can be restricted to points close to the boundaries.
A sample input file for distf3d is given below:
Line 3: Choose the formulation for computing the distance function. Formulation 1.0 selects the inexpensive, but inexact method based on finding the closest point. Formulation 2.0 selects the exact method (usual setting), which is more expensive.
Line 5: When the exact (=2.0) formulation is chosen, it is usually applied only in regions close to the boundary, to spare the expense of recomputing the distance function over the whole grid with the exact formulation. FDISTMAX determines the distance away from the boundary within which the exact formulation is employed.
Line 7: CLOSEST PT SEARCH METHOD: 1.0 selects the sophisticated and more efficient octree method, while 2.0 selects the simple but more expensive brute force method. Usual setting = 1.0. Brute force method can be used as backup method in case octree method fails.
Line 9: The input (*.edge) file and its format are listed on Line 9. FORMAT = 2.0 should be used exclusively here.
Line 11: The boundary condition (*.bcs) file and its format are listed on Line 11. FORMAT = 1.0 should be used exclusively here.
Line 13: The output (*.dist) file and its format are listed on Line 13. FORMAT = 2.0 should be used exclusively here.
A sample input file for dmin3d is shown below:
extract is a facility for converting a *.cell file into a *.edge file. A *.cell file can be considered as the neutral file format for NSU3D. Any incoming grid must first be converted to the cell file format. This format contains a description of all the cells (mixed elements including tetrahedra, prisms, pyramids, hexahedra) and boundary faces (triangles and quadrilaterals). While this is the most compact and highest level representation of an unstructured grid, it is not suitable for an edge based flow solver such as NSU3D, which requires a list of (unrepeated) edges and edge coefficients. extract extracts the graph (list of edges) from the grid specified in the cell file, and builds the necessary coefficients required by the flow solver. The resulting edge files are several times larger than their generating cell files, and do not contain the cell connectivity information, the regeneration of which is a non-trivial operation when only edge data is available.
A sample parameter input file for extract is given below:
An input *.cell file name is specified on Line 3 and its format type on Line 5.
An output *.edge file name is specified on Line 7 and its format type on Line 9.
NSTERM (Line 11) : Parameter for selecting the type of edge coeficients to be included in the output file. Although various file format options are available, the use of FORMAT = 2.0 is recommended exclusively for all cases for both input and output files. For inviscid flow computations, NSTERM can be set to 0.0, and only inviscid flow edge coefficients will be computed. For NSTERM = 1.0, the edge coefficients required for the full Navier-Stokes terms are computed. However, this is only possible for a fully tetrahedral mesh, and for a mixed element mesh (containing prismatic elements for example) the edge coefficients for the thin layer viscous terms must be employed by setting NSTERM = 2.0. In general, NSTERM can be set = 2.0 for all cases.
merge1 is a program to reduce the complexity of three-dimensional tetrahedral grids by merging tets into prism elements. The .poin1 file generated by VGrid or by invoking the makepoin1 program is required.
A sample input file for merge1 is shown below:
The default values shown here should be used for most cases, as merge1 is an intermediate step in generating grids for NSU3D and the defaults usually produce good results.
merge2 is a program to create consistent faces in a mixed element grid for NSU3D. The program takes the ouput from the merge1 program which consists of non-contiguous merged prisms and tets and creates a valid mesh.
A sample input file for merge2 is shown below:
pre_nsu3d is the general pre-processor for the flow solver nsu3d. The principal function of pre_nsu3d is to create partitioned data for parallel execution of the flow solver. pre_nsu3d also in-corporates various other pre-processing operations previously contained within the flow solver itself in older versions of nsu3d. (These include reordering data for cache or vector efficiency, build-ing coarse grid data structures, assigning boundary conditions, checking mesh and multigrid level consistencies .etc..).
There are three (3) different modes of operation for pre_nsu3d. In the automatic mode, pre_nsu3d reads in the grid and other associated file, partitions the data using an internally supplied partitioning strategy, and then writes out the partitioned data for the flow solver. This mode of operation is achieved by setting the parameter NOPTIM = 0.0
The internally supplied partitioning strategy produces sub-optimal partitions, and should only be used for small numbers of partitions (of the order of 4). In general, much better parallel per-formance will be achieved by making use of a better partitioning strategy. Therefore, an interface is provided to two externally available grid partitioners, the CHACO partitioner, described at http://www.cs.sandia.gov/bahendr/partitioning.html, and the MeTiS partitioner, downloadable from http://www-users.cs.umn.edu/karypis/metis/main.shtml.
In order to use an external partitioning code, pre_nsu3d must be invoked twice. The first run of pre_nsu3d is used to generate output files for the partitioner. In this mode, the NOPTIM parameter is set to a negative value (-1 or -2, depending on the partitioner to be used), and a separate file is generated for each grid level in the multigrid data set (including the finest grid). These files are then used as input to the grid partitioner. Each file must be partitioned into the same number of subdomains, and this must correspond to the parameter NPART in the pre_nsu3d input file. In the second phase, pre_nsu3d is run again with the same inputs, except that the parameter NOPTIM is now set to 1.0, and the partition files (generated as output from the partitioner) must be listed in the pre_nsu3d input file, under the heading PARTITION FILES, listing the fine grid partition file first, followed consecutively by the partition file for each coarser grid level. The fully partitioned output for the flow solver is generated as output from this run.
pre_nsu3d requires as input a grid (*.edge) file, a distance function (*.dist) file, a multigrid (*.amg) file, a boundary condition (*.bcs) file, and optionally, a list of partition files for each multigrid level. The output of pre_nsu3d is not a file, but rather a directory containing a series of files. The user need not be concerned with the contents of the individual directory files. The directory can be copied, moved, or tarred up and ftp'ed to remote machines without individually listing the contained files. The flow solver nsu3d need only be given the directory name as input.
The output directory produced by pre_nsu3d contains three files for each processor of a parallel nsu3d run:
header.n : A formatted test file containing information on the number of points and other entities for the partition of the grid belonging to processor n, where the range of n is 0 to number of processors-1.
order.n : An unformatted file with the original vertex ordering information (with respect to the unpartitioned data) for each partition n.
part.n : An unformatted file containing all grid and other information required by the flow solver for partition n.
Therefore, when running on 128 processors, for example, the pre_nsu3d output directory will contain 384 files. When running sequentially on a single processor, this directory will contain only 3 files.
The number of partitions/processors is specified as input to pre_nsu3d, which in turn determines the configuration of the output directory. Note that the flow solver nsu3d can be run efficiently on a number of processors which is any sub-multiple of the number of grid partitions. Therefore, it is advisable to partition the grid at the outset into a number corresponding to the maximum number of available processors, even if it is expected to be run most of the time on a smaller number of processors. For example, if 32 processors are available and the grid is partitioned into 32 parts, the solver can be run efficiently on 1, 2, 4, 8, 16 or 32 cpus, which can be specified at run time.
A sample pre nsu3d input file is given below:
Line 3: The input grid (*.edge) file and its format are listed on Line 3. Format should always be = 2.0
Line 5: The input distance function (*.dist) file and its format are listed on Line 5. Format should always be = 2.0
Line 7: The input multigrid (*.amg) file and its format are listed on Line 7. Format should always be = 2.0
Line 9: The input boundary condition (*.bcs) file and its format are listed on Line 9. Format should always be = 2.0
Line 11: NOPTIM controls the mode of operation of pre_nsu3d.
NOPTIM = 0.0: Auto-partitioning mode. pre_nsu3d will use the internally supplied partitioner to partition data into NPART subdomains, and produce the output required by the flow solver. In this mode pre_nsu3d needs only be run once, but partition quality is generally poor.
NOPTIM < 0: Create output for external stand-alone partitioners. Output for either CHACO (-2.0) or MeTis (-1.0) can be generated. One file for each grid level of the multigrid algorithm is generated. These files are to used as input to the appropriate grid partitioning program.
NOPTIM = 1.0: Read partition files created by external partitioners, and generate final partitioned output required by flow solver. The partition files to be read in must be listed in the input file on Line 19 and below, starting with the partition fole for the finest grid, followed by each successively coarser grid.
Line 13: VECTORIZATION = 0.0 should be used for cases to be run on cache-based microprocessors. For vector machines, such as the Cray J90 or SV1, VECTORIZATION = 1.0 should be used, or false results may be produced. Using VECTORIZATION = 1.0 on a non-vector machine will result in sub-optimal performance. VEC_LENGTH defines the length of vector line vector groups for vector runs. (This is only relevant for the line solver, not for the regular grid edges). Large vector lengths will run faster on vector machines, but may incur more overall work because short lines need to be extended to fit the length of the longest line in the same vector group. VEC_LENGTH = 64.0 is a good compromise for most cases.
Line 15: NMESH defines the number of multigrid levels (including the fine grid).
Line 17: NPART defines the number of partitions. This must be consistent with the number of subdomains in the partition files to be read in, otherwise pre_nsu3d will abort.
Line 19: The names of the partition files, generated by an external partitioner, are listed starting on Line 19, and adding extra lines for each additional file name. There is one file name for each grid level, starting with the finest grid and ending with the coarsest grid. These file names are only required when NOPTIM > 0.