The number of non-C(0) block interface conditions, or patches, is specified in the "general input" section (BOUNDARY AND CUT CONTROL) by the parameter PATCHBCS. Patch conditions are specified in the input file after the boundary condition and cut condition data. The first line of input for this section is a comment line (the $ delineator is not required). There must be a pair of patch condition input lines for each patch condition in order to define the blocks, boundaries, and cells that are to exchange data across the patch boundary.

Unlike a CUT each patch pair must be input in a specific order. The first line of the patch data pair is the object (receiving side) and the second line of the patch pair is the image (transmitting side). In other words, data will be transmitted from the image side and received by the object side of the patch pair. In addition, the patch coefficient generation code requires that the user specify that data is to be exchanged or updated on both sides of the patch. Therefore, for each patch interface, two patch pairs of data must be input. VULCAN will skip the superfluous side of the patch pair when patches are specified that exchange data between different regions.

When specifying the PATCH data defining the object side of the patch, the exact number of cells that are to receive data should be specified. The image side of the PATCH should be defined to be larger than necessary:

1) Do not over specify the size of the object side of the patch, or the patch coefficient generation code may find image cells that you don't want.

2) Do over specify the size of the image side. Actually, only the image block and face numbers are used by the patching algorithm.

Example: (Comment line and two pairs of patch condition lines)

While CUTS used a pair of cut data to define the bi-directional communication of block data (block 1 getting data from block 2 and block 2 getting data from block 1). The PATCH input data pair defines a uni-directional communication of block data (block 1 getting data from block 2). Each side of a patch pair must contain input data that defines the patch location and size.

PCH NAME: CHARACTER STRING; string of up to 10 characters indicating the name of the patch condition. Both sides (that is, both lines) must have the same string.

BLK: INTEGER; Block number that the patch condition applies to.

FACE: CHARACTER STRING; Face that the patch condition is to be applied on.
I = I constant boundary
J = J constant boundary
K = K constant boundary

PLACE:CHARACTER STRING; Patch condition location.
MIN = patch condition at minimum face
MAX = patch condition at maximum face
DIR1:CHARACTER STRING;Direction "1" for defining the patch window (e.g. for FACE 'I', DIR1 would be either 'J' or 'K').
I = I direction
J = J direction
K = K direction

BEG:CHARACTER STRING; Grid point at which to begin patch condition which runs in the direction specified by DIR1.
MIN = Start at minimum index of DIR1
25  = Start at index 25 of DIR1

END:CHARACTER STRING; Grid point at which to end patch condition which runs in the direction specified by DIR1.
MAX = End at maximum index of DIR1
65  = End at index 65 of DIR1

NOTE 1: BEG must be less than END, and BEG cannot equal END.

NOTE 2: The sequence (DIR1, BEG, END) must be repeated for DIR2.

IN-ORDER:INTEGER; Indicates whether the patch is to be propagated into the interior of the block as a part of the initialization process, and the order it is to be used in the initialization process. 0 = Do not use for initialization
1,2,3, ... = Propagate the patch into the block interior as a part of the initialization process where the number indicates the order in which to use the patch in that process.

NOTE: All patches must have an IN-ORDER number assigned to them! If the patch is applied to an IMIN face it will be propagated in the positive I direction from the IMIN boundary to the IMAX boundary.

NOTE: The sum of all image patch definitions must be large enough to contain all of the points defined on the object definition side of the patch. If this requirement is not met, the patcher code supplied with VULCAN will fail to find enough image data to completely define the patch interpolation weighting coefficients for the object side of the patch.

Example: PATCHBCS must have been set equal to 2.0 in the general control data section of the input.

This example involves an exchange of data between a J maximum boundary (I and K directions) in block 1 and a K minimum boundary (I and J directions). NOTE: The information obtained from block 1 by block 2 (which is interpolated and stored in the KMIN ghost cells) will be propagated into block 2 from the KMIN boundary to the KMAX boundary during the fifth pass of the initialization process.

