Posted to compgeom-discuss by Ernst Mücke (epm@ansys.com), June 17, 1996

Notes from someone new in the "CAD Zoo"

These are some remarks following-up on a recent posting by Paul Heckbert in the "Application Challenges to CG" / Taskforce thread. If you want, it is an informal treaty on CAD geometry data and the related problems in meshing and analysis. There are some further references attached in the end.

Output from some CAD systems is near-garbage (e.g. poorly designed file formats, buggy software), making mesh generation of these models very difficult. [Ernst Mücke, ANSYS, personal communication] Perhaps more computational geometers should be involved in file format standardization efforts.

The truth is, computational geometers are already involved in these standards. Of course, it is the "other breed" we are talking about here: the "modeling, curves & surface" people.

Whether or not the standards are poor and improvable is also not the issue. The standards exist, or are "in the works" for decades now, and we all have to live with them. Some of these formats also go well beyond geometry; rather, they cover the whole manufacturing process. Industry and international organizations invested a lot of time and money in this; and they are not waiting for us to help them... Some entry points to this world, for example the IGES and STEP standards: [1, 2,3]

Nevertheless, here is a potential new play ground for the compgeom community:

Find new solutions to clean up the CAD Zoo

The problems:

(I) Geometry transfer/translation.

If you accept the paradigm of a geometry file format is very much like a (programming) language, then the problem essentially compares to writing translators from, say, Russia to English. This is a very hard problem.

Different file formats (external; internal: geometry APIs, data structures) use different "languages" to describe geometry, and they are not necessarily compatible. Eg, one is NURBS based, the other B-spline based (I hear this alone is already hard enough, but I do not yet know too much about it). A trivial, but in the end rather tricky example we encountered recently: format A knows the concept of "unbounded plane," format B does not.

The problem gets even worse, because vendor A simply HAS to have an output function for format B... to satisfy marketing (and it better be yesterday!). The result are files with geometric descriptions of rather poor quality. Having to deal with these "near garbage" files is unavoidable. You might ask:

Why is it impractical for software X to simply say 'invalid input file'?

Answer: Then, nobody will buy your product. "Poor quality" geometry files exist in the thousands, and the customer will give you k of them as benchmark files. "Code evaluation" contracts will state as a requirement that x% of these have to be successfully transfered. If not, no deal.

Why can we not simply re-generate better, garbage-free CAD files?

Many reasons... time & money, and reality. The original design software might not exist anymore. Today's corporate climate might have "eliminated" the designer who originally did the model, and to start from scratch is not feasible.

Geometry files have to be viewed as regular "data" ... and real-life data is almost always "dirty." Re-acquisition of the data is rarely possible. Here's the file... Read it or leave it! Ergo, problem 2:

(II) Geometry transformation

The job: Create analysis models, ie, geometries suitable for meshing, from incomplete or topologically inconsistent descriptions.

This is the reality. Every good package should be able to do this (and every package claims to be able to do it), but I still have to see one that actually can do it, with a reasonable success rate. This is definitely a hot topic. For an example product, see [4].

How much "garbage" can you find in these files? A lot. Topolocal information might be missing or outright wrong. Edge loops might be oriented wrongly, whole faces might be missing, ... For whatever possibly can go wrong, you will sooner or later encounter a file where it actually does go wrong. It is common understanding that this problem will never be solved with no user interaction at all, but we want as little interaction as possible. Also, the software should be able to point the user to possible problems.

(IIa) Fixing, cleaning, healing

Duplicates, improper overlaps, gaps beyond tolerance, inconsistent or missing topological information... Basically, you cannot rely on anything when reading a geometry exchange file. In fact, you have to be prepared to go to the extreme and dump all the topological information and rebuild the topology from the geometry information found in the file: point coordinates, polygon meshes, surfaces.

One possible approach is to also dump the geometric surface description (NURBS, splines) and work with the polygonal surface mesh only (surface tessellation/triangulation). Some call this "micro topology" ... others call it modeling with (simplicial) complexes.

(IIb) De-Featuring

The goal is to build the geometry and topology of the analysis model which can then be fed to the mesher. It is often desirable to simplify and "de-feature" ... How? Good question.

Micro topology might be a possible answer; eg [5]. Of course, some people will always want their NURBS etc., which yields to a new problem:

creating smooth surfaces from polygon surface meshes; eg: [6,8]

And, of course,

simplifying polygon meshes; eg: [7]

So?

Today we have the pipeline: CAD -> analysis model / mesh generation -> FE solver... and each "->" seems to mean communication between disciplines (or the lack thereof), and "feeding the solver" is the main purpose. Tomorrow, we want to close the pipeline and form a cycle: variational design, design optimization (plus animation, for marketing). Obviously, the problems are challenging, and, eg, dynamic mesh generation is not the least of them. It is also a robustness question, and achieving real robustness becomes more and more an issue. I think that is good for the compgeom community. Industry might really need us. A major re-focus towards engineering seems to be in order, though.