Very critical issue

[docV]

I did the possible to get a water tight mesh with symmetry plane and vertical tail plane with OpenVSP 3.5.1, but every effort of mine was useless. The attached file shows what I get fpr a simple case. OpenVSP 2.3.0 doesn't have such problem, why? Can I get  this bug fixed please? It wouldn't restart my works again, they are important.
Thanks in advance.

[Rob McDonald]

I've known of this bug for a long time -- but frankly, it had fallen
off of my radar. Clearly people aren't trying to use the half mesh
symmetry plane very often.

What are you using to generate your volume mesh? My immediate
suggestion is for you to use that to generate the symmetry plane and
farfield boundaries. Most volume meshing tools will do that. Only
use OpenVSP to mesh the body and create a half mesh.

If you still want the benefit of OpenVSP's watertight check, then
generate a whole mesh -- if every component that crosses the symmetry
plane is located on the symmetry plane, there will be a line of nodes
on the symm plane, so you can trivially drop half the model later.

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

[docV]

My internal volume meshing tool is Engrid, that is buggy and very limited on mesh processing, but able to export to SU2 that is the solver I have to test. Unfortunately I have no cluster, so I have to save memory as much as I can, so the half mesh is mandatory for me.  By the way, I get this message on linux terminal, when i try to mesh with vertical tail plane: "IntExtCount ZERO!" What does it mean?
Would you tell me the files of mesh generation function please? I'd like to compare them with the ones of 2.3 version.
Thanks again

[Rob McDonald]

IntExtCount ZERO! means that the mesher was unable to classify a
triangle as internal or external. This ambiguity is one of the first
signs of problems like you've seen.

There are _many_ source changes between v2's mesher and v3's. So many
that comparing them for differences won't likely be productive.

Most of v3's CFDMesh files are separated into their own directory:
https://github.com/OpenVSP/OpenVSP/tree/master/src/cfd_mesh

Whereas in v2, they are all jumbled in with everything else:
https://github.com/OpenVSP/OpenVSP/tree/v2_master/src/vsp

In general, this kind of problem occurs before CFDMesh actually starts
creating the mesh. Instead, it usually has a problem when it
intersects the surfaces and builds the intersection curves. If those
end up topologically incorrect, the resulting CFDMesh will have
problems.

That intersection process (and many others in CFDMesh) involve a bunch
of interacting finite tolerances. Sometimes adjusting those can help.
In general, the tolerances in CFDMesh are in scientific notation, so
searching for '1.0e-' will help you find them.

I suspect your geometry would work fine with just the fuselage -- or
just the vertical tail, but the problem comes in with the intersection
of both - exactly on the center line.

You might be able to offset the vertical tail very slightly and work
around this problem.

Rob

[docV]

The offset of vertical tail didn't work. I increased all tolerances of all files in cfd_mesh (eg 1.0e-5 was increased to 1.0e-10) but the issue still exists. I wish it were fixed in the next OpenVSP relase. By the way, OpenVSP 2.3 has two interesting and useful features that were not ported to 3.x: rounded tips and smooth blend (in tab Dihed\Interpolation control).
Thank you very much for your help and for the development of OpenVSP.

[Rob McDonald]

'Increasing' tolerances may not have been the way to go. Loosening
some may have been a better approach. However, doing either one in a
blanket way isn't the way to go. It is the interaction between
different tolerances that make this kind of thing tricky.

I wish it would be fixed too. Unfortunately, I haven't had a bug yet
that was fixed by wishing. Instead, this one will likely take many
hours of challenging debugging.

Both rounded wingtips and blended wings are in the plan to be
implemented in v3 soonish. Blended wings in v2 were pretty terrible.
We're going to do a much better job in v3, but that takes time.

Rob

[docV]

I could give a better look at OpenVSP code, more probably it's a singularity of intersection functions. Is there any class diagram of OpenVSP? I could try to investigate to fix the bug. I went further with the testing: there's another bug with "T" configuration tail planes without a symmetry plane and farfield. I get a series of these messages

"BAD parameter in SurfCore::CompPnt! -0.001454 0.898742"

 and then a segmentation fault. What does it mean?
Thanks in advance

[Rob McDonald]