The patcher code was originally written for the PAB3D code developed by the Propulsion Aerodynamics Branch at the NASA Langley Research Center. The source code for this utility was tightly coupled to the PAB3D solver, and had a variety of non-standard FORTRAN elements that introduced compiling difficulties on some platforms. As a result, a new modular F90-compliant utility was written that utilizes the VULCAN input file as its direct input source. This utility is largely based on the PAB3D patcher algorithm, but differs in some respects. In particular, the approximate spiral search algorithm used for locating the donor cells that patch to a given block face has been replaced with a global search that requires Ο(N) operations (where N is the number of donor cells on the patch boundary).

The patching of 2 block faces can be separated into three distinct tasks. The first task is to identify and gather the faces that are involved with the patch interface. This step is achieved by parsing the patch window specification of the VULCAN input file described above. The block faces used to define a patch are referred to as either the "A" or "B" mesh, respectively. The "B" mesh is considered the donor (or image) mesh, and the "A" mesh is the receiving (or object) mesh. The second step is to identify all of the cells in the "B" mesh that overlap a given "A" mesh cell. The final step is to clip the "A" mesh cell with respect to the "B" cells and calculate the total percent area of the overlap. The resulting area percentages are saved to a "map" and output to the patch coefficient file. A bad cell list is created (if necessary) that contains information about cells that have not been properly patched. VULCAN execution will stop if the bad cell list file is present. At this point, the user should examine the contents of this file to decide if further refinements in the patch control parameters are required, or if there are errors in the patch window specification portion of the VULCAN input deck. If the patching errors are not catastrophic (i.e. if some amount of area overlap was found for all "A" mesh cells), then no further refinements are required, and executing VULCAN a second time will simply use the patch file that was created. However, the user has the option at this point to execute the patch utility in an interactive mode via the command:

VULCAN_pchutl

to attempt to refine the patching process and reduce the number of poorly patched interfaces.

There are three input parameters that influence the patching process:

(1) Point Outside UV Face: defines the tolerance for determining if the whether a "B" mesh cell vertex projects onto the given "A" mesh cell. The tolerance entered for this parameter must be between 0.0 and 1.0, but typical values used in practice lie between 0.001 and 0.05.

(2) Coinciding Point Distance: defines the tolerance for determining if a "B" mesh cell vertex coincides with an "A" mesh vertex. This tolerance is scaled relative to a measure of the smallest cell length present on the "B" mesh portion of the patch interface, i.e.
tolerance = min( sqrt(smallest "B" mesh area)*tolerance, tolerance)
The tolerance entered for this parameter must be greater than 0.0, with typical values used in practice ranging between 0.001 and 0.05.

(3) Smallest Area Fragment: defines the smallest area fragment percentage of a "B" mesh cell to be considered when projected on the "A" mesh cell. Area fragment percentages below this value are ignored. This tolerance rarely needs to be altered from its default value unless a large number of cells on the "B" mesh are patching to a single cell on the "A" mesh. The tolerance entered for this parameter must be greater than 0.0, with typical values used in practice ranging between 0.001 and 0.01.

2-D test case

This test case demonstrates the patching procedure on a simple 2-D test case. This case involves a simple 2-block grid for flow over a wedge. A patched grid interface matches the J-MAX face of the lower block with the J-MIN face of the upper block upstream of the wedge.

To try this case, run the VULCAN pre-processor using the input file "inlet_2d_nc0.dat" (found in the Sample_cases directory). The pre-processor runs quickly with no problems (i.e. the bad_cell_list file is empty), and creates the PATCH FILE "inlet_2d_nc0.ptch". Note that the VULCAN input file was set up to utilize 2 levels of multigrid (COARSE GRIDS is set to 1 in "inlet_2d_nc0.dat", which gives a total of 2 levels of multigrid). This requires that the patch coefficient file be compatible with 2 levels of multigrid. As an experiment, change the COARSE GRIDS value in "inlet_2d_nc0.dat" from 1 to 0. When the VULCAN pre-processor is re-executed, the patching process is skipped. The patching file has more multigrid levels available than is required by VULCAN, which implies that the existing PATCH FILE can be used.

As an additional exercise, one can edit the "inlet_2d_nc0.dat" file and change COARSE GRIDS from 0 to 2 (implying that 3 total levels of multigrid are required). When the VULCAN pre-processor is executed, a new PATCH FILE is generated because the VULCAN solution requires a 3rd level of multigrid. while the existing PATCH FILE was set up for only 2 levels.