Survey Results – Mesh Generation and CAD Interoperability

DrivAer-bottom-halfOur survey on mesh generation and CAD interoperability collected 136 responses and provided some insight into file-based transfer of B-Rep/NURBS geometry models yet only scratched the surface of the issues involved.  

It is easy to joke about how difficult and challenging geometry modeling and geometry interoperability are. (“Geometry modeling is to mesh generation what turbulence modeling is to CFD.”)

It is easy to appreciate the deleterious effects of the lack of interoperability on your CFD process. (You can’t mesh the geometry that didn’t import. And that’s just the most obvious of the many manifestations of poor interoperability.)

It is much harder to discover the causes of poor geometry interoperability.

The survey you responded to was just a first attempt to determine whether something we observed at the 1st AIAA Geometry and Mesh Generation Workshop (GMGW-1) was real or not. What we saw at GMGW-1 was that the vast majority of participants (albeit a small sample size) used the IGES file of the HL-CRM as the basis for meshing despite being offered other formats (NX, Creo, Parasolid, STEP).

This intrigued us. Conventional wisdom says that the native CAD format of the geometry should be preferred because it is less likely to experience translation problems. And from a practical standpoint, using the native file saves work – you don’t have to translate the file into a different format.

We asked, you answered, and here are the results. Thank you to the 136 respondents. Their email addresses were the answer to the first question which is why the results here begin with question #2.

Q2: What mesh generation software do you use?


The main takeaway from the answers to Q2 are that the survey results apply to a wider range of meshing software other than just Pointwise. (135 answers, 1 skipped)

Q3: What geometry model type do you use primarily?


Nearly 80% of respondents primarily use NURBS models for their meshing and CFD versus faceted models.

Geometry models composed of NURBS (non-uniform rational B-Spline surfaces) are the types created by today’s major CAD systems. Furthermore, these NURBS are usually assembled into solid models using a boundary representation (B-Rep) or constructive solid geometry (CSG) data structure. Faceted geometry models are just a mesh, but likely one that isn’t suitable for direct use in a simulation.

Because the purpose of this survey was to focus on NURBS-based models, respondents who answered “Faceted” here were directly sent to Q9. (131 answers, 5 skipped)

Q4: How do you get geometry models into your mesh generation software?


The respondents to this survey overwhelmingly (94%) use a file-based method of getting geometry models from their design software into their meshing software.

Other methods for obtaining geometry are not well-represented is this survey’s responses, with meshing (and presumably CFD) performed in the CAD software garnering only 3%. Direct CAD access, by which the meshing software would directly obtain geometry from the CAD software through use of its API, is only used by 2% of the respondents.

Because the purpose of this survey was to focus on file-based interoperability, respondents who didn’t answer “file import” were directly sent to Q9. (102 answers, 34 skipped)

Q5: Do you have to preprocess, repair, translate or otherwise change the geometry model exported from your design software before importing it into your mesh generator?


In hindsight, this question was not precisely phrased. The need to repair the geometry model shouldn’t have been limited to “before import” into the mesh generator. It should have accounted for repair performed in the mesher as well.

Regardless, nearly 60% of respondents have to modify the geometry model exported by their design software before they mesh it.

Based on the notorious reputation of the topic of geometry model repair, 60% might actually seem like a low number. (92 answers, 44 skipped)

Q6: Briefly described how you have to change the model.

