effect of airfoil camber

[DomIno0o]

Hi,

What options do I have to incorporate the effects of airfoil camber?
At the moment I am saving the camber line to the airfoils group. Unfortunately, as soon as I add the influence of camber to my (static) simulation the results of Sharpy do not agree with those of a simulation in Nastran. To investigate the problem further, I used a simple clamped wing and again the results match those from Nastran only as long as I disregard the effect of camber.
The biggest difference appears in the wing torsion (moment), the deviation of the wing bending is much smaller.

As far as I see, I could alternatively use the constant value in the airfoil_efficiency array or an explicit polar.

What works best in your experience and how do you then calculate the moment at zero angle of attack?

Best regards
Dominik

[ACea15]

Hi Dominik,
that's a good exercise. What approach for the camber are you using with NASTRAN DLM aero? The DLM method does not incorporate camber effects natively (since it solves the linearised potential equations around x=0, i.e. panel's chord is aligned in the x-direction). One way around this is to introduce an artificial downwash to simulate the camber, is that what you are doing?
On the other hand VLM methods seamlessly allow for arbitrary geometries. The polars could be used, I guess, but those are more for CFD type of corrections and also you will not be able to deploy the full set of capabilities in SHARPy as when introducing the camber right on the panels geometry.
Maybe worth investigating the source of the mismatch? Let us know as this could also be a good example for us.

Best, Alvaro

[DomIno0o]

Hi Alvaro,

Thanks for your answer. As you suggested, I am using the DLM method in NASTRAN and adding artificial downwash to simulate the airfoil camber.
I am trying to find the source of the deviations at the moment and will let you know if I find something.

Best regards,
Dominik

[ngoiz]

Hi Dominik,

It could be worth checking the chord wise panel discretisation you are using in SHARPy, as it could be the source of discrepancies. When introducing camber, you require a much finer discretisation in order to approximate the cambered profile with the rectilinear vortex panels.

This will of course increase the cost of the simulation. You could start with a convergence analysis of this parameter, maybe with a horseshoe wake in order to keep the cost down. If it is a discretisation issue, you can then use the option to change the size of the wake panels such that your required discretisation on the wing does not penalise you too much on the wake.

Hope this helps,
Norberto

[DomIno0o]

Hi Norberto,

Thanks for you answer as well.
I extended my previous experiments regarding the chord wise discretisation.
In the chart below I plotted the wing tip deflection and wing tip torsion from both Nastran and Sharpy over the number of chord wise panels. I non-dimensionalised with the average of the respective displacement type which means that 1.0 in the diagram is not necessarily the actual value the simulations are converging on.
As you can see the wing tip deflection converges quickly in both SHARPy and NASTRAN but the tip torsion in Sharpy converges very slowly.

Maybe I have the wrong idea due to the different behaviour in NASTRAN but over 300 chord wise panels appears like a lot to me and you could argue that the simulation still hasn't converged to a reasonable degree.
The computational effort with static simulations is not really a problem because as you mentioned I can use the horsehoe wake. However, I don't think I can use this kind of dicretisation for a transient analysis...
Do you think there is anything I can change besides disregarding the camber?

Best regards,
Dominik

[ACea15]

Hi Dominik, 300 is A LOT indeed. First question to ask is what measure are you taking for the twist in SHARPy?
For a long time we have been thinking about creating a separate SHARPy cases repo in Github where we and the community can put relevant examples that go beyond the notebooks. This would help in terms of collaboration, debugging and also showcasing important features of the code.
Would you be willing to share your case with the Nastran files?

Best, Alvaro

[DomIno0o]

Hi Alvaro,

the above example is from a test simulation with a rectangular untwisted wing that I setup to analyse the differences in my actual case.
In my real analysis I use the twist property.

Yes, I am willing to share my code once I have cleaned it up (which might take some time) ;)
I have to ask my supervisor if I am allowed to use the real case data and in case he says no I could probably still generate an artificial data set.

Best regards,
Dominik

[DomIno0o]

Hi Alvaro and Norberto,

I just did another experiment by adjusting the way I calculate the downwash in NASTRAN.
In NASTRAN the doublets are placed on the 25 % line of the local aero box and the collocation points are placed on the 75 % line.
Thus, I calculate the artificial downwash via the slope of the airfoil at the respective 75 % line (as is commonly done in the literature).

As far as I understand SHARPy's code, you sample M+1 points on the airfoil which you connect to obtain your airfoil discretisation.
You then probably use the slopes of those panels to obtain tangential conditions for the collocation points.
If I obtain the artificial downwas with the same method in NASTRAN, I get very similar values as with SHARPy.

Is there an easy way for me to use the 75 % line as collocation points?

Best regards,
Dominik

[DomIno0o]

I am not well versed in C++, so please excuse me if I am completly wrong.
As far as I understand, you compute the collocation points in the file triads.h by taking the mean of all four points around it.
So the collocation point is placed in the centre of the respective aerodynamic panel.
However, during the construction of the aero grid points you shift all points by 25 % of the box chord which means you actually place the collocation point on the 75 % line.
For the tangential/normal flow condition you then use the normal of the aero box which - intuitively - I would expect to be used on the 50 % line.

If this is true, it would explain the behaviour that I described above.

Best regards,
Dominik

[ACea15]

Hi Dominik,

that is right, see image and explanation attached (from original UVLM implementation in Murua_thesis; also recommended Carre_thesis for the latest implementation). Basically shifting the panels is a way of imposing the Kutta condition (see Katz and Plotkin book), which in the DLM implementation comes naturally with the dublets as the wake is assumed flat to infinity.

are you planning on modifying the UVLM implementation? The shifting of the panels happens here; it should not make a huge difference if you remove it but the code has undergone plenty of validation so I would be cautious as to what to take as valid results if you change the current implementation. Have a look to the generate_colocationMesh in the header file geometry.h, and more generally the biotsavart.h for the core of the implementation.

Regards, Alvaro