#593 YASim does NOT converge for small, high RPM propellers.

[Anonymous]

Originally created by: i...@beware.dropbear.id.au

*What steps will reproduce the problem?*
1. Select a model with a high rpm propeller such as Rascal110-YASim.
2. Run eg proptest Aircraft/Rascal/Rascal110-YASim.xml

*What is the expected output? What do you see instead?*
Prop RPM should smoothly increase up to 100% throttle. What is actually does is max out at 5271.2 rpm with   throttle at 0.444.

*What FlightGear version are you using (when using GIT version, please
mention date)?*

version/2.4.0-final 2011-08-14 00:25:07

*What operating system and graphics card?*

Fedora 16 i386, Nvidia GT520

*Please provide any additional information below or as attachment (Avoid
expiring external links, such as to imageshack/pastebin/...).*

This is due to yasim:PropEngine:stabilize which iterated starting at 52 rad/s and increasing by 5 rad/s a maximum of 100 times to a maximum 552 rad/s or 5271.2 rpm. There is no way this algorithm can stabilise for a prop going any faster, but model planes can easily have props going over 10000rpm.

The solution is to scale the step size and starting angular velocity for the aircraft. Fortunately both TurbineEngine and PistonEngine models have some kind of "maxrpm" parameter which can be used for this purpose. Patch attached.

[Anonymous]

Originally posted by: i...@beware.dropbear.id.au

Err, in the title that should be "does NOT converge".

[Anonymous]

Originally posted by: emili...@gmail.com

(No comment was entered for this change.)

Summary: YASim does NOT converge for small, high RPM propellers.
Labels: FDM YASIM

[Anonymous]

Originally posted by: bre...@gmail.com

Similar to #594, I'd like some FDM expert to comment.
Again, maybe Andy could do us the favour?

Related merge request (unfortunately also contains changes of merge request 21):
http://www.gitorious.org/fg/flightgear/merge_requests/22

Cc: andy.ros...@gmail.com
Status: NeedInfo

[Anonymous]

Originally posted by: andy.ros...@gmail.com

The whole PropEngine::stabilize() mechanism is a terrible hack.  It really should be integrated into the solver (because engine RPM is for obvious reasons not an independent variable).  This fix is no more or less so.  If it doesn't break anything, I don't see why it shouldn't be merged.  But note that it will change the starting RPM and step size for a bunch of aircraft, so someone will want to test all of them to verify that the solutions didn't flip out.

[Anonymous]

Originally posted by: i...@beware.dropbear.id.au

While I can't claim to have tested every model (which would potentially include private hangers) I have tested a range of models.

[Anonymous]

Originally posted by: andy.ros...@gmail.com

Sorry, I must have missed this in March.  The patch looks sane to me, though I'm not set up to try it.  The engine stabilization step in the solver is a hack, and it surely wasn't designed for model planes.  But the way the math works any solution finder should get you the same answer.  Ideally this would replace the PropEngine::stabilize() routine with one that didn't require tuning, but I don't see how this can make it any worse.