What follows is an edited list of what I considered to be typical responses. To make a long story short: fix gaps, remove excessive and unnecessary details, add missing pieces.

  • I find that I have to remove or repair small faces
  • Rebuild geometry that may have errors
  • Remove small features
  • Repair gaps to make watertight surfaces.
  • Issues are primarily with fine details such as thin features, fillets, edges etc.
  • Sometimes models need to be translated and/or scaled.
  • Clean the OML to remove any unnecessary features (screws, hinges, gaps etc….)
  • Create far field and other boundaries, patch some holes/gaps, etc
  • Defeaturing the CAD model and smoothing it by fixing gaps/overlaps of faces
  • We often get geometries that are not watertight, and need to be repaired
  • Close gaps, smooth some surfaces, eliminate unnecessary details.
  • Eliminate gaps, fix tolerances and alignment of surfaces.
  • defeaturing
  • Fill holes, delete unnecessary geometry
  • Things don’t line up.  There are gaps.  There are wiggles.
  • Repair, defeature, translate/scale, partition, etc.
  • I have to clean and simplify the geometry model; deleting the holes, deleting unnecessary faces and bodies, merging some edges and faces
  • Closing the opening i.e preparing watertight geometry for CFD analysis
  • defeature, simplify and make it water tight
  • Simplification and clean up excessive details
  • Sometimes some edges/faces have to be fixed, add domain boundaries, remove unnecessary details.
  • Model generally needs to be defeatured and made water-tight. Often needs to be scaled and translated as well.
  • Typically a combination of idealizing the geometry to remove unnecessary complexity

(46 answers, 90 skipped)

Q7: What geometry model file formats do you primarily import into your mesh generator?


For file-based interoperability of NURBS  geometry models, standard file formats (IGES and STEP) are used by 72% of the respondents. The next most widely used formats are at least 50 percentage points behind with Solidworks at 22% and the Parasolid kernel’s format at 21%.

This mirrors what was observed at GMGW-1. Most people use standard versus native formats for file transfer. The next question delved into why that would be so. (89 answers, 47 skipped. This question allowed multiple answers which is why the percentages don’t total 100%.)

Q8: If you do not use native CAD formats, why not?


The responses do not indicate a clear, single reason why native CAD formats are much less popular than standard geometry formats. Some people aren’t given native CAD files while others operate within a CFD process predicated on standards. Some report that importing geometry from a native CAD format is less robust than importing from a standard format. And finally, some mesh generation software doesn’t support native CAD formats or the users don’t want to have to pay the added expense of native CAD support for those products that do not include it as part of their standard offering.

(72 answers, 64 skipped)

Q9: Share any comments, suggestions or feedback on Pointwise’s CAD interoperability.

An open-ended question specifically about Pointwise’s CAD interoperability closed the survey. For reasons of openness, I’ll share an edited sample of the results here.

  • I would like to be able to import native SolidWorks however my version isn’t supported (17/18).
  • The CAD guys work to create for me a clean OML that I then import into Pointwise.
  • Importing a specific OML from a complete part is just too painful for me b/c all the internal details are in our models.
  • The onus is on the structures guys to give me a clean geometry.
  • I could use the Catia V6 import, just have not got to it!
  • One of my great disappointments in my 38 years in the CFD development/application world is the move to compartmentalize the sub-aspects of the CFD analysis process.
  • Need functionality to repair cracks and gaps.
  • Model should not require any simplification to be able to be meshed. The mesher should be able to work with the direct CAD data.
  • There is also a perception among some users that using IGES or STEP may help simplify some of the geometric features found in native CAD formats.
  • I cannot believe that a survey on what geometry is typically used to import into a CAD tool resulted in the IGES format.
  • When possible, push for a common open format. STEP and IGES currently lead.
  • It would we very helpful to add faceted geometry manipulation utilities.

(36 answers, 100 skipped)


I only know enough about statistics to know that sample bias exists. I doubt that our respondents represent a statistically valid sample and am fairly certain the results shown here are not universally applicable across the entire CFD world. Having admitted that, there are some conclusions that can be made.

Standard File Formats Are Preferred

The results of this survey support what was observed at GMGW-1. Most geometry model file import for mesh generation uses the IGES and STEP standards.

From a purely technical standpoint, the native format of the CAD software in which the geometry model was created should be preferred because it minimizes the number of translations required to get the data into the meshing software.

  • One translation: Native format to meshing software
  • Two translations: Native format to CAD file reader to meshing software

