Discontinuities in post-processed twist and t/c distributions

[shamsheersc19]

Type of issue

What types of issue is it?

• Bugfix (non-breaking change which fixes an issue)

Description

The post-processed twist and t/c distributions that ADflow outputs sometimes have spurious discontinuities and jumps. This is related to the script jumping between the upper and lower trailing edges of the geometry, or some equivalent jump, while calculating the twist using the farthest two points in a section.

For examples, see the twist and t/c plots in:

• "RANS-Based Aerodynamic Shape Optimization of a Strut-Braced Wing with Overset Meshes" (https://arc.aiaa.org/doi/pdf/10.2514/1.C034934)
• "Undeflected Common Research Model (uCRM): An Aerostructural Model for the Study of High Aspect Ratio Transport Aircraft Wings" (https://arc.aiaa.org/doi/pdf/10.2514/6.2017-4456)

Expected behavior

There shouldn't be spurious discontinuities and jumps.

[shamsheersc19]

Any takers? @jrram @marcomangano @A-Gray-94 @sseraj

[shamsheersc19]

I don't have a general solution in mind for the ADflow code. I'd suggest a post-post-processing script that runs through the points, checks when there is a sudden change greater than some value, and shifts the points up or down using an average of the forward- and backward-FD slope estimates at the discontinuity to estimate how much the change should actually be.

Also, we should make a note somewhere in the tutorial so that we avoid publishing further results with these issues.

[eirikurj]

Adjusting/refactoring ADflow to eliminate this completely I think will be difficult since there will likely always be some "inconsistency" where the slice cuts through the grid/states. This depends on the orientation of the grid relative to the slice. Its possible to improve the orientation of the slices but again it will be case dependent how successful this is.
In any case adding some post-ADflow data smoothing script is a good solution in the short term.

[A-CGray]

I can't really prioritise this anytime soon as I'm working on merging in my thesis work to pytacs and improving the MACH tutorial before next term starts. However, I have a vague idea that might be worth trying for whoever gives this a go:

The code responsible for this issue is here, where we loop through all pairs of points in the current slice and then select the pair with the greatest distance between them as the leading and trailing edge points for computing the chord and twist etc. The discontinuities in our plots occur when the chosen trailing edge point switches between the upper and lower point of a blunt trailing edge.

We therefore might want to try modifying this process so that we identify both points at the TE and use the average of their positions for all these calculations. You might be able to do this by also saving the point pair with the second highest separation distance, or maybe just testing the distances between the points adjacent to the chosen pair and somehow using that to identify the upper and lower TE points.

All this correction is only necessary for a blunt TE so we probably want to either write the code to be able to tell if the TE is sharp (might be hard) or just add an option to the addLiftDistribution method to switch between the two methods.

[gawng]

@sseraj @hajdik and I discussed today during the workshop that a short-term potential solution is to add an optional call to preFoil since preFoil, from what I have been told, picks up a single TE point and does NOT jump. preFoil would process an adflow output file.

Something like
CFDSolver.addLiftDistribution(*args, distributionMethod="preFoil")

This creates a soft dependency on preFoil.

The real issue here is the LE and TE search algorithm from ADflow. That has downstream effects on the plotted twist and t/c distributions.

Extra:
Other options discussed were using differences from embedded points in pyGeo to get a delta twist (or t/c) of the opt versus the baseline. But this is really only good for baselines w/ no initial twist and a known initial t/c dist.

[eirikurj]

@gang525 since I missed the discussion, can you add a little more detail on what other methods you discussed and then specifically how approach this is supposed to work. I am not sure how processing the output files, which have the issue we are talking about, will address the issue? I probably just don't have all the details here. This will also create a soft dependency on prefoil (assuming you want to use this option).

[marcomangano]

@eirikurj haven't followed the discussion but prefoil can re-parameterize the airfoils from the "point cloud" using pySpline routines and has a more robust method to find the LE. I assume the plan is to have a routine in pyADflow that calls prefoil for every station in the "lift distribution" file and handles all the geometrical parameters in a more robust way.
This would avoid fixing ADflow postprocessing routines directly but I think we need to understand the impact of the added dependency and maybe computational time?