Re: Generating LaWGS Files (Langley Wireframe Geometry Standard) Files with VSP

[Steve]

I have a LaWGS to plot3d (they're basically the same thing).  Would converting to a hermite file make sense?

Steve

On Monday, July 23, 2012 5:55:51 PM UTC-7, Josh K wrote:

I'm relatively new to VSP and was wondering if there was a tool that existed to convert VSP geometry into a Langley Wireframe Geometry Standard file. The LaWGS file is defined here:  http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19850014069_1985014069.pdf. If there is no simple tool or method already out there for doing this does anyone have thoughts on what geometry export format would make a good starting point?

Thanks,

Josh

[Rob McDonald]

Josh,

Thanks for your interest in VSP.

Thanks also for this morning's followup emails -- they help to put
everything into context (i.e. I wondered where you were going with
that).

Yes, you've hit on the difficult part of creating a structured input
file (like for A502). Creating an input file for the independent
components themselves is easy -- but of course they intersect.
Finding that intersection curve and constructing compatible panels on
the two intersecting components is the challenge.

It can be handled fairly easily for certain standard cases (wing to
circular fuselage), but the real challenge comes into play when you
want to handle any arbitrary set of intersections -- say the
horizontal tail is somewhat 'above' the wing -- or a T-tail -- or a
canopy which is part above the wing, but part not....

People have worked the structured mesh generation -- and the special
subset of it for panel codes -- for a long time. There are lots of
partial and complete solutions out there.

VSP has decided to go another way on this -- use unstructured
techniques. This lets us handle truly general problems in a truly
general way.

However, there aren't a lot of unstructured panel codes out there (but
there are a few). The wake code is brand new -- I haven't even tried
an analysis based on it yet.

Do you work for an aerospace company, government, or a university?
Knowing what kind of hat you wear, I might know of some options which
may be available to you.

Rob

On Tue, Jul 24, 2012 at 12:19 AM, Josh <kus...@gmail.com> wrote:
> After further thought, I realized that things will be slightly more
> difficult since the points contained within hermite files don't take into
> account interaction between surfaces. Ideally what I'm looking for then is
> way of a panel meshing of the whole aircraft with panel wakes and then
> turning that into a LaWGS format.
>
> Josh
>
>
> On Monday, July 23, 2012 11:31:17 PM UTC-7, Josh wrote:
>>
>> Somehow my original message was deleted right as I posted it. Anyways, I
>> should elaborate that my end goal is to tie VSP into an MDO environment
>> utilizing a panel-method code (in my case, A502/PANAIR). Creating a LaWGS
>> file is an intermediate step in the process of generating an A502 input
>> file. I took a look at the hermite file and it seems like it will work well!
>> It shouldn't be too much work to convert a hermite file into a LaWGS or A502
>> geometry input. Thank you for the help!
>>
>> This brings up the next issue that I was wondering about. Right now it
>> seems like the wake-generation routine in VSP is tied to the CFD mesher. Is
>> there a way to separate the two and include a generated panel wake in a
>> hermite file output? The CFD mesh generation process can be quite lengthy
>> and it would be nice if I could utilize the wake-generation routines already
>> in VSP decoupled from meshing instead of writing my own.
>>
>> Thanks,
>>
>> Josh

[Rob McDonald]

Josh,

I would expect the Boeing answer would be to use AGPS and other
internal tools to feed PANAIR. I'm not sure what would be the best
workflow starting from VSP.

Here are the unstructured panel codes I know about...

