How does OpenVSP export the really usable file for CFD analysis

[Eric Cheng]

Hi all,

I really want to know why every time I create an airplane model in OpenVSP, when I want to import it to other CFD software for external flow field analysis, no matter if I export it in IGES format or STEP format, it always looks on some CAD software. Will there be a lot of bugs? (For example, surface failure, many small broken surfaces, not a solid model, etc.).

What I want to know is is there any way to realize that the airplane model created in openvsp can be imported into CFD software or external CAD software without damage?

The screenshot given below is a picture of my paper related to openvsp. It shows the process from building an airplane model in openvsp to inputting CFD software to generate aerodynamic meshes. 

[Rob McDonald]

I am not sure I fully understand your question, but I'll try my best.

CAD interchange files are notoriously difficult to deal with.  _Everyone_ has trouble moving files between different geometry tools, CAD, pre-processors, mesh generators, solvers, etc.

There are a few fundamental reasons for this.

First, these standards are industry designed consensus standards.  This means that when a bunch of companies got together to develop them, nobody wanted to cause themselves (or anyone else) undue difficulty.  Consequently, the standards end up very complex.  Often there are more than one (sometimes many) ways to accomplish the same thing.  Each of these ways reflects how one tool or another implemented some feature -- they wanted their way represented in the standard.

This results in files that are relatively easy to write -- but extremely difficult to read.

Someone writing the files (such as OpenVSP) can choose whatever part of the standard best suits their needs and implement just that.  Conversely, someone reading the files (CAD, a mesh generator, etc) will ideally need to be able to read any file ever written -- using any and every part of the standard.

Second, just because you have a file that conforms to the standard, it doesn't mean that every downstream tool will be happy with _how_ you've done it.  I.e. There is a lot to CAD data interchange that is not a part of the standards.  In fact, it isn't written down anywhere at all.

For example, look at an OpenVSP Pod.  By default, we write it out as a single surface that is closed at the nose and the tail (all the lines come to a point) and is closed circumferentially where the first/last curve along the surface coincide.  This is fully valid according to STEP and IGES standards.  However, many programs aren't happy with it.

Some programs (I think GridTool is one) don't like the fact that the nose and tail of a single surface come to closed points.  Either one is OK, but both of a single surface confuses it.  To work around this, we allow you to split surfaces along feature lines -- rather than read a Pod as a single surface, it comes in as eight (octants roughly).

Other programs don't like surfaces that come together as a point at all.  This represents a singularity and their underlying geometry engines do not handle it well.  They avoid creating singular surfaces in their native geometry representation -- but they just have to deal with whatever an imported file deals to them.

Less fundamentally, reality is very complicated.  OpenVSP can write several kinds of CAD interchange files.  Some of this code is pretty old (mature and well tested) -- other parts are relatively new (less mature).  They are trying to accomplish different things -- when combined with the challenges above, it may take some trial and error to get something to work well.

OpenVSP can write:

Untrimmed IGES OML Surfaces via the File... Export... menu

Untrimmed IGES Structure Surfaces via the File... Export... menu

Untrimmed STEP OML Surfaces via the File... Export... menu

Untrimmed STEP Structure Surfaces via the File... Export... menu

Trimmed IGES OML surfaces via the Analysis... Trimmed Surfaces... analysis

Trimmed STEP OML surfaces as a shell via the Analysis... Trimmed Surfaces... analysis

Trimmed STEP OML surfaces as a BREP solid via the Analysis... Trimmed Surfaces... analysis

Trimmed IGES structure via the Analysis... FEA Mesh... analysis

Trimmed STEP structure as a shell via the Analysis... FEA Mesh... analysis

Trimmed STEP structure as a BREP solid via the Analysis... FEA Mesh... analysis

The Trimmed files are relatively new and may have more challenges.

Within each of these choices, there are often several options to try to make things work with downstream tools.  You should experiment with different avenues and the options therein to find what works best for you.

In general, OpenVSP STEP and IGES files work pretty well with downstream tools.  There are good reasons for this.

