"Proprotor 0.1" ... ?

[gibsonfvse]

So in the past few weeks, there has been some kicking around of aerodynamic ideas, as well as legitimate questions, on this board.  I'm currently working on a flight simulator for a professor of mine, and I know that much of this code can actually be moved over to the simulation of propellers and wind turbines rotors (hehe, there's that terminology issue again).  I've been kicking around the idea of writing such a code, and I may do it if I can find the time this semester.  I know such codes have been written before, just like there are thousands of flight simulators out there... but there's no learnin' like geek learnin' (geeks love reinventing the wheel), and in "starting over," I could write something based on the input of the community.

In my very brief studies of software engineering, I've grown to think that proper requirements gathering is the absolute key to good software.  I've also grown to think that when people talk of good software, they are often referring to software with an excellent user interface.  So I ask all of you: what would you like to see in such a program?  The question is about much more than a feature list.  It's about: how would  you like to -use- such a thing?  For example, one scenario I envisioned was that a user could specify the number of blades on a rotor and the blade geometry (chord distribution, twist distribution, airfoil), pick a range of wind speeds, and hit "run" to get some data plots on rpm, shaft power, and whatnot.  Or perhaps in another case, the user could specify a tip speed ratio and a design wind speed and have the program generate a rotor optimized for that design condition and return its geometry.

Basically, if you comment, think in terms of "actions and features I must have," as well as "actions and features that would be nice in a later version" and write about both.  Try to think about the interface: how should the software and the user interact?   I've not built a turbine before; my knowledge is mostly theory, and my own education is one reason why I started coming to this board.  I've learned lots from all of you so far.  Well, we'll see if the software gets off the ground.  

 - Chris

[TomW]

chris;

Might I suggest something that is cross platform or even web based interface? I like my OS X but it seems like all the cool software for this type stuff is Microsoft OS only.

Cheers.

TomW

[ghurd]

I would like to start with length, number of blades, and RPM/TSR, then work backwards to the blade design and power.  But I do stuff different.

I'll be limited on blade size, and can not just add 2 feet if the PMA needs it.

This is just toys for me. People who really need something will think about it different.

G-

[rotornuts]

I'd like to know how much you could load a specific rotor before it begins to stall.

Rotor = blades & hub

Oh and the ability to analyse low wind speed and start up performance under a user specified load would be a must.

But that's just what I'd want.

[wdyasq]

Chris,

A good look at what is available first would be a start.  Then, the user interface will need to be looked at.  I would like the ability to add airfoils to a library of standard airfoils. One might solve the generic problem then allow one of several actions - calculate known rotor; suggest rotor design; modify existing rotor, such as changing angle of whole blade.

While sliders and generic airfoils can give one and idea of where to start designing, a final software should be able to specify airfoils, specify twist at stations, transition airfoils and put out enough data to actually build the modeled turbine blade. As TomW said, it would be nice if it were platform independent.

Right now, my time is limited but I would be happy to discuss the project.  My e-mail is "Wdyasq -at- Yahoo -dot- com".    There is a lot more that might be included for a really great program, blank building, blank optimization roughing operations for CNC, finishing direction and bit selection, airfoils modification to make the thing cutable/buildable...... the list is near endless.

Ron

[Ungrounded Lightning Rod]

Others are already describing the functionality they'd like to see.  I'll defer to them on that - they've more experience in what is needed.

What I'd like to see, if you're willing, is for the project to be open-source and for the initial release to run (at least) on a Linux platform.

Releasing it for Linux means it can be used by people who aren't buying into the commercial platforms - but can be easily ported to run on those as well.

Releasing it as open source means it can serve as a starting point for functionality enhancements - either by yourself or others.  So if you didn't come up with the perfect user interface or every bell and whistle someone might need, such things can be added later without bugging you if you've moved on or been busied out.

[wooferhound]

Props are not my strong area, so I really don't know where to start.

In it's simplicity

I would like to input the Watts rating of my genny

the cut-in speed

maybe the blade count, maybe the program could suggest this to me

The software would output the: TSR, Tip angle, Hub angle, number of blades and length

I could then determine the all the construction details from there . . .

[brett]

This would be cool.

A java platform (for os independence) that will accept delimited, historical wind averages over say a choice of one month, two month, four month, six month (etc) for all of the above mentioned alternator and rotor properties.

That would give some dependable energy production projections over a reasonable time frame regarding your proposed alternator and rotor configuration(s).

