Replies: 1 comment
-
|
For anyone interested, I think this chordwiseOffset option that I added to my fork should hopefully improve robustness/variability with the offset. When that's set, I basically have it first project leList to the LE, then offset that by a specified amount in the chord direction. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I've been taking a closer look at a leading edge radius constraint in a benchmark optimization case, and noticed that it can vary quite a bit based on the polyline's offset from the leading edge. I have it defined like this (based on some previous help from Ali):
Among other things, I tried looking at the unscaled LERadius with varying LE offset, for the baseline Mach wing. Based on a quick google, the root and tip radii should be indicated by the dotted black and red lines here, with the other 20 lines being the span-wise stations across the wing:

I've tried basing the geometry on both STL and IGES models. The initial STL used a coarser unstructured discretization which seemed more problematic (larger offsets led to grossly overestimated values at the tip, at least for a certain design). However, making finer, structured STL and IGES models (with lots of refinement near the LE) still didn't smooth this out as I had hoped. Using a scaled quantity (LE/LE0) can make the response smoother, but it is still not as smooth as I'd like in certain regions of the design space, for example here:

(granted, the optimizer should've avoided this design, which was encountered when using the coarse unstructured STL, and the larger radii sections inboard do look smoother).
Does anyone have any tips on making this computation smoother?
Beta Was this translation helpful? Give feedback.
All reactions