On Thu, Feb 4, 2016 at 4:25 AM, docV <cv63...@gmail.com> wrote:
> I could give a better look at OpenVSP code, more probably it's a singularity
> of intersection functions. Is there any class diagram of OpenVSP? I could
> try to investigate to fix the bug.

If you have Doxygen and GraphViz's Dot installed, the CMake setup
should detect them and you can do a 'make doc' that should
auto-generate documentation. That should give a nice way to navigate
some of the structure.

To follow the CFDMesh execution path, start with
CfdMeshMgrSingleton::GenerateMesh(). It is nearly a straight line
flow through the process from there.

> I went further with the testing: there's
> another bug with "T" configuration tail planes without a symmetry plane and
> farfield. I get a series of these messages
>>
>> "BAD parameter in SurfCore::CompPnt! -0.001454 0.898742"
>
> and then a segmentation fault. What does it mean?

This is an error thrown when the find nearest point algorithm attempts
to go off the edge of a surface (negative parameter you see there).
It generally isn't fatal these days, so it may be unrelated to your
segfault.

The T-tail could be the same problem as the body/vertical tail -- too
many perfect edge intersections exactly on the y=0 plane. Especially
if your configuration meshes fine when you don't model the symmetry
plane.

Rob

[docV]

If you have Doxygen and GraphViz's Dot installed, the CMake setup
should detect them and you can do a 'make doc' that should
auto-generate documentation.  That should give a nice way to navigate
some of the structure.

I Doxygenated all Doxyfiles in build directory, and I got Code-Eli Documentation, scl Documentation(empty) and OpenVSPAPI  3.5.1. Unfortunately when I search for GenerateMesh() or CfdMeshMgr.cpp the search engine gives no results. Where did I go wrong?

To follow the CFDMesh execution path, start with
CfdMeshMgrSingleton::GenerateMesh().  It is nearly a straight line
flow through the process from there.

Since v3 OpenNURBS were replaced by Code-ELI, why?
Thanks again for your help. I hope to fix this bug.

[Rob McDonald]

On Thu, Feb 4, 2016 at 11:35 AM, docV <cv63...@gmail.com> wrote:
>
>>> If you have Doxygen and GraphViz's Dot installed, the CMake setup
>>> should detect them and you can do a 'make doc' that should
>>> auto-generate documentation. That should give a nice way to navigate
>>> some of the structure.
>
> I Doxygenated all Doxyfiles in build directory, and I got Code-Eli
> Documentation, scl Documentation(empty) and OpenVSPAPI 3.5.1. Unfortunately
> when I search for GenerateMesh() or CfdMeshMgr.cpp the search engine gives
> no results. Where did I go wrong?

Ok, I haven't looked at the Doxygen stuff in a _long_ time. When I
was looking at it, I was hoping to create documentation mainly aimed
at the API (not general developer documentation), so I limited the
scope that was processed by Doxygen.

src/Doxyfile.in, line 674

Contains a list of paths that are processed. Change this to something like...

INPUT = @CMAKE_CURRENT_SOURCE_DIR@/geom_core \
@CMAKE_CURRENT_SOURCE_DIR@/gui_and_draw \
@CMAKE_CURRENT_SOURCE_DIR@/cfd_mesh \
@CMAKE_CURRENT_SOURCE_DIR@/geom_api \
@CMAKE_CURRENT_SOURCE_DIR@/vsp \
@CMAKE_CURRENT_SOURCE_DIR@/vsp_graphic \
@CMAKE_CURRENT_SOURCE_DIR@/util

Then, go into the 'API' documentation, it should more comprehensively
cover everything...

>> To follow the CFDMesh execution path, start with
>> CfdMeshMgrSingleton::GenerateMesh(). It is nearly a straight line
>> flow through the process from there.
>
>
> Since v3 OpenNURBS were replaced by Code-ELI, why?
> Thanks again for your help. I hope to fix this bug.

OpenNURBS was _only_ used for writing out Rhino *.3dm files. It was
only a Rhino data structure and file I/O library, it did not do any
curve or surface math.

It was replaced with STEPCode and LibIGES to write STEP and IGES files
respectively. OpenNURBS was a hassle of a dependency, and our users
complained about Rhino files and wanted STEP or IGES instead.
Finally, Rhino is perfectly capable of reading in our STEP and IGES
files, so no capability was lost.

