foil lofting

[elephantwalker smith]

Hi,

I have a use case where I have 20 wing sections, with the root and the tip having different foils. This is a prandtl-d wing, so I need the 20 sections for 20 different twists. Everything works...except for one problem.

The tip foil and root foil are  AF_File  *.dat foils. But when I create the sections using split or add, openVSP just copies the tip foil, and doesn't extrapolate or loft between the tip and the root.

How do I extrapolate or loft the foils?

-EW

[Rob McDonald]

For a Wing, OpenVSP expects that you want to be specific about every foil at every planform break -- where you specify chord, twist, etc.

So, OpenVSP expects you to have 20 (maybe 21) files to specify all of these files.

It will interpolate between them (if the surface mesh indicates that is what is needed), but you have to specify the files yourself.

This will seem strange, but you might actually be better off using a Propeller component for something like this.  For a Prop, OpenVSP allows you to independently specify the chord and twist from where airfoils are specified.  In this manner, you can just provide root and tip airfoils and then build full twist, chord, sweep, etc. distributions for the planform shape.

This will take some work to translate from 'wing parameters' to 'propeller parameters', but it might be the way to go.

OpenVSP's wing is not very well set up for smooth or continuously varying chord and twist distributions -- you probably don't actually need it, but you have it and you think you do, and OpenVSP isn't great at handling it.

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/9aa3bc17-21fd-4fc5-a354-14640ff13dd7n%40googlegroups.com.

[elephantwalker smith]

Hi,

Thanks for the reply. Sadly if you use a linear distribution of twist, you just have one section, with Alpha on the root, and twist on the tip, and two different foils for the root and the tip. I see that openVSP lofts the foils correctly...but you can't get the 20 slices out to apply to 19 foils (0 and 20 are the root and tip, respectively), although openVSP actually has this slice in its geometry, but my geometry has a non-linear twist across the span.

I will use excel or python to loft the foils.

-EW

[Rob McDonald]

I understand the situation.

You will have the best results if you use a propeller geometry.

It is unusual that someone wants to vary the twist with great detail -- but doesn't care to vary the camber at all.

Here is a suggestion....

Build a simple hershey bar wing with the root and tip airfoils.  Set the spanwise tessellation to as many sections as you will need in your final wing.  Set the chordwise tessellation to something similar to the number of points in your airfoils.

Use OpenVSP's airfoil export capability to write out all of the airfoils along the wing.

Then go to your nonlinear curved wing -- read in the airfoils just written out.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/b2a5189d-dde2-4603-8ac7-dceb92e3f880n%40googlegroups.com.

[elephantwalker smith]

way cool! I will try it.

-EW

[elephantwalker smith]

Hi, I thought I would write about the experiences I had: 

1. First, getting out properly lofted foils uses the Export , *.dat option. The resulting files have "," in them which must be edited out. Since each foil is  a separate file, then an editor like notepad++ or an IDE must be used to correct the files. So this appears to be a bug, not a feature.

2. The number of points for the foils must be reasonable, otherwise, there is no control of the tessalation, if the number of points is too large. 
3. If there is some issue with the .dat file, there is no error thrown when it is imported into the foil using the "Read File" button for the AF_File type.

4. Although there is a proper mapping file *.csv which details each foil, all of the foils can't be loaded in at once, but have to be loaded one at a time. Kind of a drag.

5. This approach works! Yeah! I get the same results as several papers have gotten for the prandtl-d wing with OpenVSP.

Thanks for help!

-EW

[Rob McDonald]

Are you using the latest version of OpenVSP?  3.27 and higher (latest is 3.27.1) includes a fix for the comma in the airfoil file export.

Building a wing out of 20 sections is not the recommended way.  If you were going to do this a bunch, I would recommend you write a script to automate reading in the foils.

Rob

[deenri...@gmail.com]

Hi Rob, 

I am also facing a situation where I would like non-linear twist and camber. However trying to use the Prop geom allows me to only control camber through the Cli parameter. I would like to have a bit more control of the airfoils at each stations. I would also like to have access to the traditional design vars available with a wing component such as Span, Sref, Aspect Ratio etc. without having to calculate these ad-hoc on a PropGeom using analysis tools. Just adds complexity to my scripts. 

So this leads to a component request, a NonlinWing component that is a fusion of Prop-Wing components. One that allows non-linear control of chord/twist/camber/thickness along the wing, but still gives access to many of the traditional wing design vars. Wondering if this is a possibility?

Thanks

- Daniel

