I heard from a oldtimer that there was a time when CAD Interoperability wasn’t a problem. He said it didn’t become a problem until the second CAD program was written.
I’m always interested to learn more about the underpinnings and sources of interoperability problems, especially in the realm of 3D solids. Recently, I came across a paper by Jianchang Qi and Vadim Shapiro, published in the Journal of Computing and Information Science in Engineering, entitled Geometric Interoperability with Epsilon Solidity. The abstract caught my attention:
Geometric data interoperability is critical in industrial applications where geometric data are transferred (translated) among multiple modeling systems for data sharing and reuse. A big obstacle in data translation lies in that geometric data are usually imprecise and geometric algorithm precisions vary from system to system. In the absence of common formal principles, both industry and academia embraced ad hoc solutions, costing billions of dollars in lost time and productivity. This paper explains how the problem of interoperability, and data translation in particular, may be formulated and studied in terms of a recently developed theory of epsilonsolidity. Furthermore, a systematic classification of problems in data translation shows that in most cases epsilonsolids can be maintained without expensive and arbitrary geometric repairs.
I will tell you, at the outset, that epsilonsolidity is not something that a the average engineer is likely to understand. No worries—it’s the background information on interoperability issues that makes this article really interesting to nonPhDs. While you may download a copy of the article yourself (it’s available for at the link above), I’m going to excerpt some of the interesting bits here.
A typical geometric data translation problem between two systems is illustrated in Fig. 1. A geometric representation can be thought of as a composition of geometric primitives by rules specific to a given representation scheme. In data translation, such a representation is transferred explicitly by various translators. However, the meaning of any representation is determined by the corresponding evaluation algorithms that usually also differ from system to system.
Perhaps the most widespread difficulty arises from the mismatch between the accuracy of the geometric representation and the precision of the evaluation algorithms used in a modeling system. For example, if the sending and receiving systems rely on different precisions, the points on surface intersections may classify differently (ON or OFF) in the two systems. As a result of such data translation, many design, manufacturing, and analysis tasks cannot be performed in the receiving system until the geometric models are either corrected “healed” or remodeled.
Many references have illustrated various data translation problems. We will not attempt to add to the long list of wellknown difficulties, but rather consider a few carefully chosen but real examples that provide important insights into the nature and intrinsic sources of the general translation problem. The choice of commercial systems in the following examples is not important, because the problems are generic. The described difficulties are representative of the current state of the art and do not indicate inferiority of any specific systems.
Example 1. The first example illustrates the wellknown fact that even minor changes in geometric representation may invalidate the model, causing irreparable difficulties in data translation. In this case, the model shown in Fig. 2(a) is created in SolidWorks and saved in the STEP (STandard for the Exchange of Product model data) neutral data exchange file format. Then the STEP model is reloaded into SolidWorks, but was found to be invalid. The builtin healing algorithm attempted but was unable to recover a valid solid, generating instead the model shown in Fig. 2(b). The above situation is common when geometric representations are archived in another nonnative format. For example, saving the same model in ACIS format instead of STEP leads to similar difficulties. This double data translation corresponds to a situation in Fig. 1 where no new errors are introduced in the evaluation algorithm by the receiving system (because it is the same as the sending system.) The problem arises because primitives in the boundary representation—in this case, filleting surfaces and intersection spline curves in the original model—are mapped approximately into the STEP format by the translator. (Similar translation problems are common whenever tangent surfaces are approximated in the course of translation.)
Example 2. The second example Fig. 3(a) is intended to show that even when geometric healing is successful in repairing the received model, the result may not be always acceptable. The double translation procedure is identical to the first example, except, in this case, the healing algorithm is successful and generates the model shown in Fig. 3(b). The smooth blends near the corner have been replaced by sharp corners in the translated model; such drastic changes are not acceptable for engineering applications where blend radius is an important parameter.
Example 3. The third example shows that differences in precision of evaluating algorithms are also key ingredients of the translation difficulties, even when the changes in geometric representations are negligible. The solid model in Fig. 4(a) was created in SolidWorks using only planar and cylindrical primitives with integer and fixedprecision coordinates. The dimensions of the model range from 0.001 mm (the minimum thickness of the part) to 1000 mm (the length of the part.) The model is translated into ProEngineer through the STEP format, and both formats support exact representation of the original primitives. Therefore, it is reasonable to assume that the changes in geometric representation during the translation process remain negligible. Figure 4(b) shows the translated model after it is evaluated in ProEngineer. It is certainly a valid solid, but with a drastically different shape that is not likely to be consistent with the intended use of the original solid.
This last example demonstrates clearly that a geometric representation alone does not uniquely define a set of points. Rather, the set of points, and therefore all its properties, are also determined by the properties (in particular, precision) of the evaluation algorithm. In this case, Solidworks relies on incidence testing algorithms with a default tolerance of 10E6 mm, while ProEngineer uses a relative tolerance of 10E6 times the maximum size of the bounding box of the model measured in meters. The latter effectively determines the smallest feature size to be 10E6 m, matching the minimum thickness of the model in Fig. 4(a). The evaluation algorithm includes the process of merging what ProEngineer now considers coincident geometric entities, and results in the “repaired” model shown in Fig. 4(b).
It is generally accepted that modern mass production and most of the manufacturing technologies of the past century would not be possible without the concept of interchangeable parts. The doctrine of interchangeability dictates that a mechanical part may be replaced by another “equivalent” component without affecting the overall function of the product….
With the emergence of computeraided design and manufacturing over the last 40 years, most engineering tasks today are performed virtually, by simulating them on computer representations in place of physical parts and processes. One could argue that virtual engineering has become an enterprise for manufacturing virtual components themselves. The object of manufacturing, in this case, is the computer model of a physical artifact, and the manufacturing processes are the above computer transformations involved throughout the life cycle of this model. It is our belief that tolerancing and metrology of interchangeable virtual components is as important to the future of virtual engineering, as interchangeability of mechanical components was critical for emergence of mass production and modern manufacturing practice.
It’s worthwhile to note that the research presented in this paper was supported in part by UG PLM Solutions (now known as Siemens PLM Solutions.)
After I discovered this paper, I passed along a copy of it to Dr. Paul Stallings, VP of R&D for Kubotek USA. Dr. Stallings is one of the heavyhitters in the geometric modeling kernel world. He wrote back to me, and his comments were far more than just interesting. I’ve gotten his permission to share them with you, and will do so. Tomorrow.

http://www.evanyares.com/doesthemodelingkernelmatter/ Does the modeling kernel matter?  Evan Yares