Xfoil stuck in Airfoil Database

[Lucas]

Hi,

First I'd like to say that MachUpX and Airfoil Database are awesome tools and I'm really pleased with it.

Currently building a database for a XF-12 profile and I have somme issues. It works well if I build it between -5 and 5 but as soon as I extend the domain to 9° and above, there are some issues.

Some values will not converge as I saw in XFLR5 but XFLR5 doesn't get stuck by that and can continue calculations up to 20°. However, using AirfoilDatabase every non-convergence freezes the Xfoil window and the program is therefore stuck. Usually people get around that by setting a timer to close the calculation and continue to the next angle of attack.

How can I deal with this issue in Airfoil Database?

Thank you,

Lucas

[Cory]

There's not really a way to get past that in AirfoilDatabase. It's set up such that it passes all the angles of attack it needs to Xfoil at once. Then it just accepts whatever Xfoil is able to return from that list. So if execution fails at any point, whatever has yet to be computed just gets forgotten.

[Lucas]

Hi, Thanks for your response.

I solved this issue by generating a database with XFLR5 and compiling the data to suit AirfoilDatabase input. I am now using MachUpX with this database and it is working fine but approaching the non-linear part of the polar results can be a bit off, depending on the relaxation (r in the figure) and the grid. For some angles above 12° I sometimes get negatives CL although the stall in 2D is around 21°. Between those extreme values there are some values that seem fine.

Have you ever heard of those values and how to deal with it?

Thank you,

Lucas

[Cory]

That is very odd. By relaxation, I assume you mean the nonlinear solver relaxation? If your solution has converged, then the final result should be the same no matter the relaxation. Are you truncating the nonlinear solver iterations?

In the figure you sent, are those all with the same grid?

Have you plotted the values in the airfoil database you are providing to MachUpX to make sure it looks like it should?

[Lucas]

Thanks for your answer.

That's indeed what I meant for relaxation. I think I have a better understanding of what is happening. First let me precise that in the figure the grid is identical and that the airfoil database seems to be ok.

I tried to reproduce this case (click here) with XFLR5 and have yet to do it in MachUp.  But what happens is that at 13.5° the total angle of attack computed is 30°. It stops XFLR5 because it can not interpolate but it doesn't stop MachUp because I use the polynomial fits. Instead it gets the values computed with the polynomial fits at 30° and that gives negatives lift coefficients and it achieves convergence with those values that are non-physical.

I have  to try the same case as the technical paper to see what happens, but they manage to get results from XFLR5 lifting line where I don't because of this. I am pretty sure that the same issue happens with MachUp and that's the only way negatives lift coefficients can be achieved.

Thank you for your time,

Lucas

[Lucas]

Hi again,

I have more informations that might help. I tried to reproduce the same case at the research paper I linked to you on my previous message below. Basically, it is a 9 Aspect Ratio trapezoidal wing with a NACA 64_210 airfoil. Visualizing the lift distribution where the algorithm manages to converge but to non physical values gives some information :

Problems appear slightly over 10° whereas in the paper they successfuly descibres the stall at 13°. To be precise, they did that using MachUp and not MachUpX. At 10°, before any trouble the lift distribution is :

At 10.15°, distributions starts to be a little bit weird

From there it just gets worse (10.3° below):

With an associated total AoA :

I don't know why, but it converges to such solutions.

JSON and fit are below.

Thanks,

Lucas

Le vendredi 23 avril 2021 à 18:03:38 UTC+2, Cory a écrit :

[Cory]

Have you tried plotting the actual airfoil coefficients against those predicted by the polynomial fit? Looking at your fit file, it's using a 5th order polynomial fit in angle of attack for CL. I would not expect that to give good results, especially at higher angles of attack.

[Lucas]

Hi, I did after your answer and it seems good enough. CL correlation coefficient is over 0.99. Thanks for all your answer, I think I'll skip this case I don't know how they ran it on Machup in the technical report but it seems too tricky. I'll bother you one last time :

Currently working on a wing and would like to refine at the wing at the winglet (like a close uniform spacing on this part of the wing). However, it seems that you can't have several distributions on MachUpX along the span.

I tried with cluster point but with it being very clause to the tip, it doesn't work well at the tip (discretization is lower than with no cluster points). See attached files for more details.

Thank you very much,

Lucas

[Cory]

Sorry you couldn't get that working.

As for refining the grid, the best way to do that would be to model the wing using two different wing segments, one for the main portion and one for the winglet. You could then specify a denser uniform or cosine-clustered grid on the winglet.

[Lucas]

Hi,

Thanks that was indeed the way to go. Offset of 0.0001 like indicated in the MX documentation was not enough but 0.001 worked fine. Now i'm working on the flaps configuration,  a great convergence will be difficult to achieve but I'll see.

[Lucas]

Hi again, sorry I have one more question about the generation of linear database in AirfoilDatabase. I'd like to try this because it is easier to converge.

Generating the polynomial  fits creates no issue but I cannot get the command airfoil.generate_linear_model to work. If I don't specify linear_limits, I get "The inputs to the airfoil polynomial fits fell outside the bounds of available data) even though If I use the same command with get_CL (eg the same Reynolds) it has no problem to gather the data. If I specify linear limits, again within the boundary it says :

CL[i] = self.get_CL(alpha=np.radians(a), **kwargs)

IndexError: index 30 is out of bounds for axis 0 with size 30

The linear_limits format I chose is [alphamin,alphamax] in degrees. The format is not specified so it is only a guess.

How is it supposed to work?

Thank you,

Lucas

[Cory]

You're specifying linear_limits correctly. If you don't give them, does a graphical window appear asking you to select the bounds? Is that error being thrown by the airfoil.generate_linear_model() function?

I see what's going wrong with the IndexError though. I'll get that fixed and push the update.

[Cory]

The fix is pushed.

[Lucas]

Hi Cory,

Thanks for your quick fix it works perfectly.

I'm now thinking about flaps implementation on the wing and as with the winglet it would help to have a better discretization. From what I understand when you talked about that, the best solution is to create another entity (wing) to do so. The probem I have is that it works with an "y_offset" of 0 unlike the winglet but it doesnt act the same that when it is defined on one wing.

See the attached picture made for testing, it is a wing with the same airfoil along the span defined in 1 wing (black) and 2 wings (red). What you see if the lift distribution along the span and unfortunately there is a huge drop where the 2 sections are connected. How should I deal with that?

Again, thank you for your time and your code.

Lucas

[Cory]

Have you made sure to explicitly tell MachUpX the two segments are still part of the same wing? You do this by setting "wing_ID" under "grid". your center, flap, and winglet segments should all be given the same "wing_ID".

[Lucas]

Hi Cory,

I was not aware of this option at first but yes I applied it before your answer.  Here is what the wing definition looks like :

https://justpaste.it/machupxgrid

The wing_ID in grid (flaps section) is indeed 1.  Also, y_offset is 0 on this one because it works well with that (but with the winglet I had to increase it as specified in the doc).

EDIT : Thanks, wing_ID must be set to 1 also on the center part that was my mistake. Again, thanks for your tool and for your time.

[Cory]

No problem. So specifying the wing_ID fixed things?

[Lucas]

Yes, In fact I specified but the wing_ID but only on the flaps section. I was thinking that wing_ID refers to the ID of the wing. But as you explained it is independant, so each section must be attributed a wing_ID under grid to be connected.

I know that is not yet planned to create a parameter like in AVL to simulate ground effect, but do you see any problems with handmaking the symetry by creating 2 wings?

[Cory]

I don't see any problems with that.