Thread Tools
Feb 08, 2014, 09:42 AM
Registered User
Hey Dan,

I'll have to try out your new tools. I finally got back to playing around with this stuff again myself and thought I'd see if you still had your fingers in this.

Mark
Sign up now
to remove ads between posts
Feb 09, 2014, 09:14 PM
Sink stinks
Montag DP's Avatar
Thread OP
Quote:
Originally Posted by markschaffin
Hey Dan,

I'll have to try out your new tools. I finally got back to playing around with this stuff again myself and thought I'd see if you still had your fingers in this.

Mark
Sounds good. I've just recently gotten back into it myself, because I finally have some time and I want to design a new plane soon too. I intend to post an update to the code soon with the ability to use new shape functions, and also with a compiling guide and user manual.

I'm currently chasing something that seems to be a bug, but I'm not totally sure. There's some weird behavior going on where the optimizer keeps converging to a design with an unbelievably good CD at CL = 0. However, when I write out the airfoil coordinates and run it through XFoil (either my modified version or the original XFoil code), it says the CD is more like what would be expected. The behavior only seems to occur when the airfoil is constructed from the seed airfoil + shape functions, but not when read from a file, even though the coordinates should be identical. So it's a little confusing, but hopefully I can work it out soon and then post the update.
Feb 09, 2014, 09:43 PM
Registered User
At work, we refer to bug solutions as process improvements.

I got your code built and running, but stopped it as I had my own stuff running and my anemic laptop is, well, anemic. Some references to your perturbation method would be nice to see.

My system is set up to run everything via python scripts with the goal of testing out the many free derivative free optimization tools, as well as maybe finally getting AVL in there, as well. I tried developing my own swarm routine, but it never worked out correctly.

I'm set up to run an unlimited number of cases with the freedom to specify flap deflection, transition, Re, and ncrit as part of the case specification. My optimization function can vary for each case with most of the same targets as you have, but I also included transition location. I've got a script that checks the max thickness as well as the thickness at an arbitrary number of locations. It also checks for max curvature (gdes:clis) to keep the LE from getting sharp. To start with I've been running the GA by D.L.Carroll, but there are others I want to try out.

I'm not really sure what I'll do with it yet. Still think I need to couple AVL with XFOIL to get something like XFLR, but scriptable. I think the real advantage will be to use AVL with an optimizer to get the handling qualities you want. It's fun to mess around with, though.

Hope your research is going well. Still using FUN3D?
Feb 10, 2014, 11:47 AM
Sink stinks
Montag DP's Avatar
Thread OP
Quote:
Originally Posted by markschaffin
At work, we refer to bug solutions as process improvements.

