Geometry acquisition and grid generation, in an early design environment where geometry is continually updated can be very time consuming. The results are unacceptably long turnaround times for complex problems. In an ideal design environment, parametric models are used where evaluation of alternative designs can be implemented into the analysis environment effortlessly. The grid generation software used should provide automated, accurate tools that are directly linked to the parametric geometry model in the same design environment.
In a rapid design process, the geometry "thrown over the wall" approach from one discipline to another with no consideration for strong links between design and analysis increases design cycle time and cost. "Thrown over the wall" is the approach for all grid generation software including the early versions of ICEM CFD. Geometry was translated into a "third party" format (IGES, PDES, VDA, STEP etc.) and the grid generation system translated it back into it's own environment (including all the unnecessary information for CFD analysis). This was a time consuming effort because the geometries required an excessive amount of time for organization, clean up and geometry extraction from the translated geometry. In addition, users often ran into the well-known problems of "surfaces don't match", "holes in geometry", "overlaps in surfaces", and "missing surfaces". Currently few software tools are being developed to handle these problems effectively. Considering the features in today's CAD systems, the bothersome problem with a generic translator is the loss of parametric geometry information. As it translates to grid generation: if any parametric design changes occur, the translation process reruns, and the same problems have to be endured again.
The process for geometry acquisition in ICEM CFD through common translators is shown in Figure 1.
The ICEM CFD IGES translator translates NURBS surfaces, trimmed NURBS surfaces, and NURB curves into the ICEM CFD geometry module's native format. The translation into ICEM CFD also has to maintain accuracy issues, but since the size of the problem is not known beforehand, translation is usually repeated a few times if the geometry has complex features. After the geometry is translated into ICEM CFD's geometry module, the user has to organize geometry, clean up unneeded information, extract curves and points, and build surfaces to represent outer boundaries like inlet and exit faces. In order to produce an "Intelligent Geometry for Mesh Generation", the geometry is organized using the family concept. The user defines a set of families (usually representing the CFD analysis conditions) and groups the geometry into these families. During this process mesh size requirements and boundary conditions are attached to the family information. This geometry input is unified through all of ICEM CFD’s mesh generation modules.
Data translation through a neutral format creates several problems for a grid generation system. With IGES, for example:
The quality of data produced by the IGES pre-processors varies widely. To achieve robust translation, the receiving post-processor must be tuned or flavored for each specific pre-processor. Since an IGES post-processor is usually designed to handle generic IGES files, the specialization needed for a specific pre-processor is often difficult to achieve. In some cases, the data model of the sending CAD system is poorly matched to the IGES data model and the quality of the model is significantly degraded in its IGES representation.
Limitations in the IGES interface impact the data flow between the CAD system and grid generation software. For example, in most CAD systems, it is possible to add the CFD family meta-data using native features of the CAD system like entity naming or attribution. In some cases, the CAD system IGES pre-processor will not output this data and in no case is this data handled in any standard way. STEP will probably address this issue, but STEP translators are still immature and not yet widely supported.
These issues are not unique to grid generation. They apply to most downstream applications that make use of CAD geometry. Many U.S. companies have attempted to address data translation issues by requiring a single CAD system for the entire company. Integration of the grid generation system with the CAD system using a direct CAD interface significantly reduces the problems associated with data translation and has obvious advantages:
The ICEM CFD Direct CAD Interface module described in Figure 2 provides this environment.
The ICEM CFD direct CAD interface works with major CAD systems such as CATIA, ICEM Surf, Pro/ENGINEER, SDRC I-DEAS, and Unigraphics. The software provided executes inside the CAD system. The geometry is selected in the CAD system and tagged with information (made Intelligent) for grid generation such as boundary conditions and grid sizes etc. This intelligent geometry information is saved with the master geometry. If there is a parametric change in the geometry, all the user has to do is a simple file save for grid generation. The user can immediately re-calculate for unstructured tetrahedral grids. The computational grid can be updated, since the topology information remains the same, by using a replay file for multi-block structured grids and hexahedral unstructured grids. This approach also maintains the geometry accuracy requirements.
For each CAD system supported the direct CAD interface is implemented using the native application extension utilities of the CAD system. The interface is run as a plugin application within the CAD system normal user interface and presents the CAD system normal look and feel to the user. Within the direct CAD interface module, the user:
The geometry is transferred to the grid generation system through a save operation which writes an image of the collected information and the entities within the CFD families to a tetin file, the grid generation system native geometry format. This file is read by the grid generation application in the initial steps of the actual grid generation process. It is important to note that the primary specifications of the CFD grid reside in the CAD model. In many cases, the CFD grid can be updated in response to parametric changes in the CAD model by rewriting the tetin file and rerunning the grid generator in batch mode.
1.1 SIMPLE WING FUSELAGE GEOMETRY
The geometry shown in Figure 3 was created using the Unigraphics V13.0 modeling module. This geometry was created using tools common to all the CAD systems with ICEM CFD direct CAD interfaces. Our objective here is to utilize the ICEM CFD direct CAD interface to create a computational grid with the initial configuration and then replay the grid generation after we increase the cord length of the root airfoil from 100" to 200".
This wing-fuselage with a cylindrical outer body is built using parametric solids. The geometry of the airfoil is sketched in a 2-D plane using simple conics and lines. The cord length is 100" and we will use this length as a parameter to change the airfoil shape thereby changing the whole wing-fuselage configuration. A sketch of the airfoil is created in the plane going through x=0, y=0 and z=0. This sketch is transferred in the z direction approximately 300" out and approximately 100" in x direction and scaled down by half. This produces a wing shape with a sweep angle of about twenty degrees. The solid wing geometry is built using simple extrusion. A curve mesh free form surface feature is created to complete the wing tip. A solid cylinder body from 0 to 180 degrees is created to represent the fuselage. Later the wing geometry and the fuselage are united to represent a single solid. Under free form surfaces, a fillet surface with a 5" radius is created at the root of the wing where it intersects with the fuselage and is added to the wing-fuselage solid. A second cylinder is created to represent the outer boundary. The solid made from the wing, fillet surfaces and the cylinder are subtracted from the outer boundary to create a single solid. Figure 3 also shows the close-up of the initial wing geometry at the wing root area and the parameters, the chord length and the maximum height of the airfoil, all available for parametric changes.
After the geometry is created, the ICEM CFD direct CAD interface is invoked without leaving the CAD system. The extraction of the surfaces from the solid is done with a single selection. Using the define families option, the families INLET, OUTLET, OUTER, FUSELAGE, UPWING, LOWING, WTIP and FLUID are created. Appropriate surfaces, edges and points extracted from the surface edge curves are grouped into these families and mesh sizes are defined in the process. During the grouping, the direct CAD interfaces 's blank entity option is used to blank geometry from the display to simplify the entity selection operation. The ICEM CFD direct CAD interface writes a file, which can be utilized by ICEM CFD Hexa and ICEM CFD Tetra, to create a multi-block structured and a tetrahedral unstructured grid respectively. Figures 4 shows the structured and unstructured grids created using ICEM CFD.
For multi-block structured grids the replay file is saved as the multi-block structure is created. It is later replayed on the geometry with the 200" chord length wing-fuselage configuration after the initial geometry is changed parametrically.
Using the edit sketch tool in Unigraphics, the wing root sketch is edited and the chord length is updated from 100" to 200".
When the geometry update button is selected, the geometry shown in Figure 6 is created.
At this point all that is needed is to re-write the information into the file. ICEM CFD's grid generation modules are utilized to create the computational grids in Figure 6. For the multi-block structured case, the replay file saved from the initial configuration is played back on the new geometry. The tetrahedral grid is simply recomputed.