It’s working really well for me. Thanks a lot for teaching me how to point Rhino at your script from within command line. That is fantastic, and has me thinking that I will start learning how to write these, because so many batch operations that I’ve done in the past to say, build out a wing and then slice it into intermediate wing sections, could be performed with some basic knowledege of the language (though that does take some of the fun out of modeling in Rhino).
As far as any future features, it might be helpful to have the option to close the trailing edge on some of these sections. If that is not a lot to ask as a feature built into the code, it would be icing on the cake. It’s by no means necessary as one can just grab the endpoints and join them with a line, though it could help in the case of how Rhino deals with generating blended section fillets; which is to say that it has problems when the math isn’t correct. Having a trailing edge curve project to a finite point–in the case of these .dat files–to the right of imported airfoil, should allow for that. It can be done manually thinking off of past experience by extending curves until they intersect, trimming one with the other, then joining them, or doing a simple interpolation (think reading the coordinates all the way around in a circle). The latter approach may lead to deformed trailing edges when the airfoils have dramatic undercamber or other complexities, though if you don’t mind, it would be fun to play with as script command.
If you are curious to refine this script and have the time to dedicate to doing so, I would propose the options to:
Read .dat natively (just how the script functions now)
Close trailing Edge curve (add a line between the first upper TE and first lower TE points if the generated curve is open)
Interpolate Trailing Edge (if the generated curve is open)
Extend Trailing Edge (extend, trim, close curve, delete orphaned segments) again if the TE curve is open.
Here is a pipe dream since I imagine this is CPU-intensive and probably would require a lot of time to write, though I do not know for certain. Is there any way to generate a preview pane drawing of the .dat that the user is browsing? This would be slow on older Macs since the script would essentially be running on every set of coordinates that the user single-clicks on in the start dialog, though I’m genuinely curious what your thoughts are on the matter.
OK, so It’s working great. Here is batch of tests firing off a wide variety of options from the aerospace community and using the new functionality of curve knot options. Only that one b737a.dat airfoil comes out wonky, and reconfirmed that the points are simply in the wrong location for a fair curve to exist.
This is fairly easy to do. (note you can also select the profile and call CloseCrv in Rhino and it will draw a line between the ends and join it automatically).
This is also not too hard to do in principle, be the same as creating a Rhino BlendCrv between the open ends. However, there are actually an infinite number of different blends possible from “nearly flat” to “almost sharp”. The only fully determined one among these would be a specific radius (fillet).
This is again somewhat laborious to do in cases other than a linear extension, although possible. It is necessary to extend both curve ends an arbitrary amount that will result in an intersection; then either trim back to the intersection or (easier) find the intersection, then on a copy of the unextended curve, extend that to the intersection point on both ends.
I’m afraid that largely exceeds my programming skills.
This is of course true. My own foils included. As mentioned, it’s for modeling aids as the fluid dynamics involved simply do not matter when designing a wing/lifting body on a small scale, or for low velocities/low reynolds numbers. Rhino has historically been a poor performer with generating fillets, however, and this is where having the curve close does help improve the user’s ability to blend surfaces with clean isocurves; it’s less to do with say something you might output to CAM processes than it is for the integrity of the visual model.
OK, yet another command I’ve learned from you–this is shortcut to something that I’ve been doing manually for ages /scratches head
This sounds like an area that I should explore for my own skills. Thank you for once again pointing out another modeling tool.
OK, when looking at your code for V1 of the ImportAirfoilData.py I did take note of how much markup went into adding the new features, and as mentioned these were just thoughts for stretching the script as to begin taking on some really powerful automation. To be clear, I’m really excited to have V1 working it’s fantastic, and thank you again.
And I’m guessing that adding previewing panes (calling subroutines from your script and window management stuff?) starts falling into the plugin category pretty much right away. It’s working, so pardon my ignorance re: complexities involved with getting RunPythonScript to do more than is good for the programmer.
Alright Mitch, please let me know if you’d ever be interested in building a model airplane of novel design, and perhaps we can collaborate on a project. I’m much obliged, and really looking forward to making a new, elegant model with the aid of your script, and then of course building the damned thing
Some of that markup is fancy UI, if you want to program different command-line options (numbers, booleans, lists) on the same line, you have to dive down into the RhinoCommon Get() methods, which take a significant amount of lines of code.
The rest was a complete re-write in an attempt to use the data provided in Lednicer format in the second line to determine the number of points that should be in each section instead of “hoping” that the two sections would always be separated by a blank space; the idea was to be as robust as possible when parsing the file.
This is indeed fantastic! I’m trying to bend the NACA 2424 airfoil which I imported using the ImportAirfoilData.py script to conform to a circular arc chord line having a length of 1.85 inch but am not having much luck with Transform > Bend. Do you have any pointers on how I might accomplish this? I’ve tried generating the shape using perpendiculars to the curved chord and then using Curve > Free-Form > Interpolate Points, but the upper surface dips at the point tangent to the leading edge circle. I would much prefer using the object created with the ImportAirfoilData.py script than what I drew…
FWIW: The coordinates and leading edge radius I used are in the txt document.
You might try Flow and flow the airfoil from a line (the centerline of the airfoil “flat”) to your arc curve… Don’t know if it will work any better. --Mitch
Edit: I just downloaded a NACA24 and imported it via the script - the leading edge is pretty wonky - these airfoil data files don’t seem all that accurate to me. I would do some adjustment on it before curving it, but once done, using Flow as described above looks pretty good.
[quote=“Helvetosaur, post:29, topic:26362, full:true”]
Most likely, but this seems to be a turbine blade… --Mitch
[/quote] Turbine blades can be as sensitive as aircraft wings to deformations of the shape, depending on the turbine. David
Most certainly… I don’t assume to know what the OP’s design intention is here, whether it’s simply to get something that looks clean and correct or if it’s intended to be functional.
I’m not getting notifications on updates to this thread. I thought I had offended someone! I just dropped in again to be reminded of the script name and saw your comments. Thanks for all your input. The ImportAirfoilData.py script seems to have worked perfectly for me with the NACA 2424, Mitch. Thanks.
It is intended to be functional. It’s for a fan, not a turbine, and it’s got to be really smooth or the flow will separate (stall the blade) and the performance of the fan will not be optimal.
I have found that using Pascal Golay’s tips seem to have solved the problem l had with Transform>Bend (in a different thread titled 2D Bend) by doing the following: “…set the CPlane to the desired bend plane, or parallel to it, and then use Project on object snaps to make sure all your pick points stay in plane” for bending the volute.
Now that I’ve learned how to keep the pick points in the CPlane, I’ll give it another go. Thanks again!
The following link explains why I chose NACA 2424:
Hi David,
You are correct about the sensitivity of blades (this is for a fan, not a turbine, but the principle is similar).
I’m a former pro pilot (ATP ASMEL, scheduled regional carriers and corporate) and flight instructor (CFII - ASMEL) and I am reminded of an instance when an airplane, I forget the make and model, had it’s leading edge painted. The painter masked off the leading edge span-wise and, as the story goes, after the paint dried and the tape was removed the aircraft later crashed on takeoff. It seems the imperfection, the ridge of paint left behind from the masking tape was enough to disrupt the laminar flow over the leading edge and to cause the wing to stall at a much lower angle of attack.
The design of my fan is based upon specific given inlet and (different) outlet blade angles. The chord is a backward inclined circular arc, common in blade designs Please see my reply to Mitch’s comment, for the reason behind the choice of the NACA-2424 airfoil.
Thanks.
I have only just stumbled upon this by accident (got no notification), hence my silence so far.
Re fitting data to the UIUC database points - this is quite a tricky undertaking and raises a lot of interesting questions - for example, where is the leading edge point? (not always at the zero abscissa!) How do you ensure slope continuity? How much regression (i.e., departure from the data) do you allow in the interest of getting a smooth curve? Do you close the trailing edge with a short line (on airfoils with finite trailing edges) or do you tweak the points to get a sharp trailing edge?
In AirCONICS (https://aircraftgeometrycodes.wordpress.com/airconics/) we went to great lengths to deal with these issues and to make the process as simple as possible and there are some example scripts there illustrating how to do things and how to build a wing, etc.
There is more info on all of the above in our book too, where you can find some detailed explanations around some of the Rhino / Python scripts - but that is more from an engineering design perspective, for pure, non-parametric geometry modelling the scripts should be fine, you won’t need the book.
We use these geometries extensively in design optimization studies (with CFD analysis) - being able to drive Rhino in a scripted fashion has been extremely useful for all that…
But something is strange. I the AirConics input is the txt files 737c.dat then there is a lot of error between faired profiles and original data. 737airfoils-AirConics-with-Original.3dm (571.8 KB)