I got your code built and running, but stopped it as I had my own stuff running and my anemic laptop is, well, anemic. Some references to your perturbation method would be nice to see.
That's a good point. I have the references I used saved, so I'll just add a References directory next time I update the code and put them there (hopefully there aren't any copyright issues with the papers - I will have to check first).

Quote:
Originally Posted by markschaffin
My system is set up to run everything via python scripts with the goal of testing out the many free derivative free optimization tools, as well as maybe finally getting AVL in there, as well. I tried developing my own swarm routine, but it never worked out correctly.

I'm set up to run an unlimited number of cases with the freedom to specify flap deflection, transition, Re, and ncrit as part of the case specification. My optimization function can vary for each case with most of the same targets as you have, but I also included transition location. I've got a script that checks the max thickness as well as the thickness at an arbitrary number of locations. It also checks for max curvature (gdes:clis) to keep the LE from getting sharp. To start with I've been running the GA by D.L.Carroll, but there are others I want to try out.

I'm not really sure what I'll do with it yet. Still think I need to couple AVL with XFOIL to get something like XFLR, but scriptable. I think the real advantage will be to use AVL with an optimizer to get the handling qualities you want. It's fun to mess around with, though.
That sounds really cool. I thought about trying to wrap an optimizer around AVL but decided that for now I'd rather just do things by hand. It would probably be tough to get it work right. AVL + XFoil would be a nice tool, though. It would definitely save the time required to add in the viscous drag manually. I know you can do it with XFLR5, but I've never really "dug" the interface. Entering in dimensions by hand every time is too clunky.

Quote:
Originally Posted by markschaffin
Hope your research is going well. Still using FUN3D?
Thanks, and yes it's going quite well. I finished all my classes last semester, which is why I have a little extra time now. I'm still using FUN3D, doing bluff body aerodynamics and dynamics. I'm hoping to be done, or at least close, by the end of 2014.

Dan
Feb 11, 2014, 10:01 AM
Sink stinks
Montag DP's Avatar
Thread OP
Well, I figured out where the "bug" is coming from. It turns out it's not actually a bug, just an idiosyncrasy of XFoil. For this particular design, if I give XFoil the coordinates to a high level of precision and with a particular set of options, it predicts a very low drag coefficient at Cl = 0. However, if I write out the coordinates to the nearest 10 digits or so and run XFoil on that, it predicts a higher, more reasonable drag coefficient. Alternatively, if I run it with the full precision but change some other small XFoil parameter (like the viscous convergence acceleration parameter VACC), it gives the lower, more reasonable drag coefficient.

Unfortunately, there's not really a good way to prevent this, without increasing cost by a lot. Optimizers will always exploit these non-physical idiosyncrasies of the aerodynamic solver, if they exist. I noticed this same problem when I was using Matlab and running XFoil externally. I ended up just running XFoil twice at each operating point with a slightly different initialization point, and keeping the result with lower performance. I'm not sure I want to resort to that, though. For now, I'm going to try just adding another operating point for this case and see if that can keep things in check. Maybe I will look into adding another input in the operating_conditions namelist to couple two operating points together, and keep the worse one. That way, the user can do it selectively for only one operating point, if needed, instead of automatically doing it for all the points.
Feb 11, 2014, 10:12 PM
Registered User
I've never seen that before, but then again... 10 digits? I would think for a chord of 1, 5 decimal places would be more than enough.
Feb 11, 2014, 10:55 PM
Sink stinks
Montag DP's Avatar
Thread OP
Quote:
Originally Posted by markschaffin
I've never seen that before, but then again... 10 digits? I would think for a chord of 1, 5 decimal places would be more than enough.
I know, it's pretty bizarre. You'd think that any digits after that would have a negligible impact on the result, but apparently it can happen. Alternatively, if you just change the Reynolds number or another parameter by some tiny amount, the performance reverts back to what you'd expect. I've confirmed that this happens with the actual XFoil code too, not just my modified version of it.

I'm pretty close to releasing an updated version of the code. It will have a new option for shape functions (for parameterization) and also the ability to make XFoil automatically double check any of the operating points for that unusual condition. Hopefully it won't need that treatment often, but the option is there.
Feb 12, 2014, 06:04 AM
Registered User
Can you attach a couple of files that show this behavior? I'd like to see if I can make this happen.
Feb 12, 2014, 10:46 AM
Sink stinks
Montag DP's Avatar
Thread OP
Quote:
Originally Posted by markschaffin
Can you attach a couple of files that show this behavior? I'd like to see if I can make this happen.
Alright, here you go. I have a certain test case which always seems to have this happen. Two copies of the same airfoil are attached, one with coordinates to the full precision and another one with them truncated to 9 significant digits. I run them with the following XFoil commands in XFoil 6.97:

PANE (default paneling options)
OPER
VISC 3e5
ITER 100
CL 0.0

The full precision case gives CD = 0.004863. The rounded coordinates case gives CD = 0.013403. If I run the full precision case again but set the Reynolds number to 2.999e5, I get CD = 0.013406. Let me know if you get the same thing. Since it seems to be so sensitive to tiny numerical changes, it wouldn't surprise me if it doesn't happen on a computer with different architecture or with different compiling options.
Feb 12, 2014, 07:18 PM
Registered User
Hmmm, didn't happen for me. My first attempt at running the full precision did have more trouble converging, but both gave me 134 counts of drag.
Feb 13, 2014, 10:25 AM
Sink stinks
Montag DP's Avatar
Thread OP
Quote:
Originally Posted by markschaffin
Hmmm, didn't happen for me. My first attempt at running the full precision did have more trouble converging, but both gave me 134 counts of drag.
Yeah, like I said, that's not very surprising. I bet if you ran the same test case on your machine, a similar thing would happen. For some reason it seems that the new shape functions I just added are better at finding these XFoil quirks. The double-checking procedure I implemented has so far always worked to fix the problem, though. I plan to release the updated code today.
Feb 13, 2014, 01:52 PM
Stable genius
vespa's Avatar
I wonder if it's just a quirk in your processor or OS. Computers are notoriously bad at math and that's an obscene number of digits to be crunching. Looking closely at your attached files I see all the typical lumpiness of a typical low resolution coordinate file, what's the point of 17 decimal places on a crude lumpy airfoil that originated with maybe 2 or 3 decimal places?

If you scaled that airfoil up to the length of a 747 root chord (54 feet!) you would still have precision to 0.000000000000006". Or about a trillion times more precision than anything mankind has ever built. At model scales, you're specifying precision on the order of electron diameters.
Feb 13, 2014, 01:59 PM
Sink stinks
Montag DP's Avatar
Thread OP
Quote:
Originally Posted by vespa
I wonder if it's just a quirk in your processor or OS. Computers are notoriously bad at math and that's an obscene number of digits to be crunching. Looking closely at your attached files I see all the typical lumpiness of a typical low resolution coordinate file, what's the point of 17 decimal places on a crude lumpy airfoil that originated with maybe 2 or 3 decimal places?

If you scaled that airfoil up to the length of a 747 root chord (54 feet!) you would still have precision to 0.000000000000006". Or about a trillion times more precision than anything mankind has ever built. At model scales, you're specifying precision on the order of electron diameters.
Of course you're right, but remember that to a computer everything is "exact." Even if you give it a file with three significant digits, it will still store it and work with it as a real number with 8-bit precision or whatever the compiler told it to. The only reason I wrote the file out with 17 digits in this case was because it actually made a difference, as illogical as that seems. That's why I referred to it as an "idiosyncrasy."

As to whether it's a problem with my OS or compiler, I guess the only way to find out would be to run the test case on a different machine enough times to be sure (the optimization algorithms incorporate randomness, so the result isn't going to be the same for two different trials). If it doesn't happen on any other setup, then that's great, but I kind of doubt it.
Feb 13, 2014, 08:16 PM
Registered User
One way you could probably take care of this would be to load the airfoil into XFOIL, then save it from XFOIL and run that new file. I think that writes things out to about 6 decimal places.

Just out of curiosity, what compiler did you use to build XFOIL? I used the Intel compiler, which you can get for free as long as you don't do commercial work with it.
Feb 13, 2014, 10:04 PM
Sink stinks
Montag DP's Avatar
Thread OP
Quote:
Originally Posted by markschaffin
One way you could probably take care of this would be to load the airfoil into XFOIL, then save it from XFOIL and run that new file. I think that writes things out to about 6 decimal places.

Just out of curiosity, what compiler did you use to build XFOIL? I used the Intel compiler, which you can get for free as long as you don't do commercial work with it.
I'm using gfortran, which is also free and very easy to obtain since I'm on Linux. Vespa did get me thinking, though, I wonder if I were to just compile the code as single precision instead of double precision (so 4-bit reals instead of 8-bit) if that would take care of the problem. Because he's right that such high precision is certainly not needed for what I'm doing. I'm going to give that a try and see if it prevents the problem from happening.


Quick Reply
Message:

Thread Tools