Crash in OpenVSP / Triangle
251 views
Skip to first unread message
Glover George
Aug 6, 2016, 5:03:44 PM8/6/16
to OpenVSP
I've wrapped the vsp python interface into a ThreadingTCPServer so that I only need to load the vsp model once. I load the model, and then listen for morphgeom requests from a C# application. After about 30 minutes of succesful morphs and slices, I get the following error. Anyone seen this before? To be clear, each time the client connects, it does a morph geom, and then performs a planar slice.
XSec spin not implemented.
XSec spin not implemented.
XSec spin not implemented.
XSec spin not implemented.
XSec spin not implemented.
XSec spin not implemented.
XSec spin not implemented.
XSec spin not implemented.
XSec spin not implemented.
Internal error in segmentintersection():
Topological inconsistency after splitting a segment.
Please report this bug to j...@cs.berkeley.edu
Include the message above, your input data set, and the exact
command line you used to run Triangle.
Rob McDonald
Aug 6, 2016, 8:57:15 PM8/6/16
to ope...@googlegroups.com
The 'XSec spin not implemented.' error is unrelated to the Triangle
error. It simply reflects that we initially intended to implement a
'Spin' parameter for XSecs -- but never got around to it.
If you think of each XSec as a curve -- that curve has a starting
point, and moves around (say) clockwise until it gets back to the
starting point. If the curve normally starts a 12:00, Spin would move
the start/end point around the clock to (say) 3:00. It is a fine
idea, but it never got to be important enough to implement. So you
can safely ignore the Spin parameter entirely.
Triangle is a well known library that does Delaunay triangulation and
mesh generation. We use it a few places in OpenVSP. Here, we use it
to make sense of intersected triangles. When you make a planar slice,
we construct the plane using two triangles.
We then intersect the plane with the triangles that represent the
aircraft. When two triangles intersect, we split the edges at the
intersection points. Now imagine you have a triangle where the edges
have been split multiple times. We then construct the Delaunay
triangulization of that triangle.
So, the call to Triangle happens on a small scope problem (a single
triangle that has been intersected), but it gets called many many
times. This error is within Triangle. It probably results because
the geometry fed to Triangle is degenerate in some way.
The call to Triangle you're experiencing happens here:
https://github.com/ramcdona/OpenVSP/blob/master/src/geom_core/TMesh.cpp#L1983
This error is quite rare, but it does happen. Triangle is very
robust, but it is not perfect. Unfortunately, it gives very little
help when it crashes -- and it simply crashes hard, it provides no
graceful way to recover.
If you can set up a way to record the crashed cases and send them my
way, I may be able to adjust some tolerances to make our end a bit
more robust. However, it will be a ton of work for very small gains
in robustness -- and it may make other cases worse...
If you're using this in an optimization setting, it may be better to
make your framework able to gracefully recover from this sort of
thing. This crash is the kind that may go away with an
inconsequential change in a parameter (peturb something 1e-6).
The areas returned by the slicing are not going to be incredibly
smooth functions anyway (due to the faceted nature of the geometry
being sliced) so if you're using a gradient based optimizer, you're
going to want to take big steps and have loose tolerances -- so small
perturbations for crashes won't matter anyway.
If you're using a stochastic optimizer or simply doing trade study
sweeps, then tiny perturbations still shouldn't pose a problem.
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.
error. It simply reflects that we initially intended to implement a
'Spin' parameter for XSecs -- but never got around to it.
If you think of each XSec as a curve -- that curve has a starting
point, and moves around (say) clockwise until it gets back to the
starting point. If the curve normally starts a 12:00, Spin would move
the start/end point around the clock to (say) 3:00. It is a fine
idea, but it never got to be important enough to implement. So you
can safely ignore the Spin parameter entirely.
Triangle is a well known library that does Delaunay triangulation and
mesh generation. We use it a few places in OpenVSP. Here, we use it
to make sense of intersected triangles. When you make a planar slice,
we construct the plane using two triangles.
We then intersect the plane with the triangles that represent the
aircraft. When two triangles intersect, we split the edges at the
intersection points. Now imagine you have a triangle where the edges
have been split multiple times. We then construct the Delaunay
triangulization of that triangle.
So, the call to Triangle happens on a small scope problem (a single
triangle that has been intersected), but it gets called many many
times. This error is within Triangle. It probably results because
the geometry fed to Triangle is degenerate in some way.
The call to Triangle you're experiencing happens here:
https://github.com/ramcdona/OpenVSP/blob/master/src/geom_core/TMesh.cpp#L1983
This error is quite rare, but it does happen. Triangle is very
robust, but it is not perfect. Unfortunately, it gives very little
help when it crashes -- and it simply crashes hard, it provides no
graceful way to recover.
If you can set up a way to record the crashed cases and send them my
way, I may be able to adjust some tolerances to make our end a bit
more robust. However, it will be a ton of work for very small gains
in robustness -- and it may make other cases worse...
If you're using this in an optimization setting, it may be better to
make your framework able to gracefully recover from this sort of
thing. This crash is the kind that may go away with an
inconsequential change in a parameter (peturb something 1e-6).
The areas returned by the slicing are not going to be incredibly
smooth functions anyway (due to the faceted nature of the geometry
being sliced) so if you're using a gradient based optimizer, you're
going to want to take big steps and have loose tolerances -- so small
perturbations for crashes won't matter anyway.
If you're using a stochastic optimizer or simply doing trade study
sweeps, then tiny perturbations still shouldn't pose a problem.
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.
Glover George
Aug 8, 2016, 1:08:39 PM8/8/16
to OpenVSP
Yes, we are doing trade study's (full factorial), but may do optimization in the future. As long as this is a known problem, we will just handle the crash as gracefully as possible. I just wanted to be sure
it wasn't in the way we were setting up the problem or using the python library.
Cheers.
Rob McDonald
Aug 8, 2016, 3:54:55 PM8/8/16
to ope...@googlegroups.com
No, I think you've got it set up right.
These kinds of algorithms are really difficult to get 100% robust --
and ours isn't perfect.
Rob
These kinds of algorithms are really difficult to get 100% robust --
and ours isn't perfect.
Rob
Glover George
Aug 9, 2016, 10:10:55 PM8/9/16
to OpenVSP
Yes, turns out it errors on exactly the same input every time. If I get permission to send you the model, and you have time, maybe you could give me some insight on why it happens.
Cheers.
Reply all
Reply to author
Forward
0 new messages