RE: [Flightgear-devel] YASim turbo/supercharger issues
Some time ago I wrote: > > Andy Ross: > > > > If you do mean this equation then I can certainly live with that. If > > > not, I'll need to put my thinking cap on ... I've updated the > > > graphical representation here: > > > > Remind me again which one of these is the "real" engine data, and what > > the source is? The only line on this graph that has the dropoff seems > > to be the polynomial you posted. The others (including the linear > > one) all have better agreement, qualitatively. We can play with other > > forms too, like c((x+1)^e - 1) (for some e < 1, and with a c that makes > > the > > slope through the origin ~ 1). > > > > The real data is series 1, but only up to rpm-normalised = 1. For values > above 1, it's just a continuation by eye of the data. > > (See http://www.turbotechnics.com/supercharger/expo.htm Note that max > power > is at 6500 rpm, and that the supercharger output is nearly flat at 7000 > rpm.) > > I selected > > y = -0.25x^3 + 0.15x^2 + 1.11x > > because that had the best fit between 0 and ~ 1.2, which was the region in > which I was most interested. This was based on the working assumption that > an engine develops rated power at more or less the full supercharger > output. > At the moment, the equation gives a reasonable match to the known > performance. All the other curves are possibilities; that's why they are > there :-). > > I discarded the linear option because of the lack of tail-off, and the > other > polynomial as a poor fit in the operating region. On further > consideration, > perhaps the 'ln' solution doesn't tail off quickly enough, although it's a > very good fit indeed up to ~1.1. > > So far as I can see supercharger design and matching it to an engine is as > much art as science, and there are many different options. I'm reasonably > convinced that the supercharger output should tail off quite sharply after > max power, otherwise an engine would just go on developing more and more > power at higher and higher rpm until it broke or the supercharger did!. In > practice this doesn't happen because the cross section of the inlet is > carefully chosen. > > I'm sure that you can come up with some more alternatives. Let's try them > and see if we like them. > We seem to have got stuck on this one. I haven't pursued it because the Hurricane model wasn't ready. A beta version is now ready. It, along with the Spitfire and P51D need the attached modification to YASim. The diff provides a supercharger output which varies with engine rpm. It assumes that the normalized supercharger output is ~ 1 when the engine is at the nominated peak-power rpm (normalised). A 'power' equation of the form ((A*(B^x))*(x^C) has been derived empirically from some representative supercharger data. This provides near-linear output over the normal operating range, with fall-off in the over-speed situation. It proves an excellent match to published contemporary figures for the Merlin XX in the Hurricane II, and should also do so for other Merlin variants. It allows the engine to over-speed to 2.5 times the nominated peak-power rpm, and will not break beyond this (although the engine/supercharger probably would in real life!). Unlikely, but allows an unexpected YASim configuration. It also provides an additional control - Boost Control Cutout - which overrides the Boost Control (or wastgate in Yasim). The Spitfire, Hurricane and P51D all had this for use in combat. Finally, the diff corrects a minor bug in the output to the property tree and provides a Boost Gauge input. The beta version of the Hurricane IIB is available here: ftp://abbeytheatre.dyndns.org/fgfs/Hurricane/ There is a tarball (hurricane.tgz) or you can grab all the files individually. The diff is also available there. You WILL need to apply this to run the Hurricane, but so far as I can tell, no other YASim model is adversely affected. Some pictures are here: http://myweb.tiscali.co.uk/vmeazza/FlightGear/HurricaneIIb-3.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/HurricaneIIb-4.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/HurricaneIIb-5.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/HurricaneIIb-6.jpg There remains some more eye-candy to do: nav lights, beam approach marker lamps, realistic rad and oil temperature readings etc. In the meantime I would be grateful for any comments, not least that it all downloads and installs correctly! If you do decide to give it a go you'll probably need this: http://home.clara.net/wolverine/BOB/misc/Spit_Hurri_Manuals.zip Regards Vivian yasim.diff Description: Binary data ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] YASim turbo/supercharger issues
> -Original Message- > From: [EMAIL PROTECTED] [mailto:flightgear-devel- > [EMAIL PROTECTED] On Behalf Of Arnt Karlsen > Sent: 23 April 2005 22:02 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] YASim turbo/supercharger issues > > On Sat, 23 Apr 2005 20:02:48 +0100, Vivian wrote in message > <[EMAIL PROTECTED]>: > > > Arnt Karlsen wrote: > > > > > > > > > Andy Ross wrote > > > > > > > > > > > > > > Drew wrote: > > > > > > IMHO, it's best to use interpolation tables rather than > > > > > > equations if you're trying to curve fit empirical data. > > > > > > > > > > Not in this context. The data here isn't being used to model a > > > > > specific engine, but to provide sane parameters for all > > > > > (super/turbochared) engines. The performance and code size > > > > > advantages of an equation here are significant. > > > > > > > > At the moment we are looking at gear driven centrifugal > > > > compressors. Although I haven't researched it in any detail, the > > > > output of turbo-driven centrifugal compressors do not have a > > > > direct relationship with rpm (turbo lag), and the situation is > > > > complicated by the wastegate which operates on the turbo rather > > > > than the compressor. I suspect that this is another black art! > > > > Gear driven is easy in comparison. When someone comes up with a > > > > turbo we may have to have separate models. > > > > > > ..if your supercharger code takes shaft input (shaft speed, torque > > > or power), then it can be re-used in the turbocharger's compressor > > > code. > > > > It doesn't because a gear driven compressor has a fixed relationship > > to engine rpm, and I deal with 2 speed superchargers separately, but > > you are right: a centrifugal compressor neither knows nor cares if it > > is gear- or turbo-driven. > > > > > ..the turbocharger's compressor or turbo-compound engine's > > > crankshaft then only needs a turbine derivering shaft outnput (shaft > > > speed, torque or power) to the compressor or gear box. > > > > > > > Now, if we knew what the turbo rpm was for a given engine rpm, > > .._not_ gonna happen. Turbo rpm will always, always, always be a > function of the exhaust gas pressures piped in and out, and, the > turbines own shaft loads, temperature, mass, and time. > > ..just think of any water wheel, or power turbine, to do the power > turbine code part of the turbo. Then you can saw the gear box off the > supercharger shaft and weld that stub onto the power turbine to make > a turbocharger. ;o) > > > and I think we need throttle opening ... any guidance welcome. > > ..just like in the supercharger code. Now, keep in mind, the power > turbine _only_ sees exhaust gas pressures and temperatures piped > in and out and its own mass and inertia, time and the shaft and > bearing and lube film loads. > > ..the compressor on the _other_ end of that turbo shaft, will see the > _same_ as the supercharger, except for the power turbine replacing > the gear box. > > ..exhaust gas pressures and temperatures vary, think pulses, spikes, > waste gates and even exhaust throttles, if you wanna model a new > fancy way of blowing up a model engine in that spectacular way > I read about in some model magazine some 20 years back. ;o) Or TFD - I'll think about it later (much later :-). Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
On Sat, 23 Apr 2005 20:02:48 +0100, Vivian wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen wrote: > > > > > > Andy Ross wrote > > > > > > > > > > > Drew wrote: > > > > > IMHO, it's best to use interpolation tables rather than > > > > > equations if you're trying to curve fit empirical data. > > > > > > > > Not in this context. The data here isn't being used to model a > > > > specific engine, but to provide sane parameters for all > > > > (super/turbochared) engines. The performance and code size > > > > advantages of an equation here are significant. > > > > > > At the moment we are looking at gear driven centrifugal > > > compressors. Although I haven't researched it in any detail, the > > > output of turbo-driven centrifugal compressors do not have a > > > direct relationship with rpm (turbo lag), and the situation is > > > complicated by the wastegate which operates on the turbo rather > > > than the compressor. I suspect that this is another black art! > > > Gear driven is easy in comparison. When someone comes up with a > > > turbo we may have to have separate models. > > > > ..if your supercharger code takes shaft input (shaft speed, torque > > or power), then it can be re-used in the turbocharger's compressor > > code. > > It doesn't because a gear driven compressor has a fixed relationship > to engine rpm, and I deal with 2 speed superchargers separately, but > you are right: a centrifugal compressor neither knows nor cares if it > is gear- or turbo-driven. > > > ..the turbocharger's compressor or turbo-compound engine's > > crankshaft then only needs a turbine derivering shaft outnput (shaft > > speed, torque or power) to the compressor or gear box. > > > > Now, if we knew what the turbo rpm was for a given engine rpm, .._not_ gonna happen. Turbo rpm will always, always, always be a function of the exhaust gas pressures piped in and out, and, the turbines own shaft loads, temperature, mass, and time. ..just think of any water wheel, or power turbine, to do the power turbine code part of the turbo. Then you can saw the gear box off the supercharger shaft and weld that stub onto the power turbine to make a turbocharger. ;o) > and I think we need throttle opening ... any guidance welcome. ..just like in the supercharger code. Now, keep in mind, the power turbine _only_ sees exhaust gas pressures and temperatures piped in and out and its own mass and inertia, time and the shaft and bearing and lube film loads. ..the compressor on the _other_ end of that turbo shaft, will see the _same_ as the supercharger, except for the power turbine replacing the gear box. ..exhaust gas pressures and temperatures vary, think pulses, spikes, waste gates and even exhaust throttles, if you wanna model a new fancy way of blowing up a model engine in that spectacular way I read about in some model magazine some 20 years back. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] YASim turbo/supercharger issues
Arnt Karlsen wrote: > > > Andy Ross wrote > > > > > > > > Drew wrote: > > > > IMHO, it's best to use interpolation tables rather than equations > > > > if you're trying to curve fit empirical data. > > > > > > Not in this context. The data here isn't being used to model a > > > specific engine, but to provide sane parameters for all > > > (super/turbochared) engines. The performance and code size > > > advantages of an equation here are significant. > > > > > > > At the moment we are looking at gear driven centrifugal compressors. > > Although I haven't researched it in any detail, the output of > > turbo-driven centrifugal compressors do not have a direct relationship > > with rpm (turbo lag), and the situation is complicated by the > > wastegate which operates on the turbo rather than the compressor. I > > suspect that this is another black art! Gear driven is easy in > > comparison. When someone comes up with a turbo we may have to have > > separate models. > > ..if your supercharger code takes shaft input (shaft speed, torque or > power), then it can be re-used in the turbocharger's compressor code. It doesn't because a gear driven compressor has a fixed relationship to engine rpm, and I deal with 2 speed superchargers separately, but you are right: a centrifugal compressor neither knows nor cares if it is gear- or turbo-driven. > ..the turbocharger's compressor or turbo-compound engine's crankshaft > then only needs a turbine derivering shaft outnput (shaft speed, torque > or power) to the compressor or gear box. > Now, if we knew what the turbo rpm was for a given engine rpm, and I think we need throttle opening ... any guidance welcome. Otherwise ... it's going to have to be magic mushrooms. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
On Sat, 23 Apr 2005 10:15:31 +0100, Vivian wrote in message <[EMAIL PROTECTED]>: > Andy Ross wrote > > > > > Drew wrote: > > > IMHO, it's best to use interpolation tables rather than equations > > > if you're trying to curve fit empirical data. > > > > Not in this context. The data here isn't being used to model a > > specific engine, but to provide sane parameters for all > > (super/turbochared) engines. The performance and code size > > advantages of an equation here are significant. > > > > At the moment we are looking at gear driven centrifugal compressors. > Although I haven't researched it in any detail, the output of > turbo-driven centrifugal compressors do not have a direct relationship > with rpm (turbo lag), and the situation is complicated by the > wastegate which operates on the turbo rather than the compressor. I > suspect that this is another black art! Gear driven is easy in > comparison. When someone comes up with a turbo we may have to have > separate models. ..if your supercharger code takes shaft input (shaft speed, torque or power), then it can be re-used in the turbocharger's compressor code. ..the turbocharger's compressor or turbo-compound engine's crankshaft then only needs a turbine derivering shaft outnput (shaft speed, torque or power) to the compressor or gear box. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] YASim turbo/supercharger issues
Andy Ross wrote > > Drew wrote: > > IMHO, it's best to use interpolation tables rather than equations if > > you're trying to curve fit empirical data. > > Not in this context. The data here isn't being used to model a > specific engine, but to provide sane parameters for all > (super/turbochared) engines. The performance and code size advantages > of an equation here are significant. > At the moment we are looking at gear driven centrifugal compressors. Although I haven't researched it in any detail, the output of turbo-driven centrifugal compressors do not have a direct relationship with rpm (turbo lag), and the situation is complicated by the wastegate which operates on the turbo rather than the compressor. I suspect that this is another black art! Gear driven is easy in comparison. When someone comes up with a turbo we may have to have separate models. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] YASim turbo/supercharger issues
> It's nice to be able to have backout routines for interpolation > tables, as well, which can be extremely helpful in initialization > code. For tables up to 3d with fixed independent indices (is this > what you meant by 'grid', or did you mean fixed intervals?), this is > pretty straightforward. Creating backout utilities for larger > dimensions and varying indices can be difficult. By gridded I mean that the table is uniform. For instance, for 3D tables there are say, ten rows and four columns, and the row breakpoints are the same for each column, and vice versa. And, the row and column breakpoints are the same for each of the third axis breakpoints, too. You can have tables where each row of independent data may have different column breakpoints, and the row and column breakpoints (defining a 2D table) could be different for each additional 2D table. Available data doesn't necessarily fall into neat buckets. > Also, if you've got more than 3 inputs to a lookup table, you've > probably not done enough data reduction, and you're asking for > headaches when tuning the model. Usually, you can uncouple the > dependencies enough to avoid such a mess, using multiple, smaller > tables > > Drew A 3D table is nothing. Some sims I am aware of use 6 dimensional tables or more. The trick is to use recursion where possible. I've been toying with the idea where each dependent "data" point in a 2D table is itself another table. That would make the problem manageable. Yet, the toughest part of that may well be data entry and formatting - unless one has - as we (JSBSim) do: a tool (DATCOM+) that writes your aerodynamic tables for you. :-) Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] YASim turbo/supercharger issues
> Probably several. YASim has one for doing interpolation of standard > atmosphere parameters, and I'm sure there's a similar engine in the > JSBSim code, which depends on tables extensively in its configuration. Yeah, that's something that could be a project in itself. There are a few ways to do tables that I know of. JSBSim does "gridded" tables up to three independent variables. I'd like to extend that to ungridded tables of "n" dimensions. Maybe there's an algorithm around somewhere for that. I know where to look for at least one. Specifying the table data can be sort of confusing in a configuration file, but I have a way around that, I think. I just need some time. Something that there's always too little of. Like right now ... I'm being paged to come and make dinner. :-( Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
> Yeah, that's something that could be a project in itself. There are a few > ways to do > tables that I know of. JSBSim does "gridded" tables up to three independent > variables. I'd > like to extend that to ungridded tables of "n" dimensions. Maybe there's an > algorithm > around somewhere for that. I know where to look for at least one. It's nice to be able to have backout routines for interpolation tables, as well, which can be extremely helpful in initialization code. For tables up to 3d with fixed independent indices (is this what you meant by 'grid', or did you mean fixed intervals?), this is pretty straightforward. Creating backout utilities for larger dimensions and varying indices can be difficult. Also, if you've got more than 3 inputs to a lookup table, you've probably not done enough data reduction, and you're asking for headaches when tuning the model. Usually, you can uncouple the dependencies enough to avoid such a mess, using multiple, smaller tables Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
> The real data is series 1, but only up to rpm-normalised = 1. For values > above 1, it's just a continuation by eye of the data. > > (See http://www.turbotechnics.com/supercharger/expo.htm Note that max power > is at 6500 rpm, and that the supercharger output is nearly flat at 7000 > rpm.) > > I selected > > y = -0.25x^3 + 0.15x^2 + 1.11x > > because that had the best fit between 0 and ~ 1.2, which was the region in > which I was most interested. This was based on the working assumption that > an engine develops rated power at more or less the full supercharger output. > At the moment, the equation gives a reasonable match to the known > performance. All the other curves are possibilities; that's why they are > there :-). > > I discarded the linear option because of the lack of tail-off, and the other > polynomial as a poor fit in the operating region. On further consideration, > perhaps the 'ln' solution doesn't tail off quickly enough, although it's a > very good fit indeed up to ~1.1. > > So far as I can see supercharger design and matching it to an engine is as > much art as science, and there are many different options. I'm reasonably > convinced that the supercharger output should tail off quite sharply after > max power, otherwise an engine would just go on developing more and more > power at higher and higher rpm until it broke or the supercharger did!. In > practice this doesn't happen because the cross section of the inlet is > carefully chosen. > > I'm sure that you can come up with some more alternatives. Let's try them > and see if we like them. > > Regards, > > Vivian IMHO, it's best to use interpolation tables rather than equations if you're trying to curve fit empirical data. Equations are great for modeling physical principles (e.g. F=ma), but for something like this, if you use a table, you can adjust the values to your heart's content without having to worry about how one adjustment affects other entries, or how it behaves outside the domain of interest. Does FlightGear have a format and utilities for table lookups? Perhaps it's worth developing some if they don't already exist (I'd be willing to contribute). Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] YASim turbo/supercharger issues
Andy Ross wrote: > -Original Message- > From: [EMAIL PROTECTED] [mailto:flightgear-devel- > [EMAIL PROTECTED] On Behalf Of > Sent: 22 April 2005 15:19 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] YASim turbo/supercharger issues > > Vivian Meazza wrote: > > y = -0.25x3 + 0.15x2 + 1.11x > > > > Thinking about the over-speed situation overnight, the Merlin was > > allowed to go to 3600 rpm for brief periods, and even then damage to > > the engine was possible. This is a normalised value of 1.2. The K > > Series will go to 9000 (don't try this on yours - it requires special > > valve lifters and crankshaft) or 1.28 normalised. The curve shown > > here: > > Yes, but remember that the "normalization" RPM isn't guaranteed to be > a maximum speed. It might be for your merlin configuration, but I can > guarantee you (seriously: 100% certainty) that if we include a model > that goes wacky in some regime, someone will come up with a > configuration to tickle the bug. This has happened again and again, > often with your aircraft. :) That's right, blame me for finding some bugs/features :-), but OK, good point. > How about this one instead: > >ln(rpm_norm - 1) * (1 / ln(2)) > > It seems to qualitatively match the curve you posted (is there a > primary source for that curve?) without the nasty dropoff. Nope. I did a best fit to good data up to max power, and that was the outcome. However, it seemed to me to encapsulate the idea of compressor stall. > You can > see how it works, it just translates/scales a logarithm curve to pass > through the origin and (1,1). That got me going. Are you trying to calculate the natural log of a negative number (rpm_norm - 1)? Isn't that a complex number? Did you mean: ln(rpm_norm + 1) * (1 / ln(2)) ^^^ And we can't do 0 rpm can we? If you do mean this equation then I can certainly live with that. If not, I'll need to put my thinking cap on ... I've updated the graphical representation here: http://myweb.tiscali.co.uk/vmeazza/FlightGear/supercharge.pdf Let's go with that for now. Meanwhile, I've just done the boost control cutout. Trivial, I'll let you have the diff once you've done this one. Thanks again Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
Drew wrote: > IMHO, it's best to use interpolation tables rather than equations if > you're trying to curve fit empirical data. Not in this context. The data here isn't being used to model a specific engine, but to provide sane parameters for all (super/turbochared) engines. The performance and code size advantages of an equation here are significant. > Does FlightGear have a format and utilities for table lookups? > Perhaps it's worth developing some if they don't already exist (I'd > be willing to contribute). Probably several. YASim has one for doing interpolation of standard atmosphere parameters, and I'm sure there's a similar engine in the JSBSim code, which depends on tables extensively in its configuration. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] YASim turbo/supercharger issues
Andy Ross: > > If you do mean this equation then I can certainly live with that. If > > not, I'll need to put my thinking cap on ... I've updated the > > graphical representation here: > > Remind me again which one of these is the "real" engine data, and what > the source is? The only line on this graph that has the dropoff seems > to be the polynomial you posted. The others (including the linear > one) all have better agreement, qualitatively. We can play with other > forms too, like c((x+1)^e - 1) (for some e < 1, and with a c that makes > the > slope through the origin ~ 1). > The real data is series 1, but only up to rpm-normalised = 1. For values above 1, it's just a continuation by eye of the data. (See http://www.turbotechnics.com/supercharger/expo.htm Note that max power is at 6500 rpm, and that the supercharger output is nearly flat at 7000 rpm.) I selected y = -0.25x^3 + 0.15x^2 + 1.11x because that had the best fit between 0 and ~ 1.2, which was the region in which I was most interested. This was based on the working assumption that an engine develops rated power at more or less the full supercharger output. At the moment, the equation gives a reasonable match to the known performance. All the other curves are possibilities; that's why they are there :-). I discarded the linear option because of the lack of tail-off, and the other polynomial as a poor fit in the operating region. On further consideration, perhaps the 'ln' solution doesn't tail off quickly enough, although it's a very good fit indeed up to ~1.1. So far as I can see supercharger design and matching it to an engine is as much art as science, and there are many different options. I'm reasonably convinced that the supercharger output should tail off quite sharply after max power, otherwise an engine would just go on developing more and more power at higher and higher rpm until it broke or the supercharger did!. In practice this doesn't happen because the cross section of the inlet is carefully chosen. I'm sure that you can come up with some more alternatives. Let's try them and see if we like them. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
Vivian Meazza wrote: > That got me going. Are you trying to calculate the natural log of a > negative number (rpm_norm - 1)? Isn't that a complex number? Did you > mean: Yes, typo. Sorry. > If you do mean this equation then I can certainly live with that. If > not, I'll need to put my thinking cap on ... I've updated the > graphical representation here: Remind me again which one of these is the "real" engine data, and what the source is? The only line on this graph that has the dropoff seems to be the polynomial you posted. The others (including the linear one) all have better agreement, qualitatively. We can play with other forms too, like c((x+1)^e - 1) (for some e < 1, and with a c that makes the slope through the origin ~ 1). Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
Vivian Meazza wrote: > y = -0.25x3 + 0.15x2 + 1.11x > > Thinking about the over-speed situation overnight, the Merlin was > allowed to go to 3600 rpm for brief periods, and even then damage to > the engine was possible. This is a normalised value of 1.2. The K > Series will go to 9000 (don't try this on yours - it requires special > valve lifters and crankshaft) or 1.28 normalised. The curve shown > here: Yes, but remember that the "normalization" RPM isn't guaranteed to be a maximum speed. It might be for your merlin configuration, but I can guarantee you (seriously: 100% certainty) that if we include a model that goes wacky in some regime, someone will come up with a configuration to tickle the bug. This has happened again and again, often with your aircraft. :) How about this one instead: ln(rpm_norm - 1) * (1 / ln(2)) It seems to qualitatively match the curve you posted (is there a primary source for that curve?) without the nasty dropoff. You can see how it works, it just translates/scales a logarithm curve to pass through the origin and (1,1). Let me know. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] YASim turbo/supercharger issues
Andy Ross wrote: > Vivian Meazza wrote: > > I used the power form because it is easier to read, but if the other > > form produces a performance advantage, then of course we must use > > it. > > It's actually not so much about performance, really. Readability can > mean different things. The problem is that when I see a trancendental > function in code, I immediately start thinking that it much be some > complicated formula typed in from a book, as these things don't occur > in typical programmer's brains all that often. Basically, even though > in isolation it's easier to read "pow(foo, 3)" than "foo*foo*foo", > when you look at the whole expression, your original one is > "complicated" to me: > > (-0.25 * math::pow(rpm_norm,3)) + (-0.15 * math::pow(rpm_norm,2)) >+ (1.11 * rpm_norm); > > Whereas this one is just really obviously a polynomial, and I > understand polynomials, they're simple and not scary at all: > >rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25)) > > I'll work up a version of the new one with the sign bug fixed, and try > to get that checked in tonight. > Personally, I do find nested forms of programming scary, too easy to make mistakes. To reiterate, the correct equation is: y = -0.25x^3 + 0.15x^2 + 1.11x or y = ((-0.25x + 0.15)x + 1.11)x Thinking about the over-speed situation overnight, the Merlin was allowed to go to 3600 rpm for brief periods, and even then damage to the engine was possible. This is a normalised value of 1.2. The K Series will go to 9000 (don't try this on yours - it requires special valve lifters and crankshaft) or 1.28 normalised. The curve shown here: http://myweb.tiscali.co.uk/vmeazza/FlightGear/supercharge.pdf fits those numbers very nicely. I think we're there now with a nice model for a geared supercharger. I'm less happy with the rather crude model of the throttle, and will do some more work in due course. Thanks to everyone who has contributed to the maths and programming issues Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
On Friday 22 April 2005 01:46, Norman Vine wrote: > Andy Ross writes: > > Vivian Meazza wrote: > > > I used the power form because it is easier to read, but if the other > > > form produces a performance advantage, then of course we must use > > > it. > > > > It's actually not so much about performance, really. Readability can > > mean different things. The problem is that when I see a trancendental > > function in code, I immediately start thinking that it much be some > > complicated formula typed in from a book, as these things don't occur > > in typical programmer's brains all that often. Basically, even though > > in isolation it's easier to read "pow(foo, 3)" than "foo*foo*foo", > > when you look at the whole expression, your original one is > > "complicated" to me: > > > > (-0.25 * math::pow(rpm_norm,3)) + (-0.15 * math::pow(rpm_norm,2)) > >+ (1.11 * rpm_norm); > > > > Whereas this one is just really obviously a polynomial, and I > > understand polynomials, they're simple and not scary at all: > > > >rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25)) > > > > I'll work up a version of the new one with the sign bug fixed, and try > > to get that checked in tonight. > > Hmmm. > > I find it all to easy to make silly mistakes with nested parentheticals > and usually avoid them unless absolutely needed The silly mistake was that 0.15 and 0.25 got swapped. This is what it should have read: rpm_norm * (1.11 - rpm_norm * (0.25 * rpm_norm + 0.15)) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
Selon Andy Ross <[EMAIL PROTECTED]>: > > (-0.25 * math::pow(rpm_norm,3)) + (-0.15 * math::pow(rpm_norm,2)) >+ (1.11 * rpm_norm); > > Whereas this one is just really obviously a polynomial, and I > understand polynomials, they're simple and not scary at all: > >rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25)) > or is it : rpm_norm * (1.11 - rpm_norm * (0.15 + rpm_norm * 0.25)) ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
On Thu, 21 Apr 2005 19:46:10 -0400, Norman wrote in message <[EMAIL PROTECTED]>: > Andy Ross writes: > > Whereas this one is just really obviously a polynomial, and I > > understand polynomials, they're simple and not scary at all: > > > >rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25)) > > > > I'll work up a version of the new one with the sign bug fixed, and > > try to get that checked in tonight. > > Hmmm. > > I find it all to easy to make silly mistakes with nested > parentheticals and usually avoid them unless absolutely needed ..guys, 'apt-get install mathomatic', then try the above equation in it: Each equation must have one, and only one, equals sign (=). Absolute value notation (|x|) and "+/-" are understood. 1-> rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25)) = 0 111 3*rpm_norm 1 #1: rpm_norm*(--- - (rpm_norm*(-- + -))) = 0 100 20 4 1-> ..above is mathomatic output, it can do more fun: http://packages.qa.debian.org/m/mathomatic.html -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] YASim turbo/supercharger issues
Andy Ross writes: > > Vivian Meazza wrote: > > I used the power form because it is easier to read, but if the other > > form produces a performance advantage, then of course we must use > > it. > > It's actually not so much about performance, really. Readability can > mean different things. The problem is that when I see a trancendental > function in code, I immediately start thinking that it much be some > complicated formula typed in from a book, as these things don't occur > in typical programmer's brains all that often. Basically, even though > in isolation it's easier to read "pow(foo, 3)" than "foo*foo*foo", > when you look at the whole expression, your original one is > "complicated" to me: > > (-0.25 * math::pow(rpm_norm,3)) + (-0.15 * math::pow(rpm_norm,2)) >+ (1.11 * rpm_norm); > > Whereas this one is just really obviously a polynomial, and I > understand polynomials, they're simple and not scary at all: > >rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25)) > > I'll work up a version of the new one with the sign bug fixed, and try > to get that checked in tonight. Hmmm. I find it all to easy to make silly mistakes with nested parentheticals and usually avoid them unless absolutely needed Python 2.4 (#1, Dec 4 2004, 20:10:33) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> rpm_norm = 100 >>> a = (-0.25 * math.pow(rpm_norm,3)) + (-0.15 * math.pow(rpm_norm,2)) + (1.11 >>> * rpm_norm) >>> b = rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25)) >>> a == b False >>> a -251389.0 >>> b -152389.0 >>> rpm_norm_2 = rpm_norm*rpm_norm >>> rpm_norm_3 = rpm_norm * rpm_norm_2 >>> c = (-0.25*rpm_norm_3) + (-0.15*rpm_norm_2) + (1.11*rpm_norm) >>> a == c True >>> ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
Vivian Meazza wrote: > I used the power form because it is easier to read, but if the other > form produces a performance advantage, then of course we must use > it. It's actually not so much about performance, really. Readability can mean different things. The problem is that when I see a trancendental function in code, I immediately start thinking that it much be some complicated formula typed in from a book, as these things don't occur in typical programmer's brains all that often. Basically, even though in isolation it's easier to read "pow(foo, 3)" than "foo*foo*foo", when you look at the whole expression, your original one is "complicated" to me: (-0.25 * math::pow(rpm_norm,3)) + (-0.15 * math::pow(rpm_norm,2)) + (1.11 * rpm_norm); Whereas this one is just really obviously a polynomial, and I understand polynomials, they're simple and not scary at all: rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25)) I'll work up a version of the new one with the sign bug fixed, and try to get that checked in tonight. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] YASim turbo/supercharger issues
Andy Ross wrote: > Vivian Meazza wrote: > > The attached diff models the output of a gear-driven > > supercharger > > I just now got a chance to sit down and puzzle this out. I see where > it's going: instead of ignoring the RPM contribution to boost, it adds > an extra factor that reduces the boost at lower RPMs. It works by > normalizing the "rpm" value to the range [0:1] (expressing it as a > fraction of the engine's solution RPM) and then applies this as an > extra factor on top of the turbo-mul value from the configuration > file: > -0.25*rpm^3 - 0.15*rpm^2 + 1.11*rpm Right - this approach seemed to me to be consistent with the existing code. > Now, one mild criticism of the code here is the use of the pow() > function to compute integer powers. Just in case you don't know the > trick, you can express that equation in a C expression as something > like: > >rpm * (1.11 - rpm * (0.15 * rpm + 0.25)) > > But that's more or less irrelevant. I used the power form because it is easier to read, but if the other form produces a performance advantage, then of course we must use it. > My real confusion is that while > this function reaches its maximum at a normalized RPM of slightly more > than 1.0 (sounds about right), it maximum value is only about 0.7 or > so. This will have the effect of reducing turbo-mul by about 30% from > pre-existing aircraft configurations. Is that the intent? Or should > the function be re-scaled to equal 1.0 at maximum boost? I've made a typing error here. The equation should be: -0.25*rpm^3 + 0.15*rpm^2 + 1.11*rpm This does have a max value of 1.01 at the normalised rpm value of 1. Now I'm concerned that it all worked so well before. I'm going to have to test all over again. > The other issue is that this function drops off really fast in > overspeed situations. I'd intuitively expect some drop-off in MP at > high RPMs (compressor stall) before reaching a constant asymptote, but > this thing plunges like a rock, crossing zero (negative MP?) at about > 1.8. Remember that the normalization RPM isn't always guaranteed to be > the maximum engine speed, so this regime might actually be close to > what you can do in the cockpit in a fast dive, for example. I think that this is a very valid point, and I agree. I have no good evidence for how the curve should drop, except that at some point the compressor goes supersonic, and surges. I have an alternative curve which is more asymptotic in shape, but doesn't fit quite so well at low rpm. Problem is that the controller holds the rpm rock solid at 3000 rpm, whatever I do. Interestingly, this was also claimed for the controller in real life. Here's what I'm trying to do http://myweb.tiscali.co.uk/vmeazza/FlightGear/supercharge.pdf Hang on, I'll have to find out why it all worked so well with an error. It will take me till after the weekend to retest it all. I'll test the second curve as well and try to reach a conclusion as to which is better. Thanks for all this, I'll get back to you soonest Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
