These scripts can be found in a git repo here: ~thomas/git/ICEMCFD_Scripts/wing-body-tail_620blk/scripts.git
The instructions here are up to date with the October 29, 2013 git commit with ID: 7f8d41510a6db547b38dfdb3c52c76a3f98c870b
Sample geometries are in ~thomas/git/ICEMCFD_Scripts/wing-body-tail_620blk/examples
These scripts are used for generating 620 block grids around a wing-body-tail configuration. The process is broken into three stages:
Geometry processing
Blocking
Meshing
The script at each stage can be run as follows. In the ICEM terminal session ("med>" is the prompt) point to the correct input file for each stage by doing:
set geometry_input <geometry_file_name>
set blocking_input <blocking_file_name>
set meshing_input <meshing_file_name>
Then each stage can be run by doing:
source geometry.rpl
source blocking.rpl
source meshing.rpl
This will read the input in the corresponding files defined by geometry_input, blocking_input, meshing_input and execute the scripts.
The scripts can now not be run through the replay GUI. This is because certain features are not available when using the replay GUI as opposed to batch mode.
0. Geometry Preprocessing
The geometry required by the geometry script has several requirements:
The base geometry which you start with must have a certain form. There must be 1 fuselage surface named s.f, 4 main wing segments on the lower and upper surface, each named s.wN.ls, s.wN.us where N = 1,2,3,4,5 and segment 5 is a small tip cap. The tail must have at least one main segments on the lower and upper surface, each named s.tN.ls, s.tN.us where N = 1,5 and segment 5 is a small tip cap. Two main surfaces are actually required on the tail. There is an option in the geometry_input file called 'split_tail' which can be used to do this automatically. However it is not stable in all cases. Thus, it is HIGHLY recommended that you manually set the main tail surfaces in the spanwise direction to form s.tN.ls, s.tN.us where N = 1,2,5.
The (u,v) surface parameters must also be oriented as follows: 1) Fuselage: u = length direction, v = radial direction, and 2) Wing/Tail: u = spanwise direction, v = chordwise direction. Those surfaces which come out of Genair should adhere to this, but the surfaces may need to be adjusted in certain cases
The wing segment 1 must intersect the fuselage. If needed, the wing can be manually shifted inboard slightly to provide this intersection if it is not already present.
The fuselage cannot have a hole where the wing intersects it.
If the original geometry file contains other parts and/or surfaces they will be ignored by the scripts, unless the part name begins with "PART_", in which case the part and its contents will be deleted.
This step is done manually by you.
1. Geometry Processing
The base geometry (for example wbt_base.tin) which has the naming conventions as described above, must be present.
A geometry input parameter file is required (for example geometry.params), with the options described below. A sample of which can be found in the git repo as "geometry.params".
1.1 Input parameters
base_geometry_file: The name of the original geometry in the format as described above.
geometry_file: The final processed geometry file. This same file will be used by all future stage scripts.
geo_tol: ICEM triangulation tolerance.
farfield_dist: Distance from the origin to farfield.
farfield_spread_angle: The angle at which blocks on the geometry grow as they go to the farfield.
fuse_offset_dist: The distance from the fuselage of the first block break surrounding the fuselage.
wing_chord_offset: This is used to create points ahead/behind the leading and trailing edges of the wing which are used for flaring blocks during the blocking stage
wing_normal_offset: The height of the wing-adjacent blocks.
wing_tip_offset: Width of the block off of the wing tip in the spanwise direction.
tail_chord_offset: Same as wing, but for the tail.
tail_normal_offset: Same as wing, but for the tail.
tail_tip_offset: Same as wing, but for the tail.
fuse_sections: The locations, as fractions of fuse length at which cross sections are cut from the fuselage. These form the location of block splits later on. Those elements of the list marked with NOSE, LE, HC, TE, TAIL are determined automatically.
split_tail: While the input geometry may have only one tail surface and a tip cap, two are needed later on. If split_tail = True, the geometry script will do this cutting for you. However, there are cases where it can fail. Thus it is recommended that you do this manually in the creation of the base geometry and this flag can be set to False.
tail_span_split: If split_tail = True, this is the span fraction at which the split is made.
1.2 Running the script
There must exist the base geometry file with the naming convention described above, and specified in the "base_geometry_file" option. The script is run as described above. After running the geometry.rpl script, the "geometry_file" (for example wbt.tin) will be created.
2. Blocking
As long as the geometry script has been run successfully, the blocking script should work. A blocking input parameter file is required (for example blocking.params), with the options described below. A sample of which can be found in the git repo as "blocking.params".
2.1 Input parameters
geometry_file: The processed geometry .tin file from the first script.
blocking_file: The output blocking file generated by this script.
geo_tol: ICEM triangulation tolerance.
fuse_shape_factor: A factor which matches the edge shapes just off of the fuselage to the fuselage shape.
wing_shape_factor: A factor which matches the edge shapes just off of the wing in the chordwise direction to the wing shape.
auto_smooth_vertices: This will apply automatic vertex orthoganalization to certain vertices if set to True. However, it is an automatic function, and as such can lead to undesirable behaviour. Use with caution.
2.2 Running the script
There must exist the geometry file from the geometry script (for example wbt.tin) as well as the blocking input parameter file (for example blocking.params).
The script is run as described above. On completion the "blocking_file" will have been created.
At this point, if changes must be made (i.e. manual edge flaring, etc) it should be done and saved as a blocking file again. Any manual changes done to this file must not change the number or names of vertices and/or blocks or the meshing script will not work!
3. Meshing
There must exist the geometry (e.g. wbt.tin) and blocking (e.g. wbt.blk) files, as well as a meshing input parameter file present (for example meshing.params), with the options described below. Samples of which can be found in the git repo for sample fitting grids ("fitting.params"), Euler grids ("euler.params") and RANS grids ("rans.params").
3.1 Input parameters
geometry_file: The geometry file out of the geometry script.
original_blocking_file: The basic blocking file either generated by the blocking script, or a manually modified version of that.
meshed_blocking_file: The output blocking file with the mesh information.
grid_file: The Plot3D grid file if export is requested.
export_grid: Exports a Plot3D grid file if True.
scale_grid: The Plot3D file is scaled by this factor on export.
geo_tol: ICEM triangulation tolerance.
Fluid/farfield meshing inputs:
n_fluid: Number of nodes in the main fluid blocks in each direction.
h_fluid: The factor of a uniform spacing. I.e. spacing = h_fluid (edge_length/n_fluid).
bl_fluid: The bunching law used in the fluid.
h_farfield: The farfield spacing (in absolute units).
bl_farfield: The bunching law used towards the farfield.
General geometry mesh inputs:
n_normal: Number of nodes normal to the surfaces.
h_normal: Off-wall spacing, as a fraction of the root chord.
h_normal_chord_scaling: Specifies how off-wall spacing scales with the chord. I.e. off-wall spacing = h_normal * c_root * (c/c_root)^h_normal_chord_scaling.
bl_normal: The normal direction bunching law.
n_chord: Number of nodes over half the wing and tail chord.
h_chord_LE/HC/TE: leading edge, half chord, and trailing edge spacings, as fraction of the local chord length.
h_chord_chord_scaling: Specifies how LE/TE chordwise spacing scales with the chord. I.e. LE/TE spacing = h_chord_LE/HC/TE * c_root * (c/c_root)^h_chord_chord_scaling.
gr_chord: A power by which the chord spacing grows as it moves away from the wing. I.e. spacing = h_chord_LE/HC/TE * (distance from wing)^gr_chord.
bl_chord: Bunching law along the chord.
n_span: The number of nodes on each block on the wing/tail in the spanwise direction.
h_span_root: Spanwise spacing at the wing/tail root as a fraction of the semi-span.
h_span_midspan: Spanwise spacings at the wing/tail block interfaces between segments as fraction of uniform spacing.
h_span_tip: Spanwise spacing at the wing/tail tip as a fraction of the semi-span.
gr_span: A power by which the span spacing grows as it moves away from the wing. I.e. spacing = h_span_root/mid/tip * (distance from wing)^gr_span.
bl_span: Spanwise bunching law.
Fuse specific mesh inputs:
h_fuse_axial/radial: The factor of a uniform spacing at fuselage surface block interfaces in the axial and radial directions. I.e. spacing = h_fuse_axial/radial (edge_length/n_chord).
bl_fuse_axial/radial: Bunching law on fuselage surface blocks in the axial and radial directions.
3.2 Running the script
There must exist the geometry file from the geometry script (for example wbt.tin), the blocking file from the blocking script (or a manually modified version) as well as the meshing input parameter file (for example meshing.params).
The script is run as described above. On completion the "meshed_blocking_file" will have been created, as well as the "grid_file" if export is requested. In addition, boundary conditions recognized by jetstream are written to the "topo_mulcad_out.top", "family_boco", and "family_topo.fto" files which can be turned into the grid connectivity file with the "convert_connect" utility.
The instructions here are up to date with the October 29, 2013 git commit with ID: 7f8d41510a6db547b38dfdb3c52c76a3f98c870b
Sample geometries are in ~thomas/git/ICEMCFD_Scripts/wing-body-tail_620blk/examples
These scripts are used for generating 620 block grids around a wing-body-tail configuration. The process is broken into three stages:
The script at each stage can be run as follows. In the ICEM terminal session ("med>" is the prompt) point to the correct input file for each stage by doing:
Then each stage can be run by doing:
This will read the input in the corresponding files defined by geometry_input, blocking_input, meshing_input and execute the scripts.
The scripts can now not be run through the replay GUI. This is because certain features are not available when using the replay GUI as opposed to batch mode.
0. Geometry Preprocessing
The geometry required by the geometry script has several requirements:
- The base geometry which you start with must have a certain form. There must be 1 fuselage surface named s.f, 4 main wing segments on the lower and upper surface, each named s.wN.ls, s.wN.us where N = 1,2,3,4,5 and segment 5 is a small tip cap. The tail must have at least one main segments on the lower and upper surface, each named s.tN.ls, s.tN.us where N = 1,5 and segment 5 is a small tip cap. Two main surfaces are actually required on the tail. There is an option in the geometry_input file called 'split_tail' which can be used to do this automatically. However it is not stable in all cases. Thus, it is HIGHLY recommended that you manually set the main tail surfaces in the spanwise direction to form s.tN.ls, s.tN.us where N = 1,2,5.
- The (u,v) surface parameters must also be oriented as follows: 1) Fuselage: u = length direction, v = radial direction, and 2) Wing/Tail: u = spanwise direction, v = chordwise direction. Those surfaces which come out of Genair should adhere to this, but the surfaces may need to be adjusted in certain cases
- The wing segment 1 must intersect the fuselage. If needed, the wing can be manually shifted inboard slightly to provide this intersection if it is not already present.
- The fuselage cannot have a hole where the wing intersects it.
- If the original geometry file contains other parts and/or surfaces they will be ignored by the scripts, unless the part name begins with "PART_", in which case the part and its contents will be deleted.
This step is done manually by you.1. Geometry Processing
The base geometry (for example wbt_base.tin) which has the naming conventions as described above, must be present.
A geometry input parameter file is required (for example geometry.params), with the options described below. A sample of which can be found in the git repo as "geometry.params".
1.1 Input parameters
1.2 Running the script
There must exist the base geometry file with the naming convention described above, and specified in the "base_geometry_file" option. The script is run as described above. After running the geometry.rpl script, the "geometry_file" (for example wbt.tin) will be created.
2. Blocking
As long as the geometry script has been run successfully, the blocking script should work. A blocking input parameter file is required (for example blocking.params), with the options described below. A sample of which can be found in the git repo as "blocking.params".
2.1 Input parameters
2.2 Running the script
There must exist the geometry file from the geometry script (for example wbt.tin) as well as the blocking input parameter file (for example blocking.params).
The script is run as described above. On completion the "blocking_file" will have been created.
At this point, if changes must be made (i.e. manual edge flaring, etc) it should be done and saved as a blocking file again. Any manual changes done to this file must not change the number or names of vertices and/or blocks or the meshing script will not work!
3. Meshing
There must exist the geometry (e.g. wbt.tin) and blocking (e.g. wbt.blk) files, as well as a meshing input parameter file present (for example meshing.params), with the options described below. Samples of which can be found in the git repo for sample fitting grids ("fitting.params"), Euler grids ("euler.params") and RANS grids ("rans.params").
3.1 Input parameters
Fluid/farfield meshing inputs:
General geometry mesh inputs:
Fuse specific mesh inputs:
3.2 Running the script
There must exist the geometry file from the geometry script (for example wbt.tin), the blocking file from the blocking script (or a manually modified version) as well as the meshing input parameter file (for example meshing.params).
The script is run as described above. On completion the "meshed_blocking_file" will have been created, as well as the "grid_file" if export is requested. In addition, boundary conditions recognized by jetstream are written to the "topo_mulcad_out.top", "family_boco", and "family_topo.fto" files which can be turned into the grid connectivity file with the "convert_connect" utility.