Use of a standard format like IGES or STEP requires more translations.

  • Two: CAD software to standard format to meshing software
  • Three: CAD software to standard format to CAD file reader to meshing software.

The translations are necessary due to differences in representation of the data in each of the systems involved. It is likely that the CAD system’s internal representation of a B-Rep or NURBS doesn’t match the same in a file format standard or in CAD reading software or in the mesh generator. Each translation is a potential contributor of errors. (Hence the adage, all engineering happens at the interfaces.)

Half to Two-Thirds of You Can’t or Won’t Use Native Formats

Pure technical reasons aside, the reasons against use of native formats begin with the practical. You either aren’t given native formats (31%) or your meshing software couldn’t read them if you were (17%). That’s 48% or nearly half of the respondents.

If you add the 17% of you who also have simulation processes that require the use of standard formats, we just eliminated 65% or nearly two-thirds of you as native format users.

If you were able and you could, I wonder how many of you would switch to a native format? Maybe the next conclusion answers that question.

Native Readers Aren’t as Robust

A robustness issue is the next culprit against use of native formats; over a quarter of you (26%) report importing geometry from native formats is less robust than importing from standard formats.

It is important here to remember that many/most native CAD format readers have been developed by reverse engineering the CAD vendor’s files. As good as these readers are, you can imagine that reverse engineering is not foolproof. Plus, you almost necessarily have a lag between a CAD vendor’s updated format and when the reader will support it.

If you consider native kernel formats (e.g. Parasolid, ACIS), it would be interesting to see if the robustness issue becomes moot if the CAD system and the mesh generator use the same kernel and can share the native kernel format. (The answer may seem obvious but I’ve seen stranger things throughout my career.)

Native Readers Are Too Expensive

The last portion (10%) of survey respondents who don’t use native CAD formats for meshing cite expense as the reason leading me to infer that native format support is an extra-cost item in your meshing software. Of course, “too expensive” is rather qualitative and makes it difficult to compare the cost of the native readers to the value those readers deliver in your CFD process.

Now What?

If most/all CAD systems can export geometry models to standard formats such as IGES and STEP, and two-thirds of you have to use standard formats, and a quarter of you report native formats as being less robust, why are we even bothering with native formats?

Despite the commentary above, there’s no reason why import should be less robust from native formats than from standard format. If you had seen some of the standard-violating data written by CAD systems to standard formats you’d agree with me.

How do we reduce to zero the number of you who have to repair the geometry? And exactly what are we talking about when we say “repair”?

We at Pointwise continue to invest in developing techniques for helping you get a meshable geometry model as quickly as possible. In addition to programming toward that goal, it’s likely we will ask questions about some of these subtopics in future surveys.

If you have insights into interoperability to share or questions you’d like answered, don’t hesitate to write them in the comments below.

Or if you’d like to try Pointwise (which includes a variety of native CAD readers for free) on your geometry models, request a free trial license today.




This entry was posted in News, Software and tagged , , , , , . Bookmark the permalink.

7 Responses to Survey Results – Mesh Generation and CAD Interoperability

  1. Andreas Schleth says:

    Counting the number of translations necessary is not the only interesting metric here. Count the number of necessary translators: For direct conversion you need a translator for every CAD-package/mesher combination (O n*m). With indirect conversion via a standardized format (STEP) each program would only need one translator (O n+m). So you should compare many errorprone 1:1 translators with one well tested translator from/to STEP.

  2. Pingback: This Week in CFD | Another Fine Mesh

  3. Pingback: This Week in CFD | Another Fine Mesh

  4. Pingback: This Week in CFD | Another Fine Mesh

  5. Pingback: For All Intensive Purposes, We Use the Acronym CAD Incorrectly | Another Fine Mesh

  6. Pingback: This Week in CFD - Another Fine MeshAnother Fine Mesh

Leave a Reply