1) The files are usually simpler, containing only the geometry significant for a particular analysis.  There is usually no need to de-feature a model.

2) The individual components are usually self watertight.  They are topologically simple.

3) Untrimmed files will not have slivers, gaps, and holes that can be introduced by the trimming process and characteristic of solid models.

4) Trimmed files are generally simpler (than CAD originating files) because their base topology was more simple.

It looks like you're using GridTool / VGRID.  I took GridTool / VGRID / USM3D training more than twenty years ago, so my knowledge is rusty...  But I have some level of familiarity.

As I recall, GridTool can only read in a very limited set of IGES entity types (including entity 128) (they never tried to be a universal reader).  This is good news -- OpenVSP loves writing Entity 128's!  So, as a start, you should use this approach...

Untrimmed IGES OML Surfaces via the File... Export... menu

The options menu for this is here:

You might also try 

Trimmed IGES OML surfaces via the Analysis... Trimmed Surfaces... analysis

Maybe it will work, maybe it won't.

I do not think there should be any reason to use Rhino as an intermediary (unless you are modifying the geometry, adding fillets, etc).  You should not need it as a conversion tool for OpenVSP to GridTool.

If you are using it to modify the geometry (add fillets, high lift devices, make a shell model a solid, etc.) then OpenVSP only has control of what is read into Rhino -- we have no control of how things are exported from Rhino to GridTool.

Over the years, we have done a bunch of things to try to help GridTool users at NASA.  Hopefully someone (@JW) will chime in here to provide some best practices.  I will try to remember what I can...

GridTool does not like single closed surfaces.  Yes, they complain that our geometry is too watertight...  So, the 'Split Surfaces' button in the above menu will split the geometry along feature lines (the black lines in the OpenVSP visualization if you turn the surface off).  This is probably good for body and fuselage type things, but maybe not for wings.

GridTool also does not like a wing that is a continuous surface from trailing edge (lower) to leading edge and back to trailing edge (upper).  They want it broken up at least some.  However, they don't really like to have an airfoil split along the exact leading edge (some mesh quality reason).  So, they wanted to be able to specify _where_ the surface was split.

So, we added the 'Split U/W-Const Sub-Surfaces' option.  That way, a user can put in U/W split lines with subsurfaces and the surfaces would be split along those lines during export.  A GridTool user might place split lines on the top and bottom wing surface slightly aft of the leading edge (say 5% x/c) so they can patch and mesh the entire leading edge region with one patch, but still split the airfoil up a bit.

USM3D likes blunt trailing edges, so usually GridTool is working from a blunt TE.  OpenVSP's surface starts and ends at the TE -- when there is a blunt TE, we actually start in the _middle_ of the TE.  Consequently, there are actually two TE surfaces (upper/lower halves).  The GridTool users don't like this.  They'd rather just have us throw away the TE surfaces.

So, sometimes they don't split the surfaces at all -- but the 'Omit TE Surfaces' option was added so we would throw away those surfaces (purposefully making the export non-watertight).  This leaves them with a non-closed airfoil (which they like), but also a surface that is not split exactly at the LE.  It is pretty easy for them to construct a new TE surface in GridTool.

There are probably other lessons learned, but those are the GridTool tricks that I can remember off the top of my head.

I don't know that this answers your question, but hopefully it helps you get down the road a bit....

Rob

--
You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/90908681-af4a-4783-afa8-5151fe05ad54n%40googlegroups.com.

[C P]

Hi,

among all suggestion given by Rob , in  my case, the command  Trimmed Surfaces, in Analysis Tab, works very well in  exporting an entire configuration to cfd software and meshing it without any preliminary , or with a very minimal,  work of geometry reparing or gap closing. 

Corrado

[Eric Cheng]

Rob,

Thank you very much for your detailed answer, I really benefited a lot from it.

Thanks again

[Rob McDonald]

Thrilled to hear it works well for you.

Can you share a few more details about your process?  Which file type and options are you using?  Which mesher and downstream tools are you exporting to?  Anything else that might be useful.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/c46e4d29-b143-4e78-af9f-207a7d365132n%40googlegroups.com.