With stall model CLtot decreases with AOA as AOA increases from negative to positive

[Mike Vivaldi]

Hi all,

I set up my analysis case by running a low positive AOA case, identified where the highest cl*C/Cref value was on the load distribution graph was, i then identified what airfoil was at that span of the wing, then went to XFLR and entered relevan CLMax2D and Clo2D. When I ran the analysis the results showed a constantly decreasing CL starting at AOA -10 up to +20. I've provided screenshots. 

What is happening here to cause these results? What do I need to modify or change? 

Thank you for helping me understand what is happening.

Best Regards,

Mike

[Mike Vivaldi]

Here is the attached polar file

[Rob McDonald]

I don't really follow what you're trying to accomplish or the problems you're seeing.

I also don't understand why you're looking at peak cl*c/cref.  The wing will likely first stall at peak cl - not cl*c.

Rob

[Mike Vivaldi]

Hi Rob I was trying to get a clean set of data CL, CD, CM v alpha across the flight regime and I was using a set of instructions for the process but evidently they were incorrect. The aircraft is a 707 and has multiple airfoils across the span of the wing. I think a couple years ago I was working on this and I think you mentioned the process would be to find where CL max is across the span, then find what airfoil that span location is and then input the CLMax and CLo from XFLR5 into openVSP.

Thanks,

Mike

[Rob McDonald]

OK, do you recognize the difference between:

cl*c/cref

and

cl ?

One of them is relevant to understanding and setting clmax -- the other is not.

You can plot both of them for any VSPAERO solution -- it is useful to plot them both and compare them.

cl0 you can set without looking at stall.  I would set it to an average ideal lift coefficient for the airfoils used on the wing.

Rob

[Mike Vivaldi]

Ya I see the difference and I think that something on my end was lost in my notes when I was trying this the other day. The Cl*c/cref graph effectively shows the span wise lift contributions where as CL is the operating point of the airfoil but independent of the actual lift contributed. mea culpa on that aspect.

When you mention setting CL0 for the average ideal lift coefficient, which average are you thinking of, average by area or average by span or something else? For example if the wing by span from root to tip is 20% NACA 2410, 30% NACA 2210, 50% 2010 would I average the airfoil by area or by span?

Thank you again for your help!

Mike

[Rob McDonald]

Just squint at it and pick something reasonable.  It won't make a very big difference.

There is no such thing as a NACA 2010 -- the 2nd digit is the location of maximum camber, which can't be at the LE.

Comparing the 0010, 2410 and 2210, their ideal lift coefficients are 0.0, 0.256 and 0.308 -- which are faithfully pretty much at the center of the drag polars for those airfoils.

If instead, you compare a 0010, 2410, and 4410 (same camber position, but increasing magnitude), you get ideal lift coefficients of 0.0, 0.256, 0.512

Of course, these charts are just at one Reynolds number.

What VSPAERO is doing is applying a very simple drag model strip-wise along the wing.  It calculates the local cl and then adds in a simple polar term that basically amounts to:

cd = cd0+K*(cl-cl0)^2

So, by adjusting cl0, you are just moving where the center of that polar is.  It is a very simple approximation.

Since the coefficient ends up multiplied by area (first by chord, then by span), I would say an area-weighted average is best.

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 visit https://groups.google.com/d/msgid/openvsp/3b75241d-b0f6-45e5-8ace-6c256631ec01n%40googlegroups.com.

[Mike Vivaldi]

Thanks Rob,

I'm running an analysis now based on your suggestions, it appears there is still a disparity between CLo and CLi resulting in a negative CLtot

What airfoil tool is that you posted?

Mike

[Rob McDonald]

Please post your *.vsp3 file.  All I can guess is that you've selected a Mach and Reynolds number that is making the simple drag model come up with obscene values.  Notice that the CDo term is enormous as well.

The parasite drag term is calculated for the airfoil - purely as a drag contribution (in the local direction of the airfoil section).  It is then resolved into Lift/Drag contributions on the wing -- so CLo starts out as a sectional drag coefficient.  If it is large, then we would expect the cdo to be excessively large for some reason.

What airfoil tool is that you posted?

It is a new OpenVSP feature that I'm working on.  Not released yet.

Under the hood, it is using libNeuralFoil to do the calculations.

At the same time, VSPAERO is being modified to use libNeuralFoil too.  Once that is complete, you won't need to put in clmax and cl0 numbers at all -- we'll figure them out ourselves.

These features will be released together when they are complete.

Rob

To view this discussion visit https://groups.google.com/d/msgid/openvsp/937bc922-df5f-4c07-98c7-4a5075d33d25n%40googlegroups.com.

[Mike Vivaldi]

Hi Rob attached is the vsp3 file.

Mach 0.23 Reynolds 41,720,500 which were based on the root chord and at that mach at sea level.

Thanks,

Mike

[Rob McDonald]

Well, your root chord is 12.36 -- while your cref is only 7.57, so your ReCref is off by about a factor of 2.

That said, when I run the case you're running, I don't see the problem in the load distribution, but I do see it in the total coefficients...

Now I see the problem.

You have a spike in your cl distribution.  That spike is about cl~1600!

So, that one section, when cl^2 is calculated, causes a huge influence in the cdo integral.  Even though it is only contributing over a small span section, it is so huge that it throws off the total load.

Fix the spike and you're in business.

You can probably play with the geometry and/or mesh at the intersections to try to resolve the spike.

Usually small spikes can be pretty much ignored -- but this one is so huge that it throws things off.

Rob

  

To view this discussion visit https://groups.google.com/d/msgid/openvsp/6eede519-4a2c-433b-903f-21b94f400517n%40googlegroups.com.

[Mike Vivaldi]

Hi Rob, 

So the chord at the wing/body interface is 10.9 meters so I used that as the reference chord for this run and recomputed the RE for M0.23. I also turned off X-Z symmetry and ran the case, the spikes at the 0m x-location disappears 

but with X-Z on the centerline spiked values reappear

Im not sure what might be happening here.

Thanks,

Mike

[Rob McDonald]

That looks like it is being caused by the vertical tail.

I'll have to take a look at what is happening with a vertical tail -- in thick mode -- on the centerline -- but with a symmetrical calculation.

I suspect that if you change any of those, the issue will go away.

Rob

To view this discussion visit https://groups.google.com/d/msgid/openvsp/76f64ae5-9dec-47bf-9af6-2ba9d4726130n%40googlegroups.com.

[Mike Vivaldi]

Hi Rob,

Yup, switching it to thin removes the spikes on X-Z symmetry.

Thanks,

Mike