CFD Mesh

[DR Millman]

I can mesh my model with CFD Mesh for the whole vehicle. When I try to generate the half mesh, OpenVSP crashes. Is this a known bug, or is it more an issue with my model?

[Rob McDonald]

I just tried it with a simple pod/wing geometry and it worked fine for
me, so I don't think there is an 'every time' bug in VSP.

Can you tell what stage of the CFDMesh process it crashes? Something
like Intersect, Build Target Mesh, or is it during the remesh process
where it iterates on each surface 10 times?

If it gets to the remesh process, how many surfaces are there -- and
how many in the full mesh case? I.e. are there exactly half as many
surfaces (you wouldn't do a half mesh with an asymmetrical body).

VSP components are made of surface patches. Even a fuselage, which
you could think of as one surface, is split vertically and
horizontally into four patches. This means there is usually a patch
boundary down the middle of almost all components.

To make a half mesh, VSP adds a symmetry plane and cuts the geometry
at Y=0. Usually, this means it is slicing the geometry right along
patch boundaries. VSP has special code to handle this exact case.

If a component were slightly moved such that the natural patch
boundary was very close to -- and parallel to the Y=0 cut, I could
imagine some problems. So, the first thing I would check is for patch
boundaries lining up with each other -- and a confluence of those at
Y=0.

If you can send me the *.vsp file, I can try to check it out.

Rob

On Tue, Apr 9, 2013 at 7:08 AM, DR Millman <themillm...@gmail.com> wrote:
>
> I can mesh my model with CFD Mesh for the whole vehicle. When I try to generate the half mesh, OpenVSP crashes. Is this a known bug, or is it more an issue with my model?
>

> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[DR Millman]

It dies on Intersect. This is my first model I've built with OpenVSP, so I'm sure it's something I modeled.

[DR Millman]

I tried loading the file to the post, but I got an error. Please send an e-mail to millman...@bah.com, and I'll send you the file.

[Rob McDonald]

Daniel,

Thanks for sending me your example file.

Looks like you've found a bug. I've chased it down and have a fix
that works for all the cases I can throw at it (including yours). The
fix is in a new branch on GitHub...

https://github.com/ramcdona/OpenVSP/tree/HalfMeshFix

Are you set up to compile VSP? If so, can you please try it and see
if that gets you going? Compiling VSP is pretty easy on MacOS or
Linux. It is a real pain on Windows. If you are on Windows and don't
already compile VSP, then don't try to set it up for this.

If you can't build/test this fix, I'll try to roll a new 2.2.3 release
soon and get this out...

Thanks,

Rob

[DR Millman]

I'm currently running on Windows, but I want to get set up on Linux. You just gave me motivation to set up on Linux tomorrow.

[Rob McDonald]

Ha! Don't blame me for that.

It worked fine without the vertical tail and engine components. So,
you can probably keep your project making progress in the meantime by
deleting those components and working with the rest.

I'll go through and re-audit the code. I'm pretty confident it is the
right fix. I have a couple of other bug fixes queued up, so if I have
time, I'll try to release a new version tomorrow. I was waiting on a
feature release, but these are real bugs that real users have hit, so
they're worth getting out there.

I noticed that your fuselage was defined with a large number of cross
sections. Unless these cross sections -- and the tangent angles
between them -- are defined perfectly, this has a chance of causing
spurious ripples between the cross sections.

In general, for VSP, less is more.

For your fuselage, I suggest you try to define it with the absolute
minimum number of cross sections possible. Only add an additional
section if you are certain you can not represent the shape without it.
This will let VSP do what it can to to make the highest quality
surface possible.

Also, is there a reason you added all the mesh sources? Since the
curvature based meshing was added, my general advice is for users to
start with the curvature parameters to get the mesh 90% of the way
there. You should be able to get all the geometry properly
represented with these parameters. The main reason to control
resolution with the sources is then to make sure that you have all of
the flow features (or whatever physics you are modeling). So, I'm a
little surprised to see mesh sources before someone has run a test
solution with just the curvature based stuff.

Best,

Rob

[DR Millman]

Rob,

Like I said, this was my first model. I was playing around with sources so I could understand how they work. I just downloaded CART3D, so I will clean up this model before I try to run anything on it.

I'm evaluating these tools as a way to get a quick assessment on missile designs. I'll probably be back in touch as I learn more. I plan to start playing with the design variables, running in batch mode, and wrapping OpenVSP with POST II to do some optimization design. If you have any more advice in that regard, I'm all ears.

Thanks!

Danny

[Rob McDonald]

Danny,

No problem, just trying to give a few tips to help you along the way.

Cart3D is a CFD code unlike most others. I think very highly of it,
in my experience, it has enabled great productivity. However, you
somewhat need to think about things differently from a 'normal' CFD
code.

I strongly suggest you go through the VSP to Cart3D tutorial on the VSP Wiki...

http://www.openvsp.org/wiki/doku.php?id=c3dtutorial

There is also some good background information in the slides from last
year's Workshop...

http://www.openvsp.org/wiki/lib/exe/fetch.php?media=vsp_file_types_meshing.pdf

Cart3d _must_ have a watertight body as its input geometry. The
half-models produced by VSP CFDMesh are not watertight -- they leave
the face cut by the symmetry plane open. The Cart3D tools will crash
and refuse to work with them.

However, that doesn't matter. I commonly take a symmetric geometry
from VSP and only analyze the half-domain in Cart3D. When you
visualize the results, you will see half an airplane hanging outside
the control volume, but everything works great. So, for Cart3D, you
don't even need the 'Generate Half Mesh' flag in CFDMesh!

Next, there are three ways to take VSP geometry to Cart3D. They are
detailed in the tutorial above. While the CFDMesh approach will work
- and it has some advantages - I generally recommend you go with one
of the other approaches for Cart3D. They are more robust, easier, and
faster to work with. So, for Cart3D, you don't even need CFDMesh!

When you go to wrap OpenVSP for some sort of design process, I have
two recommendations. If your organization has ModelCenter, then you
should certainly use the plugin. You can contact your Phoenix rep to
get access to it.

Otherwise, I suggest you use the *.des design file support. The only
documentation for that is in some slides from the Workshop...

http://www.openvsp.org/wiki/lib/exe/fetch.php?media=vsp_xddm.pdf

Let me know if you have any more questions,

Rob

[DR Millman]

Rob,

I was able to generate the half mesh. Thanks for the update.

Danny

[DR Millman]

Rob,

I noticed on your tutorial that you really packed a lot of points on the OneraM6 wing. I tried packing a similar number of points on the mesh I sent you and did a CompUnion. I either can't open that file now, or it's just taking a really long time to open. Do you have a suggestion on the cell size before generating a .tri file for CART3D?

Thanks

[Rob McDonald]

Cart3D uses the faces for two things:

First they act like a knife to cut the Cartesian mesh. Consequently,
you only need enough to accurately cut the shape.

Second, the solution is interpolated back onto the triangles for
visualization. Consequently, you need enough triangles to graphically
display the flow solution.

So, if for some reason, you wanted to study the flow around a cube,
you could get away with 12 triangles and still exactly represent a
cube. You would get the right solution. However, when you
interpolated the solution back onto the triangles, the visualization
would not accurately represent the flow.

So, as a rule of thumb, the Cart3D guys suggest that you try to keep
the triangles smaller than the cubes you will use in the flow
solution. That way you are safely covered for the flow solution and
the visualization needs.

Because the triangles are somewhat de-coupled from the Cartesian mesh,
adding extra surface triangles doesn't slow down Cart3D, so there is
generally little downside from adding lots of surface triangles for
Cart3D.

CompGeom will slow down with a huge number of points, so you might
just give it some time. On the other hand, you can export a
non-intersected tri file and use Cart3D's 'Intersect' program. You
should get the same result, but Cart3D's Intersect is quite a bit
faster than CompGeom for large meshes.

Hope this helps,

Rob