Awesome idea.

Web based would be cool, grab data for projections from something like www.wunderground.com through the use of a html scraper, to collect the weather/wind data and store in a web server db to use on output projections maybe, hmm lots of possibilities for partnerships with weather data providers and cheap membership fees to access your software for the projection production.

Would like to hear of your final requirements.

Keep truck'in.

brett

[RatOmeter]

I don't know what degree program you're pursuing at school and it might affect the approach you take to designing software. I've been programming computers in one form or another since 1984 so I recognise that when you refer to software as "codes" that you are probably fairly new to programming. This could be a good thing as many veteran programmers tend to stick with what they know (like my tendency to stick with C), placing unnecessary limits on their work.

The earlier suggestion to use Java for cross-platform compatibility is probably the most valuable one yet. For example, if you only know Visual Basic for Windows and used it for this application, I guarantee that about half of the people here who could benefit from or enjoy it the most would never fire it up. There are other ways (languages, development packages) that facilitate cross-platform operation, but Java is probably the easiest to learn and the most valuable to you acedemically and professionally.

As to user interface and features, how about allowing the user to specify twist, taper and profile changes as mathematical (non-linear) functions along the length of the blade? As mentioned before, a data output format that is very usable is important too.

[gibsonfvse]

Thanks to all of you for your responses; I hope to get more comments.  I haven't exactly planned out the "tooling" yet, but if I do this, I will write GPL software and use cross-platform interfaces like wxWidgets.  The comment on Java is valid; I'm familiar with Java and C++, and both have their ups and downs.  Debating on languages is a bit like debating religions, however, so I'll see what my professors recommend on that point.  

I'm amused by RatOmeter's comment on the term "codes"; in the aerospace department I am in, the word "codes" tends to get kicked around still, even though software has come a long way from the days of Boeing's wave drag code in the 1950s and the first versions of XFoil (which is still written in FORTRAN, by the way).  So I was typing my post, and that word came out; I figured somebody would give me rub about it :-)  Well-done, RatOmeter.

So based on what's been requested so far, it looks like the core usees of such an application should be:

• Direct design method: specify rotor diameter and blade geometry (taper and twist distribution), plus inertial properties
  
• Inverse design method: specify rotor diameter, design TSR, design RPM, and design wind speed, plus inertial properties
  
• Tweak rotor geometry
  
• Generate plots: RPM vs. wind speed, shaft power vs. wind speed, efficiency vs. wind speed, with exportable data
  
• Predict stall regime
  
• Specify rotor shaft load in terms of torque vs. RPM
  
  

Complications: aerodynamics and airfoils

Most likely, the first versions will use the flat plate linear assumption from thin airfoil theory (cl = 2*pi*alpha).  The reason is because if I used airfoil data, I'd have to generate a database of polars (lift and drag coefficients vs. angle of attack) from profile data.  Note that I want to do exactly this, and I was already thinking about modding XFoil to go through websites like the UIUC Airfoil Coordinates Database and generate polars for a range of angles of attack and Reynolds numbers.  I better start that early, since it could take weeks or even months to generate all 1550 polars from the site  Once that's done, I could release the whole database of polars as a package.  However, there is another problem: transitioning of geometry and Reynolds numbers.  It makes perfect sense to (for example) specify a root airfoil and a tip airfoil and just interpolate the geometry in between, like wdyasq said, but I'm not sure the airfoil polar data can be interpolated in the same fashion.  I'll ask my professors on that, and hopefully I will like their answers.  Stall prediction is also tough, because the flow on any stalled surface is highly three-dimensional (and moving in the radial direction in the case of a prop or rotor).  So in a way, my "stall prediction" feature mightdouble as a "skeptical data beyond this point" feature.  It's important to remember that numerical tools like this are for estimation purposes; they tell you where to start, and then you go out and see if the tool was right  There are many aerodynamic models out there, and I'd like to eventually have a number of them in the program along with the option to choose between them or even get recommendations on which one to use.

Complications: alternators

I have no knowledge of alternators or their modeling; I can only imagine that simulating an alternator would be incredibly difficult, as I'm not sure if there are any assumptions of linearity one can make (can someone clue me in on this?).  Furthermore, an alternator's behavior depends on the whole circuit it's wired to, as we all know.  What I'd do, most likely, is tell the user to specify the alternator's torque vs. RPM curve to figure out the loading.  To get the electrical power generated, the user would have to specify an electrical power vs. RPM curve.  It's what would have to be done unless a way to simulate alternator behavior can be figured out.  So long as this data exists, wooferhound, the program should be able to do what you request.  I'll have to figure out more on the blade count aspect, though.