In v2, we did our curve and surface math in about four places
scattered across the source code. It was all limited to cubic Bezier
splines.

Code-Eli is 100% developed by the OpenVSP team. It is capable of
supporting arbitrary order Beziers and has lots of other curve/surface
construction capabilities that we use.

Rob

[docV]

OpenVSP compilation takes a lot of time, how can I get my hacked OpenVSP without compiling the executable from scratch each time?
What did you change in v3 than v2 about the mesh generation? It's faster now

[Rob McDonald]

You shouldn't have to re-run CMake after you've set things up the
first time. When you make a small source code change, just re-start
the build process at 'make'. In addition, you can do a parallel make,
depending on how many processors your machine has 'make -j4' or 'make
-j8' should help a lot.

Glad to hear that CFDMesh is faster for you. It was a lot slower
initially. I made some changes in 3.2.3 to try to speed it up. It
still has slow spots, but it got better.

Many things changed from v2 to v3. Mainly forced because it switched
from CFDMesh using its own Bezier surface math to make calls to
Code-Eli instead.

Rob

[docV]

I went further with testing: I specified a box part as farfield and I put a fuselage+half wing at a corner. The mesher deletes the wrong triangles and keeps a part of fuselage that is outside of domain.

IntExtCount ZERO!
    "means that the mesher was unable to classify a triangle as internal or external."


 I started at  CfdMeshMgrSingleton::GenerateMesh() as you told me, and after a fast look at the code

  425  CfdMeshMgr.BuildDomain();
  428  CfdMeshMgr.BuildGrid(); //BuildGrid: Build surf dist maps, find  surf border curves, load surface curves (SCurve) Match SCurves to create ICurves.  Create wakes surfs.
             
  431  CfdMeshMgr.Intersect();
     2416     BuildChains();
     2418     LoadBorderCurves();
     2420     MergeInteriorChainIPnts();
     2422     SplitBorderCurves();
     2424     IntersectSplitChains();
     2426     BuildCurves()
  438  CfdMeshMgr.InitMesh( ); //InitMesh: Tesselate chaings, merge border end points, build initial mesh, remove interior tris.
  440  CfdMeshMgr.SubTagTris();
  443  CfdMeshMgr.Remesh( CfdMeshMgrSingleton::CFD_OUTPUT );//CfdMeshMgr::Remesh: Remesh (split, collapse, swap, smooth) each surface mesh triangle.

that is linear and more or less self explanatory, I just should know what it's meant by chains, distmaps and ICurves, to get a better view of how the program works.
Thanks in advance

[docV]

I added a line in CfdMeshMgr.cpp

            cout << "SCurves Not Matched " << num_unmatched << endl;

At line 1186 and then I ran the testcase fusalage+wing.
I got 8 unmatched surface and not water tight mesh when I run fuselage+wing+symmetry. I get 4 unmatched surfaces and water tight mesh when I run fuselage+symmetry. Do the number of unmatched surfaces affect the watertightness?
Thanks in advance

[Rob McDonald]

Try this out:

https://github.com/OpenVSP/OpenVSP/tree/Fixes

I don't know if it will fix all of the problems you've seen, but it
may fix the problem with the vertical tail on the symmetry plane.

Rob

[docV]

Thank you very much.
it's the fix I was waiting for. I was finally able to get a water tight half mesh of F-104 with vertical tail. I get a mesh with hole just when the vertical tail airfoil is biconvex.
Thanks again
                        Carmine

[Rob McDonald]

On Mon, Feb 8, 2016 at 12:43 PM, docV <cv63...@gmail.com> wrote:
> Thank you very much.
> it's the fix I was waiting for. I was finally able to get a water tight half
> mesh of F-104 with vertical tail. I get a mesh with hole just when the
> vertical tail airfoil is biconvex.
> Thanks again
> Carmine

Carmine,

I'm glad that fix has helped you make progress.

I can replicate the problem with biconvex airfoils, but it doesn't
make a lot of sense why it doesn't happen for other airfoil types or
other similar situations.

This one is certainly linked to the value of some tolerance -- making
the offending section's chord larger or t/c larger can make the
problem go away.

If you have a chance to dig deeper, maybe you'll track it down.

Rob