- Analytical Methods (http://www.am-inc.com/) has a version of VSAero
which supports unstructured patches. They typically use it for
wing-body junction (with the rest of the geometry structured). I do
not know if it could be satisfactorily used in a fully-unstructured
mode.

- Flow Solutions (http://www.flowsol.co.uk) markets NEWPAN, an
unstructured panel code.

- Larosterna (http://www.larosterna.com) has DWFS, an unstructured panel code.

- David Willis (http://faculty.uml.edu/dwillis) developed an
unstructured panel code as part of his PhD work at MIT. He is now
faculty at UML.

- Continuum Dynamics (http://www.continuum-dynamics.com/) has FPA.

- Dave Kinney at NASA Ames has CBAero. This tool is mostly used for
hypersonic and heating work, but it also has a low-speed panel method.
This is the tool targeted by VSP's wake modeling.

- Daniel Filković (http://www.3dpanelmethod.com/) has APAME, a
one-man open-source attempt to build an unstructured panel code.

- Philip Watts (http://appliedfluids.com/) had an employee develop one
under contract some time ago. I believe that effort has been
abandoned.

Unfortunately, the published record of these codes is nearly
non-existent. There is no way to know what kinds of
verification/validation exercises have been conducted. There is also
no way to know what kinds of projects they have been successfully
applied to.

Rob


On Tue, Jul 24, 2012 at 8:55 AM, Josh Kusnitz <kus...@gmail.com> wrote:
> Thank you Rob for the reply. I work at Boeing. Are the unstructured codes
> you're referring to using unstructured inputs directly or using an
> intermediary code first in order to read in an unstructured input?
>
> Josh

[Steve]

Rob & Josh,

Would it make sense to bump up the allowable number of patches in Panair?  My understanding is if you did that, you would be able to just model each triangle from VSP as a quad on an individual patch.  Then just apply your boundary conditions using a program like Patran (somewhat overkill; treat it as a property/material) and convert it to Panair format.

Steve

[Rob McDonald]

Josh,

Glad you've got a plan ahead. Please keep us posted if it works --
and let us know if you have trouble if it doesn't.

Rob

On Wed, Jul 25, 2012 at 11:13 AM, Josh Kusnitz <kus...@gmail.com> wrote:
> That seems a bit more overkill than I was looking for. Thanks for the
> suggestion though. Also, thank you very much Rob for your reply. After
> further research I found capability in AGPS to create structured A502 meshes
> from an unstructured geometry so I should be set through using a hermite
> file and AGPS.
>
> Josh

[Rob McDonald]

Steve,

I like your idea here.

I once attempted the same approach to make an unstructured version of
a hypersonic impact method. Its geometry input method was very
hierarchical (configuration made of parts made of sections made of
patches made of panels or some-such). The only level that 'required'
a structured approach was the lowest-level.

So, we constructed some models by using degenerate quads as single
triangles at the lowest level of the scheme. It worked for the
inviscid impact method parts of the program. Making it work for the
streamline tracing viscous and heating parts was going to be a lot
more difficult -- it wasn't set up to trace streamlines across certain
layers of the hierarchy.

It was only a proof of concept implementation. The array sizes for
each level were hard-coded, so we would need to modify those
significantly to be able to handle decent sized problems. We never
got around to that part of the project.

If someone can confirm/demonstrate that the public domain version of
A502 can be made to work on a triangulated surface, and that the array
sizes can be re-worked to make this a useful tool, then I think we're
in business. It would be good also to measure any performance impact
this approach had on the code.

If that looks promising, we can modify VSP to write out the input
files directly; no need for jumping through Patran along the way.

Rob

On Tue, Jul 24, 2012 at 9:07 PM, Steve <mesh...@gmail.com> wrote:

[Steve]

Rob,

I'm sure it can be done.  I have the Panair source (downloaded from PDAS) and have poked around in the past.  I'll take a look at it.

How about a Cart3D-esque file format?  The tricky part is defining the wakes.  If VSP can do that, then that's really all I'd need.  For boundary conditions:  Cart3D regions can identify BCs.  A separate file can map region #1 to a Panair BC=5 (base wake).  I suggest this because you can have a BC of 18 (wake), with a kt of 1 or 2.

I'd expect quite a bit of slowdown (~20%), but Panair models require FAR too much effort to make and 20% of a few minutes isn't that much.

One question I have is:  Can VSP output quads instead of triangles?  A quad based code would be faster and compare better to Panair.

Steve

[Rob McDonald]

Steve,

I'm pretty sure we write out the wakes to the Cart3D format -- if not, we can.

I agree that a Cart3D style point-connectivity-tags file is the way to
go if you're going to modify things on the panair side. Also, I see
no reason to reinvent another triangulated surface format.

On the other hand, we should also consider modifying VSP to write out
a 'native' triangulated panair file. Whichever makes the most sense.

JR recently received some feedback on the first application of the new
wakes. There are a few issues to be resolved (consistent normal
direction, etc) but those should be taken care of relatively soon.
You won't want to get too serious about testing things until those
issues are addressed.

I think the PDAS version is the perfect place to start from -- the
intellectual status of that code is quite clear. I don't know if you
are a git user yet or not, but it would be great to trace the
development of this project in some sort of version control software
from the start.

VSP's mesh generation capabilities are all triangle based. It is the
only way to handle the general problem easily and robustly. I realize
it may slow things down and it will make it difficult to directly
compare solutions with structured codes, but I think that is one that
we'll just have to eat...

I have access to an old-school Panair expert. I know he'll be
thrilled if we can breathe some new life into the tool by making it
more accessible to the masses. He is also a stickler for rigor, I'm
sure he'll be willing to help verify and validate everything once you
get a prototype capability up and running.

Let me know if I can be of assistance.

Rob

[Steve]

[Steve]

i've managed to convert the file to a panair file using some scripts I have with pyNastran.   The conversion is not difficult and panair ran on a simple box problem.  I wanted a more realistic problem before I attempted wakes though.

I tried the three plugs cart3d model (I'm only using 1 of the plugs for testing) and I'm running into a problem with the common block.  When I get to ~element/patch/network #455, I'm running into what I think is a Panair bug.  I set  mxnett (max Networks) to 10,000, which controls nnett (number of networks), but nnett changes from 10000 at that element to 2.  At that point the code crashes due to nnett being too low.

You can take a look at the code at:

http://code.google.com/p/pynastran/source/browse/trunk/pyNastran/converters/cart3d

specifically the toPanair.py file

It will read ascii or binary cart3d files.  So far all BCs and reference values are set inside the code.

[Rob McDonald]

Steve,

Have you had an opportunity to experiment further with creating
unstructured PanAir input files?

Your initial attempt came at a busy time - which was immediately
followed by the start of the academic quarter. Consequently, I never
got a chance to look at it.

I have a little time over the holidays when things aren't quite so
busy and will try to take a look at this.

Where do you think things stand?

Rob

[Steve]

Hi Rob,

I've got the converter working a reasonably simple model setup file to define boundary conditions.  The Cart3d model is then converted to a Panair model based on the regions (e.g. wing, fuselage, wake).

The part that's not working is Panair itself.  I was able to bump up the number of patches and points, but eventually hit another limit that I wasn't able to diagnose.  Fortran isn't my area of expertise, but I can take a look at it.

Beyond that, there are 5 types of wakes.  Wing sharp trailing edge wakes, wing blunt trailing edge wakes, body wakes, wing-fuselage wakes, engine wakes.  The wing wakes extend from the wing directly aft to some point aft of the body.  The body wake simulates a blunt surface.  The wing-body wake should intersect the wing wake and body wake and follow a smooth contour until it hits the body wake.  Engine input/output faces should be paved over and a cylindrical wake should extend aft.  All the wakes should go to the same aft location.

How capable is VSP in terms of wakes?

[Rob McDonald]

Steve,

Is this converter somewhere in the pyNastran codebase available
online, or have those changes been kept off to the side?

I have never actually run PanAir, so I don't have a lot of experience
with it or a set of pre/post processors at my fingertips. That said,
I don't have any problem digging in and trying to chase down the
problem.

VSP's wakes are a good start. Unless you fight VSP, all lifting
surfaces have sharp trailing edges. You can choose to construct a
wake from any lifting surface. VSP will build a surface from the TE
to a specified number of body lengths downstream. If those wakes
intersect another component, VSP will generate a mesh that honors that
intersection.

PanAir might use the whole VSP wake, or it may make sense to throw
away the wake and just keep the attachment line.

Right now, we don't try to handle nacelles or other components. We
know they need to be treated, but weren't a priority for this first
cut at wakes. I don't think we need to worry about them for this now
either.

I'm confident that if we could get a reasonable workflow for
'ordinary' wing-body geometries, we could generate a lot of enthusiasm
to make further improvements.

Rob

[Rob McDonald]

Steve,

Here are a few shots of a quick wake example I threw together....

Rob