CFD Collateral

Preparation of Geometry Models for Mesh Generation and CFD

Issue link: https://resources.system-analysis.cadence.com/i/1472078

Contents of this Issue

Navigation

Page 7 of 14

Preparation of Geometry Models for Mesh Generation and CFD 8 www.cadence.com Sources of Geometry Model Unsuitability All of the geometry modeling techniques described above can produce geometry models that are perfectly suitable for mesh generation and CFD simulation. In practice, however, their use often presents challenges for the downstream user. Rather than cast this discussion in terms of "quality" - or its counterpart, sloppiness - it is presented in terms of suitability. The same geometry model may be suitable for one type of meshing such as CFD and unsuitable for another. Suitability must be assessed within the greater context of one's unique simulation requirements and unique simulation toolchain. In theory, all users should have equal access to all geometry modeling technology. In practice, users are limited by what their simulation toolchain supports. For example, if a mesh generator doesn't support Sub-D surfaces, their relative benefits are moot. These types of scenarios are not explicitly considered in the following discussion. Interoperability & Translation The first challenge faced by the practitioner is the transmission of a geometry model from the originating application (MCAD) to the downstream applications (meshing and CFD). There are at least three main paths for this transmission: file I/O, direct interface to CAD, and CAD-embedded simulation. Interoperability by File Exchange It is fair to say the most widely employed interoperability method for geometry models is transmission via a file. A wide variety of geometry model file formats are available including standard formats (e.g., IGES, STEP), native CAD and kernel formats (e.g., Creo, Parasolid), and de facto standards (e.g., STL). The issues associated with file exchange are mainly practical in nature and center on the accuracy and completeness of what is written and read from the file. However, mathematical accuracy is affected by representation and tolerance issues. Standards and Specifications All file formats suffer from a common problem; nothing prevents them from being written in ways that violate their specifi- cation. Any standard-conforming application that attempts to read these violating files is likely to fail. IGES in particular, has a notorious reputation as a problematic format, an undeserved reputation. When exported and imported correctly according to the standard, the format supports geometry and topology up through B-Rep solids. Yet in practice, one often encounters deviations from the standard that make file import problematic. For example, a trimming curve in an IGES file can be defined either in 3D space or in the 2D parametric space of a surface. The flag specifying that choice is often set incorrectly in the file by the sending application such that the receiving application will not be able to find the curve. As a second example, the IGES standard explicitly forbids certain curve types from being used for intersection curves. Yet one often encounters files that ignore that restriction to the chagrin of the receiving application. The STL file specification lacks a color attribute for a discrete geometry example of non-conformance to specification. Yet many implementers have chosen to add a color specifier for the entire object or each facet. Unfortunately, how the color is specified can differ among these format extensions. The independent extension of de facto standard file formats is a common source of geometry model interoperability problems. Non-standard files force downstream applications to write their file readers defensively by accounting for every non-standard occurrence encountered over years of use. Implementations also utilize a practice called "flavoring" in which the reader or writer is tailored to the particular dialect of the file standard implemented by the sending or receiving application, respec- tively. A mesh generator must be flexible enough to support a wide variety of geometry model file formats so that you can work with geometry provided by different sources. In addition, the ability to automatically assemble the model into a solid that's ready for meshing is invaluable. https://www.pointwise.com/theconnector/2015-September/Tips-Tricks-Reading-Writing-Files-. html] Geometry model files, especially in organizations practicing the master model concept, contain data well in excess of geometry and topology such as attributes (e.g., colors, names), manufacturing details (e.g., materials, finishes), and extra- neous geometry (e.g., law curves). It is important to recognize that many readers skip data not deemed relevant to the receiving application's needs. Sometimes these omissions are limited to non-geometric data, while in others, only a subset of geometry and topology entities are imported (e.g., the receiving application may only support certain types of curves and surfaces).

Articles in this issue

Links on this page

view archives of CFD Collateral - Preparation of Geometry Models for Mesh Generation and CFD