Issue link: https://resources.system-analysis.cadence.com/i/1472078
Preparation of Geometry Models for Mesh Generation and CFD 9 www.cadence.com Translation & Representation Relative to B-Rep models, discrete geometry is generally less ambiguous when translated and shared through files. However, the translation of a B-Rep model through the interoperability toolchain is a potential source of data loss and the introduction of errors. While the general mathematics of analytic B-Reps is well known, how they are implemented in the MCAD software and the receiving applications may differ significantly, especially the tolerances used in surface-surface intersections and related computations. Common types of necessary translations are the conversion of implicit surfaces to splines and the splitting of surfaces at slope discontinuities, the latter driven by the requirement that most algorithms for spline evaluation assume slope continuity. A single file exchange may require multiple translations only exacerbates the problem. For example, assume the file reader used by meshing software is licensed from a 3rd party. The number of translations required to import the geometry model is three: CAD to file, file to reader, reader to mesher. Exchanging a geometry model using a native CAD file format (e.g. CATIA, NX) should be the least problematic. It can be safely assumed that the CAD software can accurately and completely write its native format, thereby eliminating one translation from the illustration above. [There are several benefits to importing CAD geometry from a native file rather than from a neutral file. By eliminating the need to convert from CAD to neutral and then from neutral to mesher, you halve the number of conversions and, therefore, halve the potential for translation errors. Most modern CAD systems automatically produce 3D solid models that are then imported directly into Cadence ® Fidelity™ Pointwise ® Mesh Generation. Working with solids help you ensure that your mesh will be watertight. When you receive geometry data in different formats from several contractors, vendors, and partners, there's no longer a need to translate them into a common format. https://www.pointwise.com/theconnector/2012-January/Seamlessly- Working-Native-CAD-Data.html] To mitigate this issue, some CAD software providers have made available tools to read and write their native format. For example, Robert McNeel & Associates operate the openNURBS Initiative [31], which provides a software development kit (SDK) for reading and writing their native 3DM file format. A downstream application implementing the openNURBS SDK will likely have few problems importing Rhino's 3DM files. Lacking such a native SDK, importing a geometry model from a CAD native format typically involves using 3rd party CAD reading libraries in the receiving application. These libraries remove the programming burden of writing from scratch readers for each native format. However, it is important to note that, unlike standard formats, file specifications are not usually published for native CAD formats (because they may be considered proprietary by the software vendor). Therefore, native CAD reading software is developed by reverse engineering CAD files. The resulting libraries can be quite robust and richly featured. From a practical standpoint, these 3rd party readers will necessarily lag behind updates to the file's contents made by the CAD software vendor. [A mesh generator requires various geometry modeling capabilities to prepare and supplement the model provided by the CAD software. https://www.youtube.com/playlist?list=PLWHat3P46AwD8KpRdVHPlZHtN0i6r_qTs] For discrete geometry file formats, the situation is much less problematic because these formats are mostly open, including de facto standards (e.g., STL, 3MF, PLY, OBJ) and ISO standards (AMF, JT), and the geometry data format is relatively simple to parse (despite the complexity of the geometric shape) (i.e., points and facets). Interoperability by Direct Interface To minimize the potential data loss due to translations of a geometry model through intermediate format(s), an alternative approach is for the receiving software to directly interface with the CAD software through an application programming interface (API). Most MCAD vendors provide an SDK and API through partner programs (e.g., Dassault Systemes' CAA, Autodesk's ADN). The SDK's libraries are built into the receiving application which issues function calls through the API directly to an instance of the CAD software to interrogate the geometry model (e.g., surface evaluations, mesh point projections). A receiving application would implement a direct interface for each MCAD platform from which geometry models will be received. This limitation should not be too severe within a single organization or a group or organizations that have standardized on a single MCAD application. To alleviate the need for multiple implementations, the receiving application could implement a CAD-neutral API such as CAPRI [43]. Using a CAD-neutral API allows the interface to multiple CAD systems to be implemented once. A drawback of such an approach is that the API has to be written to the lowest common denominator of the capabilities offered by the supported CAD systems. Whether one uses proprietary or open SDK, direct interfaces require access to (i.e., a license for) the CAD software. Use of this asset may not be available in all organizations.