IGES Entities
161 views
Skip to first unread message
DR Millman
Nov 16, 2016, 4:42:46 PM11/16/16
to OpenVSP
I would like the iges export to use different entities (141 or 143) rather than the 144 entity that it currently writes. Can I change that in the source code for OpenVSP? If so, where? Thanks.
Rob McDonald
Nov 16, 2016, 5:05:10 PM11/16/16
to ope...@googlegroups.com
It is theoretically possible -- but it would certainly be a non-trivial change.
What are you trying to achieve that requires this alternate entity type?
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.
What are you trying to achieve that requires this alternate entity type?
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.
DR Millman
Nov 16, 2016, 5:23:52 PM11/16/16
to OpenVSP
Transfer the geometry to HeatTK.
DR Millman
Nov 16, 2016, 5:30:57 PM11/16/16
to OpenVSP
The only entities Heat TK can handle are 143, 141, 128, and 126
Rob McDonald
Nov 16, 2016, 5:40:55 PM11/16/16
to OpenVSP
Have you tried a file directly from OpenVSP? I.e. not processed through any CAD tools?
OpenVSP only outputs entity 128's. I'm not sure where you're coming up with the 144s.
That said, our 128's are not trimmed. If Heat TK expects a trimmed watertight solid, then that is a more significant issue.
Rob
The Millmans
Nov 16, 2016, 6:15:12 PM11/16/16
to ope...@googlegroups.com
Yes, but Heat TK is expecting trimmed surfaces grouped into panels. And you're right. I did try to process the .igs file through Free CAD, AutoCAD, and even NX. Nontrivial indeed.
Sent from my iPhone
Sent from my iPhone
You received this message because you are subscribed to a topic in the Google Groups "OpenVSP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openvsp/9Sk4HM__3yc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openvsp+u...@googlegroups.com.
Rob McDonald
Nov 16, 2016, 6:56:52 PM11/16/16
to ope...@googlegroups.com
The HeatTK pdf I found easily online is a little confusing as to what
it expects from the geometry (a few figures would have gone a long
way).
If you can live with un-trimmed surfaces, then OpenVSP's file made of
128's should work great. It may be worth trying this for some simple
test cases -- just to find out where the next breakage point is. A
missile body or an Apollo capsule could be done quite readily.
Frankly, given the level of theory used by some components of HeatTK,
you could place some fins 'just touching' the missile body and even
with un-trimmed geometry, your answers would be about the same.
If you want to go all the way to watertight BREP's, then that will
require very significant changes to OpenVSP. If your CAD program is
outputting the wrong entity types (but otherwise satisfactory
geometry) then perhaps you can find a way to convert on that end.
Once you read a OpenVSP IGES/STEP file into a CAD program, we can't be
held responsible for what happens to it.*
A long time ago, I worked with SHABP, VECC, and co. Unless they have
been substantially re-written to arrive at HeatTK, I have serious
questions about how the geometry is processed before analysis (again,
figures in the document would go a long way). Unless HeatTK includes
a miraculous structured surface mesher, something happens along the
way that may not make it worth worrying too much about starting with
perfect BREPs.
This may not be an option, but have you considered using CBAERO from
NASA Ames? It may not be an option, but it is an aero/heating code of
similar theory -- but it was designed from the ground up to work with
an unstructured triangle surface mesh representation of the geometry.
Rob
*As an experiment, try this.... Open an OpenVSP STEP or IGES file in
your favorite CAD program. Then immediately export/save the file as
STEP/IGES. Then, compare the files side-by-side.
Every time I've tried this, the files are _significantly_ different.
Not just trivial boiler plate details -- but fundamentally different
structure, entities, etc. This is because every CAD program converts
the input geometry into its own internal data structures -- and then
it writes them out using its own writer.
it expects from the geometry (a few figures would have gone a long
way).
If you can live with un-trimmed surfaces, then OpenVSP's file made of
128's should work great. It may be worth trying this for some simple
test cases -- just to find out where the next breakage point is. A
missile body or an Apollo capsule could be done quite readily.
Frankly, given the level of theory used by some components of HeatTK,
you could place some fins 'just touching' the missile body and even
with un-trimmed geometry, your answers would be about the same.
If you want to go all the way to watertight BREP's, then that will
require very significant changes to OpenVSP. If your CAD program is
outputting the wrong entity types (but otherwise satisfactory
geometry) then perhaps you can find a way to convert on that end.
Once you read a OpenVSP IGES/STEP file into a CAD program, we can't be
held responsible for what happens to it.*
A long time ago, I worked with SHABP, VECC, and co. Unless they have
been substantially re-written to arrive at HeatTK, I have serious
questions about how the geometry is processed before analysis (again,
figures in the document would go a long way). Unless HeatTK includes
a miraculous structured surface mesher, something happens along the
way that may not make it worth worrying too much about starting with
perfect BREPs.
This may not be an option, but have you considered using CBAERO from
NASA Ames? It may not be an option, but it is an aero/heating code of
similar theory -- but it was designed from the ground up to work with
an unstructured triangle surface mesh representation of the geometry.
Rob
*As an experiment, try this.... Open an OpenVSP STEP or IGES file in
your favorite CAD program. Then immediately export/save the file as
STEP/IGES. Then, compare the files side-by-side.
Every time I've tried this, the files are _significantly_ different.
Not just trivial boiler plate details -- but fundamentally different
structure, entities, etc. This is because every CAD program converts
the input geometry into its own internal data structures -- and then
it writes them out using its own writer.
The Millmans
Nov 16, 2016, 7:04:43 PM11/16/16
to ope...@googlegroups.com
I'll look into CBAERO. Thanks.
Sent from my iPhone
Sent from my iPhone
Daniel Millman
Nov 18, 2016, 4:06:03 PM11/18/16
to ope...@googlegroups.com
Rob,
One more question. HeatTK actually uses a .geo format. I cannot find any documentation on what that means. I was hoping I could use the four step utility to get from .iges to .geo. Do you have any documentation on what .geo is?
Thanks,
Danny
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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.
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "OpenVSP" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/openvsp/9Sk4HM__3yc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to openvsp+unsubscribe@googlegroups.com.
Rob McDonald
Nov 18, 2016, 4:27:08 PM11/18/16
to ope...@googlegroups.com
Danny,
The only reference I have is from AFRL-VA-WP-TR-2005-3120 which I
found online and marked for unlimited distribution.
At the top of pdf page 26, it says the *.geo format is defined in
Section 2 of the VECC manual. Slightly before it says that, it says
the file is made of x,y,z points on the surface -- the geometry is
divided into components, panels, sections, and elements.
Remembering back to when I used VECC and S/HABP Mk. 5, I recall the
component, panel, section, element hierarchy system. Bottom line, it
was a structured wireframe file. The hierarchy provides various
levels of organization -- a system designed today would have probably
ditched those levels.
Back then, I wrote a program to convert VSP's *.hrm files to *.mk5
files (basically what must be the *.geo format).
HeatTK must do some simple meshing to convert an IGES file into a
*.geo wireframe -- I suspect this is _very_ simple -- meaning it does
not make any attempt to intersect or trim the geometry.
This is not a horrible thing given the level of theory used for this
kind of analysis. Make sure you understand just what your analysis
will let you get away with. If you are only using these tools for
aero forces, you don't even need to have the wings and bodies analyzed
at the same time -- they are independent!
BTW, here is a link to a paper I wrote based on the work I did with S/HABP...
http://arc.aiaa.org/doi/abs/10.2514/6.2000-5559
Also downloadable here
http://digitalcommons.calpoly.edu/aero_fac/96/
Rob
The only reference I have is from AFRL-VA-WP-TR-2005-3120 which I
found online and marked for unlimited distribution.
At the top of pdf page 26, it says the *.geo format is defined in
Section 2 of the VECC manual. Slightly before it says that, it says
the file is made of x,y,z points on the surface -- the geometry is
divided into components, panels, sections, and elements.
Remembering back to when I used VECC and S/HABP Mk. 5, I recall the
component, panel, section, element hierarchy system. Bottom line, it
was a structured wireframe file. The hierarchy provides various
levels of organization -- a system designed today would have probably
ditched those levels.
Back then, I wrote a program to convert VSP's *.hrm files to *.mk5
files (basically what must be the *.geo format).
HeatTK must do some simple meshing to convert an IGES file into a
*.geo wireframe -- I suspect this is _very_ simple -- meaning it does
not make any attempt to intersect or trim the geometry.
This is not a horrible thing given the level of theory used for this
kind of analysis. Make sure you understand just what your analysis
will let you get away with. If you are only using these tools for
aero forces, you don't even need to have the wings and bodies analyzed
at the same time -- they are independent!
BTW, here is a link to a paper I wrote based on the work I did with S/HABP...
http://arc.aiaa.org/doi/abs/10.2514/6.2000-5559
Also downloadable here
http://digitalcommons.calpoly.edu/aero_fac/96/
Rob
Daniel Millman
Nov 18, 2016, 4:47:49 PM11/18/16
to ope...@googlegroups.com
Thanks. I may be able to convert the mesh data to .geo. HeatTK also has a plugin to OTIS to do trajectory analysis. I think it will give me nice trade studies once I can import some OpenVSP geometries.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >> --
>> >> 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.
>> >
>> > --
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "OpenVSP" group.
>> > To unsubscribe from this topic, visit
>> > https://groups.google.com/d/topic/openvsp/9Sk4HM__3yc/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to
>> > For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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.
--
You received this message because you are subscribed to a topic in the Google Groups "OpenVSP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openvsp/9Sk4HM__3yc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openvsp+unsubscribe@googlegroups.com.
Daniel Millman
Nov 18, 2016, 5:03:16 PM11/18/16
to ope...@googlegroups.com
So here is what I don't understand about the .geo format (or the .mk5 format)
F0 0000000004*
1 000
0.0421 -1.6461 0.00002 0.0421 -1.6308 0.00040 0 1 3 0
0.0421 -1.5863 0.00090 0.0421 -1.5153 0.00120 0 1 3 0
0.0421 -1.4203 0.00160 0.0421 -1.3037 0.00180 0 1 3 0
0.0421 -1.1683 0.00210 0.0421 -1.0163 0.00230 0 1 3 0
0.0421 -0.8505 0.00250 0.0421 -0.6733 0.00270 0 1 3 0
0.0421 -0.4873 0.00280 0.0421 -0.2949 0.00280 0 1 3 0
Line 1: I believe F0 is the panel name. I'm nor sure what the 0004* means.
Line 2: No clue
Line 3: I think the first 6 numbers represent x(1,1,1), y(1,1,1), z(1,1,1), x(1,2,1), y(1,2,1), z(1,2,1). Not sure what the trailing integers indicate.
Once I understand the formatting, I think I can generate the .geo files directly.
Thanks
Rob McDonald
Nov 18, 2016, 5:15:26 PM11/18/16
to ope...@googlegroups.com
Daniel,
I really can't help you with things that are non OpenVSP related.
There needs to be someone else in your group who can help you with
this -- or else you're just going to have to find and read the
appropriate documentation and manuals.
Do you have the VECC documentation? I believe this is what I used
many years ago -- I don't know if there is something more recent
available:
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA302456
Check out Appendix A. In 'Fortran speak', a 'card' means a line in a data file.
Rob
On Fri, Nov 18, 2016 at 2:03 PM, Daniel Millman
I really can't help you with things that are non OpenVSP related.
There needs to be someone else in your group who can help you with
this -- or else you're just going to have to find and read the
appropriate documentation and manuals.
Do you have the VECC documentation? I believe this is what I used
many years ago -- I don't know if there is something more recent
available:
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA302456
Check out Appendix A. In 'Fortran speak', a 'card' means a line in a data file.
Rob
On Fri, Nov 18, 2016 at 2:03 PM, Daniel Millman
Reply all
Reply to author
Forward
0 new messages