Learning to fit OpenVSP models to old geometries
696 views
Skip to first unread message
Fred Bacon
Oct 4, 2016, 2:18:39 PM10/4/16
to OpenVSP
Hi Rob,
I was at the OpenVSP meeting in August (which was great) and followed along with your presentation on using the fitting functionality in OpenVSP. I have some old wireframe geometry models for various military aircraft that I would like to move into OpenVSP if possible. My geometry models are used for IR signature modeling and come with a variety of "attributes" attached to different portions of the geometry. So I have a number of issues to tackle when it comes to mapping the old geometry models into OpenVSP and back. I've been experimenting with different aspects of this for the past several days, and I'd like to run my plans and observations by you to see if you have any suggestions where I might improve things.
Some of my models have a significant number of regions of various sizes which denote areas with different thermal properties. They may be the locations of fuel tanks, avionics bays, APUs, turbofans, etc.. It looks as though I can easily represent most of these areas within the OpenVSP geometry using subsurfaces. Is there any way within OpenVSP to associate user defined attributes with these subsurfaces, or will I need to maintain that information independently?
It seems hopeless to try and fit an entire model automatically. My best path forward seems to be to break the old geometry model down into different components (wings, tails, fuselage, engines, pylons, etc.) fit them individually and then reassemble the complete geometry from these components. Working with simpler subsections just seems the least frustrating path given my current limited experience.
My current demonstration project is a model of the QF-4. It's possible at some angles to view the spinning compressor blades. From the other end, you can see up the afterburner to see the exhaust cone and the spray bars. The spinning compressor blades and the afterburner spray bars are currently represented by an undifferentiated disks. I pulled out those components and began trying to fit them with a "Fuselage" component.
Basically, I just needed a circularly symmetrical cylinder with two flat end faces and a spinner and a cone sticking out either end. This seemed simple at first glance, but I quickly ran into problems. Giving the fitter too many points and parameters just seemed to result in truly strange shapes which fit the data points, but were otherwise useless to me. I realized that I would actually need to figure out how to constrain the problem even further.
Yesterday I sat down and tried to create something by hand that was close to the shape that I wanted so that I could see exactly which parameters were necessary to achieve the results that I wanted. (See attached images.)
I was at the OpenVSP meeting in August (which was great) and followed along with your presentation on using the fitting functionality in OpenVSP. I have some old wireframe geometry models for various military aircraft that I would like to move into OpenVSP if possible. My geometry models are used for IR signature modeling and come with a variety of "attributes" attached to different portions of the geometry. So I have a number of issues to tackle when it comes to mapping the old geometry models into OpenVSP and back. I've been experimenting with different aspects of this for the past several days, and I'd like to run my plans and observations by you to see if you have any suggestions where I might improve things.
Some of my models have a significant number of regions of various sizes which denote areas with different thermal properties. They may be the locations of fuel tanks, avionics bays, APUs, turbofans, etc.. It looks as though I can easily represent most of these areas within the OpenVSP geometry using subsurfaces. Is there any way within OpenVSP to associate user defined attributes with these subsurfaces, or will I need to maintain that information independently?
It seems hopeless to try and fit an entire model automatically. My best path forward seems to be to break the old geometry model down into different components (wings, tails, fuselage, engines, pylons, etc.) fit them individually and then reassemble the complete geometry from these components. Working with simpler subsections just seems the least frustrating path given my current limited experience.
My current demonstration project is a model of the QF-4. It's possible at some angles to view the spinning compressor blades. From the other end, you can see up the afterburner to see the exhaust cone and the spray bars. The spinning compressor blades and the afterburner spray bars are currently represented by an undifferentiated disks. I pulled out those components and began trying to fit them with a "Fuselage" component.
Basically, I just needed a circularly symmetrical cylinder with two flat end faces and a spinner and a cone sticking out either end. This seemed simple at first glance, but I quickly ran into problems. Giving the fitter too many points and parameters just seemed to result in truly strange shapes which fit the data points, but were otherwise useless to me. I realized that I would actually need to figure out how to constrain the problem even further.
Yesterday I sat down and tried to create something by hand that was close to the shape that I wanted so that I could see exactly which parameters were necessary to achieve the results that I wanted. (See attached images.)
I found that I needed to place a cross section at the locations with right angle turns in the surface (the flat disks), and that I had to set the "Strength" to 0.0 in the Skinning tab for the cross section. If I didn't set the strength to zero, then I ended up with a thin "flange" at the outer edges of the disks. That was rather unexpected, but a good lesson. Because I need to divide the surface into sections for thermal modeling, I added sub-surfaces of type "Line" at the various corner points. Positioning them was a bit tricky until I finally remember that the cross-sections are evenly spaced in UV space regardless of their position in physical space. (It would be nice to have them "snap to" a nearby cross-section. But you should be able to turn that off and on at will.)
So anyway, I believe that I've figured out how to improve my fitting procedure. (Some of it only in the course of writing this message!) I still need to actually fit a model to my cloud of points, but at least I now know which parameters should be allowed to freely vary and which should be firmly fixed.
Finally, I'll need to export my finished geometry from OpenVSP into a format that my IR modeling tools understand. My initial idea was to extend OpenVSP to write the necessary geometry format. Even though the IR signature tool is a JANNAF code, I doubt that you want to drag along yet another file format translator. Now I'm leaning towards writing a script to perform the geometry export. Is there an example which would show me how to generate, access and manipulate a mesh geometry within a script? I especially need to deal with sub-surfaces and extra attributes if they are available.
I apologize if this was long, rambling or contained too many images. I was trying to organize my own thoughts as I worked through this.
Thanks,
Fred Bacon
Aerodyne Research, Inc.
Rob McDonald
Oct 4, 2016, 10:44:51 PM10/4/16
to ope...@googlegroups.com
Fred,
This looks like a lot of fun.
Right now, OpenVSP does not have any way to annotate attributes to surfaces/subsurfaces.
However, it has come up a few times, so it wouldn't surprise me to see it added sometime down the road. Your use-case is exactly the kind of thing that we would have in mind.
If you can share (offline ok) some more information about your case, it would be helpful. The name of this code, perhaps some documentation, a list of the attributes that would be needed, etc.
We would want to make the attribute system generic (rather than tailored to a single application). The tricky part will be figuring out a way to make the generic attribute data available to exported files and whatnot.
Fit Model was never intended to fit a whole model automatically -- instead, it is meant more as an assistant to the otherwise manual process you would normally go through to make a model.
When you work with Fit Model, you are rolling up your sleeves and getting elbow deep into an optimization problem. It will take advantage of any ill-posed problem. Keep things very simple, take on a small bite at a time.
Rather than create sharp corners by setting the strength to zero, it is better if you change the settings to allow non-equal angle on either side of a cross section. Then, set one side to 90 and the other to 0 (or whatever you need) and go from there.
I wouldn't rule out adding an additional file format for this code down the road.
In the meantime, the full mesh data from a CompGeom mesh is available in memory to the API and/or AngelScript built-in scripting.
The TestAll.vspscript example that comes with VSP includes a section of code where the mesh data is used to write out an STL file -- as a demonstration that all the data is there. That should get you started.
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Fred Bacon
Oct 5, 2016, 1:07:18 PM10/5/16
to ope...@googlegroups.com
Hi Rob,
I was setting non-equal angles on either side of the cross section, but it still required me to set the strength to zero to avoid getting a thin flange at the corner which extended beyond the cylinder. However, I don't exclude the possibility that something about the order in which I performed operations caused that result.Fred Bacon
Oct 5, 2016, 1:40:49 PM10/5/16
to ope...@googlegroups.com
Rob,
That looks good. I'll compare it to my own model. I believe that you are correct about my angles. What sort of coordinate system defines the forward and backward angles at the xsecs?Fred Bacon
Oct 7, 2016, 8:43:29 AM10/7/16
to OpenVSP
Hi Rob,
I ran into a problem last night working on the afterburner and nozzle of the J79 engine of the QF-4. I've recreated the geometry from our original wireframe model. Then I used subsurface lines to break it down into various thermal zones to match our original model. When I try to turn it back into a mesh using CompGeom, I get the following message:
...Comp Geom...
2 Num Comps
2 Total Num Meshes
1272 Total Num Tris
Theo_Area Wet_Area Theo_Vol Wet_Vol Name
-------------------------------------------------
0.000 0.000 0.000 0.000 Totals
WARNING: 2 open meshes removed
After playing with it for a while last night, I've come to two hypotheses about the problem. The first is that I didn't create the subsurfaces in any particular order. The second, and more likely problem is that some of my subsurface lines fall close to but not exactly on a facet boundary. Thus, when OpenVSP tries break the surface at the line, it ends up with a thin sliver that it rejects. The end result is that no mesh is produced. I don't exclude other possibilities, those are just the two I could imagine. It's also possible that I've just botched the whole thing. :-)
Could you or anyone in the group take a look and make suggestions about how to fix my problem? I've attached my working model of the afterburner section.
Eventually, I'll want to turn this section into a custom part. To open and close the nozzle correctly, I'll need to vary several parameters simultaneously to simulate the opening and closing of the nozzle and throat regions at different power settings. But that will have to wait until I finish the complete QF-4 geometry.
Fred
I ran into a problem last night working on the afterburner and nozzle of the J79 engine of the QF-4. I've recreated the geometry from our original wireframe model. Then I used subsurface lines to break it down into various thermal zones to match our original model. When I try to turn it back into a mesh using CompGeom, I get the following message:
...Comp Geom...
2 Num Comps
2 Total Num Meshes
1272 Total Num Tris
Theo_Area Wet_Area Theo_Vol Wet_Vol Name
-------------------------------------------------
0.000 0.000 0.000 0.000 Totals
WARNING: 2 open meshes removed
After playing with it for a while last night, I've come to two hypotheses about the problem. The first is that I didn't create the subsurfaces in any particular order. The second, and more likely problem is that some of my subsurface lines fall close to but not exactly on a facet boundary. Thus, when OpenVSP tries break the surface at the line, it ends up with a thin sliver that it rejects. The end result is that no mesh is produced. I don't exclude other possibilities, those are just the two I could imagine. It's also possible that I've just botched the whole thing. :-)
Could you or anyone in the group take a look and make suggestions about how to fix my problem? I've attached my working model of the afterburner section.
Eventually, I'll want to turn this section into a custom part. To open and close the nozzle correctly, I'll need to vary several parameters simultaneously to simulate the opening and closing of the nozzle and throat regions at different power settings. But that will have to wait until I finish the complete QF-4 geometry.
Fred
Rob McDonald
Oct 7, 2016, 10:29:53 AM10/7/16
to ope...@googlegroups.com
Ok, there are two things going on here.
First, there is a 'MeshGeom' component on your geometry browser. It is
the component you are matching to. It has also been converted to
points.
When CompGeom runs, it will include any MeshGeom components in its
operation -- that is why it says there are two components, not just
one. It is trying to merge your reference geometry with the VSP
geometry.
I would use 'Sets' to avoid this behavior. Place all the reference
geometry components into one 'Set', place all your 'real' geometry
into another set. Then select the desired set when you run CompGeom.
The second issue is that the component is 'open'.
OpenVSP likes each component to be individually watertight. You've
constructed this afterburner as a thin shell -- the first cross
section does not come to a point or coincide with the final cross
section, so it is open.
When CompGeom processes a geometry, it first goes through and checks
if individual components are watertight -- those pass and get placed
on a stack. Non-watertight geometry gets placed on another stack.
After that first pass, OpenVSP goes through all the non-watertight
shapes, checking if they have any perfectly coincident edges -- if
they do, they get merged. If the result is watertight, they get moved
to the good pile.
Everything that is eventually deemed watertight (either individually
or in combination with friends) is then processed in CompGeom.
Everything that is open gets thrown out and ignored. Hence the
message 'Warning: 2 open meshes removed'.
The two open meshes are your real geometry and your reference
geometry. If you use the set approach above, you'll be down to one
open mesh.
You changed the XSec Order policy to 'Free', For this, you probably
want to use 'Loop'. That will enforce the first/last XSec are exactly
identical and coincident. Unfortunately, it also requires the 'first'
cross section to be located at 0,0,0, so you'll need to re-order your
component.
Additionally, in my experience, it is more intuitive to model this
kind of geometry as a Stack instead of a Fuselage. The primary
difference is that a Fuselage is always referenced to x/L y/L z/L with
a global L controlling length. However, a Stack is built as deltax,
deltay, deltaz in dimensional coordinates.
The one possible hangup is that when you angle sections in Stack, the
whole stack now builds off in that other direction -- you'll want to
play with it some before committing too seriously.
Rob
First, there is a 'MeshGeom' component on your geometry browser. It is
the component you are matching to. It has also been converted to
points.
When CompGeom runs, it will include any MeshGeom components in its
operation -- that is why it says there are two components, not just
one. It is trying to merge your reference geometry with the VSP
geometry.
I would use 'Sets' to avoid this behavior. Place all the reference
geometry components into one 'Set', place all your 'real' geometry
into another set. Then select the desired set when you run CompGeom.
The second issue is that the component is 'open'.
OpenVSP likes each component to be individually watertight. You've
constructed this afterburner as a thin shell -- the first cross
section does not come to a point or coincide with the final cross
section, so it is open.
When CompGeom processes a geometry, it first goes through and checks
if individual components are watertight -- those pass and get placed
on a stack. Non-watertight geometry gets placed on another stack.
After that first pass, OpenVSP goes through all the non-watertight
shapes, checking if they have any perfectly coincident edges -- if
they do, they get merged. If the result is watertight, they get moved
to the good pile.
Everything that is eventually deemed watertight (either individually
or in combination with friends) is then processed in CompGeom.
Everything that is open gets thrown out and ignored. Hence the
message 'Warning: 2 open meshes removed'.
The two open meshes are your real geometry and your reference
geometry. If you use the set approach above, you'll be down to one
open mesh.
You changed the XSec Order policy to 'Free', For this, you probably
want to use 'Loop'. That will enforce the first/last XSec are exactly
identical and coincident. Unfortunately, it also requires the 'first'
cross section to be located at 0,0,0, so you'll need to re-order your
component.
Additionally, in my experience, it is more intuitive to model this
kind of geometry as a Stack instead of a Fuselage. The primary
difference is that a Fuselage is always referenced to x/L y/L z/L with
a global L controlling length. However, a Stack is built as deltax,
deltay, deltaz in dimensional coordinates.
The one possible hangup is that when you angle sections in Stack, the
whole stack now builds off in that other direction -- you'll want to
play with it some before committing too seriously.
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.
> 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
Fred Bacon
Oct 7, 2016, 11:19:01 AM10/7/16
to OpenVSP
Thanks, Rob!
I will experiment with Stacks this weekend. Your other suggestions are going to be very helpful.
We have this complex duct which runs through the airframe where the J-79 engine resides. The heated surfaces of the duct can be visible at certain angles, so they have to be present in the final model. I've been worrying about that duct from the start. I was trying to tackle the duct, engine, afterburner and nozzle in segments and then fit the pieces together in the final step to create a closed surface, but it looks like that won't be a practical idea.
Fred
I will experiment with Stacks this weekend. Your other suggestions are going to be very helpful.
We have this complex duct which runs through the airframe where the J-79 engine resides. The heated surfaces of the duct can be visible at certain angles, so they have to be present in the final model. I've been worrying about that duct from the start. I was trying to tackle the duct, engine, afterburner and nozzle in segments and then fit the pieces together in the final step to create a closed surface, but it looks like that won't be a practical idea.
Fred
Reply all
Reply to author
Forward
0 new messages