These scripts can be found in a git repo here: ~thomas/git/ICEMCFD_Scripts/wing_168blk/scripts.git
The instructions here are up to date with the January 30, 2014 version with git commit ID: 1ced0d735ecef66fb5534bf847dfc4467687f172
Sample geometries are in ~thomas/git/ICEMCFD_Scripts/wing_168blk/examples
These scripts are used for generating 168 block grids around a wing. The process is broken into four stages:
Initialize
Geometry processing
Blocking
Meshing
The script at each stage can be run as follows. In the ICEM terminal session ("med>" is the prompt) initialize some shortcuts by
med> source init
The three primary steps are run by
geom <geometry_input_file>
block <blocking_input_file>
mesh <meshing_input_file>
which, if the <> are left blank, the defaults 'geometry.params', 'blocking.params', 'meshing.params' are used for input files.
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 wing surface with 5 surface segments and 1 tip cap, named s.wN.ls and s.wN.us where N = 1,2,3,4,5,6 for the lower and upper surfaces.
The (u,v) surface parameters must also be oriented as follows: Wing: 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.
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 wing_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_chord_offset_scaling: How the chord offset varies with local chord (i.e. (c/c_root)^wing_chord_offset_scaling).
wing_normal_offset: The height of the wing-adjacent blocks.
wing_normal_offset_scaling: How the normal offset varies with local chord (i.e. (c/c_root)^wing_normal_offset_scaling).
wing_tip_offset: Defined degree of block curvature at the tip.
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 wing.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.
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. wing.tin) and blocking (e.g. wing.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_normal: Number of nodes in the main fluid blocks in normal (z) direction.
n_fluid_chord: Number of nodes in the main fluid blocks in the streamwise (x) direction.
n_fluid_span: Number of nodes in the main fluid blocks in the spanwise (y) direction.
h_fluid: Spacing, in fraction of a uniform spacing, at block interfaces in the 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.
n_normal: Number of nodes normal to the surfaces.
h_normal_surface: Off-wall spacing, as a fraction of the root chord.
h_normal_interface: Normal spacing at the interface of the wing-adjacent block and the fluid block.
h_normal_centerline: Normal spacing around the wing on the centerplane of the wing.
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.
3.2 Running the script
There must exist the geometry file from the geometry script (for example wing.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 January 30, 2014 version with git commit ID: 1ced0d735ecef66fb5534bf847dfc4467687f172
Sample geometries are in ~thomas/git/ICEMCFD_Scripts/wing_168blk/examples
These scripts are used for generating 168 block grids around a wing. The process is broken into four stages:
The script at each stage can be run as follows. In the ICEM terminal session ("med>" is the prompt) initialize some shortcuts by
- med> source init
The three primary steps are run bywhich, if the <> are left blank, the defaults 'geometry.params', 'blocking.params', 'meshing.params' are used for input files.
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 wing surface with 5 surface segments and 1 tip cap, named s.wN.ls and s.wN.us where N = 1,2,3,4,5,6 for the lower and upper surfaces.
- The (u,v) surface parameters must also be oriented as follows: Wing: 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.
- 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 wing_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 wing.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. wing.tin) and blocking (e.g. wing.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:
3.2 Running the script
There must exist the geometry file from the geometry script (for example wing.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.