[Rob McDonald]

I have some thoughts about an improved Wing component similar to your suggestion.  For better or worse, that sort of thing has not been a priority for the folks who pay the bills -- so I don't have any idea when something like that will happen.

That said, what is wrong with Cli?  It really should be preferred over any other sort of single-parameter camber parameterization. All the NACA airfoils (except for 4-digit) are parameterized in terms of Cli -- I derived the conversion for 4-digit foils so they can work that way too for propellers.

I.e. if I were developing an advanced wing component, it too would be parameterized in terms of Cli.

If you're using CST or File airfoils, then OpenVSP can't modify the camber, so there is no parameterization of it.

Would you want Span, Sref, Aspect Ratio as inputs, or as reference outputs?

As an input, Span and Diameter are equivalent for this purpose (b=D).  I think it would be challenging to have detailed chord parameterization and keep Sref or AR as input parameters.

As outputs, reference quantities are just that -- reference.  Their values don't really matter as long as you are consistent.  Getting close has its benefits, but if you're working with a non-trapezoidal wing, you're going to be stretching definitions of reference quantities anyway.

The prop component already calculates lots of propeller relevant metrics -- activity factor, average chord, thrust & power weighted chord, solidity, etc.

The average chord (reported as C/R) is calculated as the integral of the chord/R, over the limits of integration -- starting at r_0, ending at 1.0.  For a wing, you would move the root XSec to start at 0.0 and set r_0 to 0.0.

So, if you want the planform area, multiply C/R by (b^2/2) and you have S.

Take b^2 / S and you'll find that: AR = 2/(C/R)

If you really want these things as easy outputs, you could gin up an advanced link to do the calculations.  You could then add a reference trapezoidal wing and set the planform parameters from the advanced link....

You could then tell VSPAERO to use that reference wing for reference quantities -- you would not want the trap wing in the analysis Set, but you can still use it to set Sref and stuff.

Rob

[deenri...@gmail.com]

I'll walk back my previous comment about "non-linear camber". It would be more interesting to me to be able to provide nonlinear twist and chord distribution (N stations) but fixed airfoils at certain (M) stations. With the goal of specifying airfoils, to not only control camber, but also to control the thickness distribution. This would allow use of refined airfoils other than NACA4 digit (Im thinking NLF).

And agreed, there are (hacky) ways to get many of the wing vars from the prop component, adv linking, or even through Geom Analysis. Just want to make some noise for this component.

At this time I'm reminded of an old software dev principle Don't Repeat Yourself (DRY). It suggests:  "If you have to do it more than twice, automate it."

- Daniel

[Rob McDonald]

The camber parameterization works with:

NACA 4-Digit

NACA 6-Series

NACA 4-Digit Modified

NACA 5-Digit

NACA 5-Digit Modified

NACA 16 Series

If a prop segment (space between two specified airfoil types) is bounded by like-type airfoils, then OpenVSP will construct the desired non-linear variation of camber across that segment.

If the prop segment is bounded by different-type airfoils (say a 4-Digit blending into a 16-Series) (or the other kinds like CST and File Airfoils that don't have camber parameterized), then OpenVSP will linearly interpolate the airfoil and then scale the result to match the desired nonlinear t/c variation.  In this case, the camber is whatever it happens to be.

The NASA NLF (and SC2) airfoils are not defined from a set of basis equations, so although they appear parameterized to the user (because they come from an organized catalog), they are not defined in a way that you can construct 'in-between' airfoils from the math.  This is why they are not direct choices in OpenVSP -- you have to use File Airfoils to use those types.

The prop component will scale the t/c of all airfoil types (even CST and File airfoils) to match a nonlinear t/c distribution across the blade.

Historically, the t/c was scaled by 'just' scaling the airfoil ordinates.  Somewhat recently (3.45.1), OpenVSP instead decomposes an airfoil into thickness and camber distributions, scales the thickness only, and then re-applies that thickness to the original camber.  The thickness/camber decomposition is approximate, but it is consistent with the camber decomposition used for the thin-surface representation that feeds to VSPAERO, so from that perspective it is consistent.

A hypothetical advanced wing component would suffer the same limitations.

While I love a good hack, I wouldn't describe my suggestions as hacks...  They're more a case of using what is already provided as a workaround for a feature that will probably never happen.  Calculating Sref=(C/R)*b^2/2 is exact.  Likewise, AR=2/(C/R) is also exact.  Both are pretty convenient (they are available as Parms and are dynamically updated every time the Prop is lofted). 

Rob