Anyway, I don't know who is still reading this post, but thanks for your comments.  I'd like to keep the discussion fairly nontechnical at this point because I really don't know all the technical details of the software yet (that comes later), but I wanted to bring up a few concerns I had.  I'll be graduating this semester, and I may or may not go to graduate school right away, so I'll be quite busy.  If things progress, though, I'll tell all of you.

- Chris

[gibsonfvse]

Also, I'll do the obligatory google search, but I'd like to ask directly: what design/analysis software for rotors are you people familiar with so far, and what do you think of them?  Note that "software" can be as simple as an Excel spreadsheet, and I think just such a thing has been done for Hugh Piggott's design methods, among others.

-c

[wdyasq]

This link has the bulk of it Chris:

http://wind.nrel.gov/designcodes/simulators/

Ron

[monte350c]

Hi Chris,

I have been using Profili quite a bit lately. It is essentially a front end that has XFoil in the background.

So for wind turbines it would be handy to have an automatic way to change parameters such as TSR, number of blades, and see the changes to chord and twist.

Profili has a fair number of preprocessed polars in its database, and you can easily upload any profile from a standard coordinate file. There's a feature to import profiles from raster files but I haven't tried that feature so can't really comment on its use.

You can produce tapered sections with it but not twist. There's pretty good coverage of Cl/Cd issues but the AOA is limited to 13 degrees.

You can blend airfoils, for example starting out with one profile at the root, blending to another at the tip etc.

It can output templates for wing cutting.

The web site is http://www.profili2.com/eng/default.htm

There's some good info on wind turbine airfoils, testing, comparisons, and the results between the X-Foil predictions and actual testing are interesting. Try this site and click the search button, try a search on "wind turbine airfoils" for example. This site has kept me reading for the past week or more.

Good luck with the project!

Ted.

[monte350c]

Oops forgot the link:

http://www.risoe.dk/

Worth a read!

Ted.

[gibsonfvse]

Thanks for this.  I am familiar with Profili (and the fact that it uses XFoil as a backend), and it is a beautiful application.  I had no idea about the polars database, though... now I know, and wow that saves me lots of coding and computer processing time  However, I don't know what the angle of attack limits are; I presume they are -8 to +13 deg, and if so, they would probably have to be extended.  Still, it's a great start.  Thanks for the "Risoe" link as well.

[monte350c]

Hi Chris,

You are right about the AOA limits.

One very interesting paper I read last night from the risoe site:

http://www.risoe.dk/rispubl/vea/veapdf/ris-r-1280.pdf

It's just over 2.5 mb - and has a comparison between X-Foil predictions and actual wind tunnel test results.

X-Foil still looks pretty good despite a slightly optimistic Cl in places.

The document is pretty interesting since it's all about profiles for turbines. albeit larger turbines.

Ted.

[wdyasq]

interesting program

http://www.grc.nasa.gov/WWW/K-12/airplane/foil2.html

Eon

[monte350c]

Thanks Ron - that's a fun simulator.

It's interesting to see the flow respond directly to your input - after poking around in X-Foil and Profili you can certainly get the numbers but - it would be kinda cool if a program had that sort of interactive element to it.

So as you're designing the ideal blade you could actually see the effects as you went along. I can just imagine the processing power THAT would need - doing the polars work and showing it 'live'...

The big challenge is in the actual production of the blade. If it's bumpy or otherwise not to profile then the efficiency is going to suffer.

I read a bit on the Enercon web a few weeks ago about their E70 turbine - it has a 50% CP at wind speeds of 8 to 10 ms. Pretty amazing.

Even though the wind is a free resource, it makes sense to try to be as efficient as practical/possible. An efficient machine should be lighter and cheaper to build if all the variables work out right.

It's all good fun in any case!

Ted.

[rotornuts]

Thanks ted for the risoe link, I've got my reading for the next month linedup off that site. I'm with you on the may as well make it as efficient as you can bit as well. I don't see the point in going to great strides to do a nice motor conversion or build a nice dual rotor just to throw out watts with your blades.

Some airfoil sim software written by Martin Hepperle, uses java.

http://www.mh-aerotools.de/airfoils/javafoil.htm