RE: [Flightgear-devel] New turbo/supercharger code
Andy Ross Vivian Meazza wrote: control-input axis=/controls/engines/engine[0]/boost-control Here is the setting in the property browser Controls/engines/engine/boost-control= 1.0 Case bug or just a typo? Oh, were it that easy! Unfortunately, neither - my mail client did that - it's right in the code. I've checked n times. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
Andy Ross wrote
Vivian Meazza wrote:
I would deduce that the property:
Controls/engines/engine/boost-control
Does not exist when the solver runs.
It should still see a zero for undefined properties,
What does it do for defined properties that contain null/nil?
although you can
make arbitrary property settings in the approach/cruise definitions up
at the top. Some of the aircraft
???
Note again, though, that you appear to have a case bug. The property
tree name is controls, not Controls.
There is no case error, sorry to have mislead you here.
I would back out your changes to the last version that works and
re-add them one at a time. The change to the property input for the
throttle control will not cause a change in solution results.
Something else must have been modified.
No - nothing else has been modified. I've gone back to the cvs-head version
of source and data. This is the _only_ change in the code anywhere:
!--control-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/--
control-input
axis=/controls/engines/engine[0]/boost-control control=THROTTLE/
this is the solver output in fgfs:
YASim solution results:
Iterations: 1
Drag Coefficient: 1000
Lift Ratio: 1
Cruise AoA: 0
Tail Incidence: -0
Approach Elevator: 0
CG: -3.412, 0.000, -0.201
Same thing using yasim.exe. You can check for yourself very quickly and
easily.
My hypothesis remains that the value of
/controls/engines/engine[0]/boost-control
is null/nil at solve time. Since this property hasn't been initialized with
this as the only change this ought to be the case??? If I do initialize the
property using nasal, then the outcome is the same, therefore I deduce that
the property remains null/nil despite apparent initialization until after
solve-time. I have had to add this to some nasal to work around this
elsewhere:
if (mp == nil){mp = 0};
But not in this test - the only change to cvs-head is as above.
Vivian
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Arnt Karlsen wrote: Andy Ross wrote: Yeah, but that's a bug. There is only one manifold pressure. Surely you don't want *both* mp-inhg and supercharger-output-inhg, which mean exactly the same thing. ..I beg to differ; flow always means there are flow losses. The discussion was about software, not engines. If you really want to nit, we should be modelling the MP as a 3D scalar field, so that the user can decide where to put the probe. :) The point was that there is no need for a new property to represent the value displayed by the manifold pressure gauge. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Vivian Meazza wrote: What does it do for defined properties that contain null/nil? It doesn't. The solver doesn't actually try to read properties during solution (which would be madness -- you would get different solution results by changing values that aren't in the aircraft definition file). At solution time, the solver assumes that any undefined properties are zero, and applies any of the values it finds in the control tags. although you can make arbitrary property settings in the approach/cruise definitions up at the top. Some of the aircraft ??? Sorry, didn't finish the sentence. Some of the aircraft use this to set a non-zero trim for the cruise solution. No - nothing else has been modified. I've gone back to the cvs-head version of source and data. This is the _only_ change in the code anywhere: !--control-input axis=/controls/engines/engine[0]/throttle control=THROTTLE/-- control-input axis=/controls/engines/engine[0]/boost-control control=THROTTLE/ Bingo. That's the bug. You commented out the throttle! How is the engine supposed to produce thrust when the throttle input is zero? :) You need *both* the inputs for them to be added together. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
Andy Ross
No - nothing else has been modified. I've gone back to the cvs-head
version
of source and data. This is the _only_ change in the code anywhere:
!--control-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/--
control-input axis=/controls/engines/engine[0]/boost-control
control=THROTTLE/
Bingo.
Not. At least, only in the sense of RTB. This is where we came in. It might
not produce any thrust, but it should solve shouldn't it?
That's the bug. You commented out the throttle!
How is the
engine supposed to produce thrust when the throttle input is zero? :)
You need *both* the inputs for them to be added together.
Yes. I wish!
Next trial:
Config file:
control-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/
control-input
axis=/controls/engines/engine[0]/boost-control control=THROTTLE/
Output:
YASim solution results:
Iterations: 1
Drag Coefficient: 1000
Lift Ratio: 1
Cruise AoA: 0
Tail Incidence: -0
Approach Elevator: 0
CG: -3.412, 0.000, -0.201
Do you suppose that whatever is or isn't in
/controls/engines/engine[0]/boost-control
Is breaking YASim?
And I've tried initializing /controls/engines/engine[0]/boost-control in
hardcode, and in Nasal, and in .XML - no difference. I can only think that
initialization creates the property with a null value, and then only gives
it the correct value after YASim has tried to use it and failed. I can show
that this is the case with NASAL, otherwise I wouldn't need this:
if (mp == nil){mp = 0};
Any better theory?
Vivian
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
-Original Message- From: [EMAIL PROTECTED] [mailto:flightgear-devel- [EMAIL PROTECTED] On Behalf Of Andy Ross Sent: 19 June 2005 18:34 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] New turbo/supercharger code Vivian Meazza wrote: Not. At least, only in the sense of RTB. This is where we came in. It might not produce any thrust, but it should solve shouldn't it? Er, huh? I guess I don't understand how you think that would work. What the solver does is figure out how much drag the airframe needs to produce in order to meet the specified performance numbers. If there is no thrust, then the only drag that works is zero and you get a failure. I honestly thought everyone was clear on this point. This is going in circles. Start with your working file. Add *only* the line specifying the new boost control axis. Touch nothing else. Don't come back until you make it work. I assure you that you will get the same solution after you add the axis. Once it is there, you can start playing with it at runtime. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Erik Hofman wrote: No we shouldn't. In aviation there are not many places where SI units are used so we stick with what is used by default. If you don't like it use Nasal to correct it yourself. In the _long_ run it might make _much_ sense to use SI units _internally_ and let every designer adapt their gauge/whatever to the units they like most. To my impression SI units are being used in aviation at many places - just not for the user interface. In fact depending on several 'fuzzy' factors you might see almost identical aircraft from the same production line with different units on their gauges, one with numbers basing on statue miles, the other with numbers basing on nautical miles. And, just as a note, all European countries _I_ know of use a QNH in hectopascal to adjust their altimeter May, am I happy that they all use 360 degrees for a full circle :-) The only solution for not getting confused by this is the use of SI _internally_ and to offer a set of conversion routines to everyone - probably by exposing different 'attributes' of the same property (or any other method that fills ther gap). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
On Sun, 19 Jun 2005 09:08:05 -0700, Andy wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: Andy Ross wrote: Yeah, but that's a bug. There is only one manifold pressure. Surely you don't want *both* mp-inhg and supercharger-output-inhg, which mean exactly the same thing. ..I beg to differ; flow always means there are flow losses. The discussion was about software, not engines. If you really want to nit, we should be modelling the MP as a 3D scalar field, so that the user can decide where to put the probe. :) ..aye. ;o) The point was that there is no need for a new property to represent the value displayed by the manifold pressure gauge. ..agreed, and my point was just keep open space for code modelling those losses, until it is written. -- ..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] New turbo/supercharger code
Oliver C. wrote: We should really try to use only SI-units everywhere in the base code. If this is not the case, we should start to correct that. No we shouldn't. In aviation there are not many places where SI units are used so we stick with what is used by default. If you don't like it use Nasal to correct it yourself. It might sound bad (I'm from Europe too) but it's really the only way to go. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
Andy Ross wrote: Vivian Meazza wrote: Engines/engine/boost-pressure-psi-gauge = 46.00167 (correct order of boost) Can you try it with the CVS code? This may be interacting badly with your local changes, which makes debugging difficult. Nothing in this mechanism should require any of the new code. I've already done that, but didn't take exact readings; the outcome looks the same, I think. I'll do it again. The new/old code should have no impact on this. Also on this subject: I started integrating the RPM-based supercharger attenuation, and noticed that your code added three new engine properties: mp-pascals: Is this needed? The standard so far for manifold pressure has always been inHg. Having lots of duplicate units around complicates things; we can always do conversions in the panel animations or Nasal code. I don't use it: I only include it because I thought we ought to have SI units. boost-pressure-psi-gauge: This looks to have been hardcoded to sea level; it should be using ambient, no? Also, must the units be PSI, or can I change them to inhg? The final name would then be boost-gauge-inhg (units go last, and pressure is implicit in the units). OK with the name. PSI(gauge) is what we use over here, otherwise it's inhg absolute for the US. Gauge-inhg makes no sense. In real life there's no difference between the way the US and UK measure the pressure, it's the zero on the gauge which is different, so I think it's correct the way it is. Gives the right gauge readings anyway. boost-pressure-inhg: Reading the code, this looks like an absolute manifold pressure, and not a boost at all. Is this a mistake, it looks like a synonym for mp-inhg to me. I named it that way to distinguish it from mp-inhg, which in the current code reports supercharger output before the 'wastegate' is applied. The existing mp-inhg should be retired or renamed to supercharger-output-inhg to reflect what it reports (useful for testing). Then boost-pressure-inhg can be renamed accordingly. The important thing is for the pressure, in whatever units you want (apart from gauge-inhg), is reported _after_ the 'wastegate' etc. have been applied to the supercharger output. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
Andy Ross
Vivian Meazza wrote:
Engines/engine/boost-pressure-psi-gauge = 46.00167 (correct order of
boost)
Can you try it with the CVS code? This may be interacting badly with
your local changes, which makes debugging difficult. Nothing in this
mechanism should require any of the new code.
Here's the result of the short experiment conducted using a clean download
of the YASim directory from this morning cvs-HEAD:
This is the entry in the config file
control-input axis=/controls/engines/engine[0]/boost-control
control=THROTTLE/
Here is the setting in the property browser
Controls/engines/engine/boost-control= 1.0
Here is the output in the property browser
Engines/engine/mp-inhg = 145.518585
Engines/engine/prop-thrust = 4230.001953
Velocities/airspeed-kt = 45.839
Same outcome. I guess that something somewhere isn't reading the input axis.
I haven't found it yet, but in passing (and only peripherally related to
this problem) I found this in thrusters.cpp
void Thruster::setThrottle(float throttle)
{
_throttle = Math::clamp(throttle, 0, 1);
}
Will this prevent a negative value for:
control-input axis=/controls/engines/engine[0]/boost-control
control=THROTTLE/
when we get it to work?
V.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
I wrote:
I found this in thrusters.cpp
void Thruster::setThrottle(float throttle)
{
_throttle = Math::clamp(throttle, 0, 1);
}
Will this prevent a negative value for:
control-input axis=/controls/engines/engine[0]/boost-control
control=THROTTLE/
when we get it to work?
Another potential pooh trap?
// Returns the input/output range appropriate for the given
// control. Ailerons go from -1 to 1, while throttles are never
// lower than zero, etc...
static float rangeMin(int type);
static float rangeMax(int type);
V.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
I wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:flightgear-devel- [EMAIL PROTECTED] On Behalf Of Vivian Meazza Sent: 18 June 2005 11:23 To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] New turbo/supercharger code Andy Ross Vivian Meazza wrote: Engines/engine/boost-pressure-psi-gauge = 46.00167 (correct order of boost) Can you try it with the CVS code? This may be interacting badly with your local changes, which makes debugging difficult. Nothing in this mechanism should require any of the new code. Here's the result of the short experiment conducted using a clean download of the YASim directory from this morning cvs-HEAD: This is the entry in the config file control-input axis=/controls/engines/engine[0]/boost-control control=THROTTLE/ Here is the setting in the property browser Controls/engines/engine/boost-control= 1.0 Here is the output in the property browser Engines/engine/mp-inhg = 145.518585 Engines/engine/prop-thrust = 4230.001953 Velocities/airspeed-kt = 45.839 Same outcome. I guess that something somewhere isn't reading the input axis. Ok - problem solved, or rather, cause identified. The solver is failing silently. This is the output: YASim solution results: Iterations: 1 Drag Coefficient: 1000 Lift Ratio: 1 Cruise AoA: 0 Tail Incidence: -0 Approach Elevator: 0 CG: -3.412, 0.000, -0.201 I would deduce that the property: Controls/engines/engine/boost-control Does not exist when the solver runs. So now to try to get around that one. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Oliver C. wrote: In this case inch Hg is wrong, because it is not an SI-unit. Pascal (Pa) is a SI-Unit so that should be used in the base code. Conversion from none SI-Unit can still be done in nasal code. Uh... except that aircraft gauges almost never read in SI units. The point here isn't one of purity (YASim is already using SI/MKS internally, FWIW), but one of practical engineering: duplicate properties are bad if they aren't needed. The point here wasn't to start a flame war about units, just to synchronize the existing standards with Vivian, who needs to actually use the property. If someone wants to go through and change all the existing property units to SI only, and then modify all the aircraft definitions, they have my hearfelt support. I ain't gonna. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Vivian Meazza wrote: control-input axis=/controls/engines/engine[0]/boost-control Here is the setting in the property browser Controls/engines/engine/boost-control= 1.0 Case bug or just a typo? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Vivian Meazza wrote: OK with the name. PSI(gauge) is what we use over here, otherwise it's inhg absolute for the US. Gauge-inhg makes no sense. In real life there's no difference between the way the US and UK measure the pressure, it's the zero on the gauge which is different, so I think it's correct the way it is. Gives the right gauge readings anyway. In this case, gauge is important though: it indicates that the value is a delta (the difference between MP and ambient pressure) and not an absolute pressure. Do you not want this value? That is what is normally termed boost when one talks about super/turbochargers. I named it that way to distinguish it from mp-inhg, which in the current code reports supercharger output before the 'wastegate' is applied. Yeah, but that's a bug. There is only one manifold pressure. Surely you don't want *both* mp-inhg and supercharger-output-inhg, which mean exactly the same thing. The important thing is for the pressure, in whatever units you want (apart from gauge-inhg), is reported _after_ the 'wastegate' etc. have been applied to the supercharger output. So it sounds to me like all you wanted was mp-inhg in the first place... I'll just chuck the new properties. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Vivian Meazza wrote: I found this in thrusters.cpp Another potential pooh trap? No, those are applied to the throttle setting after the input mapping has happened. The code you want to be reading is in ControlMap.[hc]pp Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Vivian Meazza wrote: I would deduce that the property: Controls/engines/engine/boost-control Does not exist when the solver runs. It should still see a zero for undefined properties, although you can make arbitrary property settings in the approach/cruise definitions up at the top. Some of the aircraft Note again, though, that you appear to have a case bug. The property tree name is controls, not Controls. I would back out your changes to the last version that works and re-add them one at a time. The change to the property input for the throttle control will not cause a change in solution results. Something else must have been modified. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
On Sat, 18 Jun 2005 15:24:09 -0700, Andy wrote in message [EMAIL PROTECTED]: Vivian Meazza wrote: OK with the name. PSI(gauge) is what we use over here, otherwise it's inhg absolute for the US. Gauge-inhg makes no sense. In real life there's no difference between the way the US and UK measure the pressure, it's the zero on the gauge which is different, so I think it's correct the way it is. Gives the right gauge readings anyway. In this case, gauge is important though: it indicates that the value is a delta (the difference between MP and ambient pressure) and not an absolute pressure. Do you not want this value? That is what is normally termed boost when one talks about super/turbochargers. I named it that way to distinguish it from mp-inhg, which in the current code reports supercharger output before the 'wastegate' is applied. Yeah, but that's a bug. There is only one manifold pressure. Surely you don't want *both* mp-inhg and supercharger-output-inhg, which mean exactly the same thing. ..I beg to differ; flow always means there are flow losses. The important thing is for the pressure, in whatever units you want (apart from gauge-inhg), is reported _after_ the 'wastegate' etc. have been applied to the supercharger output. So it sounds to me like all you wanted was mp-inhg in the first place... I'll just chuck the new properties. Andy -- ..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] New turbo/supercharger code
Vivian Meazza wrote: Good news: I've got Andy's code to run. Just a few minor changes. Bad news: It doesn't work. I've set the property /controls/engines/engine[0]/boost-control to a fixed value. Yasim shows the correct Boost value. But there's no power. What does show the correct boost value mean? You mean the property is set, or that YASim is seeing the throttle setting but somehow not acting on it? My only suggestion is to look harder for a typo or somesuch; make sure the property you are setting is the one you are reading. Note that higher up in the same file you are already using the same trick: control-input axis=/controls/flight/elevator control=FLAP0/ control-input axis=/controls/flight/elevator-trim control=FLAP0/ I'm quite certain this technique works. It's been in there, and actively used, since day one. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
Andy Ross Vivian Meazza wrote: Good news: I've got Andy's code to run. Just a few minor changes. Bad news: It doesn't work. I've set the property /controls/engines/engine[0]/boost-control to a fixed value. Yasim shows the correct Boost value. But there's no power. What does show the correct boost value mean? You mean the property is set, or that YASim is seeing the throttle setting but somehow not acting on it? Yes, more or less - PistonEngine.cpp seems to be seeing it, and you can see the boost going up and down with the throttle setting, but the power isn't which seems to eliminate the typo theory. My only suggestion is to look harder for a typo or somesuch; make sure the property you are setting is the one you are reading. I had a typo at one stage: I eliminated that one. I've eliminated the nasal code by substituting a single value for /controls/engines/engine[0]/boost-control. The previous email was a direct paste from the code. Note that higher up in the same file you are already using the same trick: control-input axis=/controls/flight/elevator control=FLAP0/ control-input axis=/controls/flight/elevator-trim control=FLAP0/ I'm quite certain this technique works. It's been in there, and actively used, since day one. Yes, I know it should work, and I'm familiar with its use elsewhere: this was behind my query yesterday. It seems to partially work. Odd. Well, I'll just have to eliminate all possibilities one by one. I think PropEngine.cpp is a likely candidate, but I haven't had time to look in depth yet. I'm very keen to make this work: it looks like the right way to proceed. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
I wrote: Andy Ross wrote I'm quite certain this technique works. It's been in there, and actively used, since day one. Yes, I know it should work, and I'm familiar with its use elsewhere: this was behind my query yesterday. It seems to partially work. Odd. Well, I'll just have to eliminate all possibilities one by one. I think PropEngine.cpp is a likely candidate, but I haven't had time to look in depth yet. I'm very keen to make this work: it looks like the right way to proceed. Here's the result of a short experiment: This is the entry in the config file control-input axis=/controls/engines/engine[0]/boost-control control=THROTTLE/ Here is the setting in the property browser Controls/engines/engine/boost-control= 1.0 Here is the output in the property browser Engines/engine/boost-pressure-psi-gauge = 46.00167 (correct order of boost) Engines/engine/mp-inhg = 123.613 Engines/engine/prop-thrust = 4655.708495 Velocities/airspeed-kt = 49.599 Something very odd is going on. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Vivian Meazza wrote: Engines/engine/boost-pressure-psi-gauge = 46.00167 (correct order of boost) Can you try it with the CVS code? This may be interacting badly with your local changes, which makes debugging difficult. Nothing in this mechanism should require any of the new code. Also on this subject: I started integrating the RPM-based supercharger attenuation, and noticed that your code added three new engine properties: mp-pascals: Is this needed? The standard so far for manifold pressure has always been inHg. Having lots of duplicate units around complicates things; we can always do conversions in the panel animations or Nasal code. boost-pressure-psi-gauge: This looks to have been hardcoded to sea level; it should be using ambient, no? Also, must the units be PSI, or can I change them to inhg? The final name would then be boost-gauge-inhg (units go last, and pressure is implicit in the units). boost-pressure-inhg: Reading the code, this looks like an absolute manifold pressure, and not a boost at all. Is this a mistake, it looks like a synonym for mp-inhg to me. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
On Saturday 18 June 2005 01:09, Andy Ross wrote: mp-pascals: Is this needed? The standard so far for manifold pressure has always been inHg. Having lots of duplicate units around complicates things; we can always do conversions in the panel animations or Nasal code. In this case inch Hg is wrong, because it is not an SI-unit. Pascal (Pa) is a SI-Unit so that should be used in the base code. Conversion from none SI-Unit can still be done in nasal code. We should really try to use only SI-units everywhere in the base code. If this is not the case, we should start to correct that. boost-pressure-psi-gauge: This looks to have been hardcoded to sea level; it should be using ambient, no? Also, must the units be PSI, or can I change them to inhg? Both is wrong, the SI-Unit Pascal (Pa) should be used. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
Andy Ross
Vivian Meazza wrote:
It would be possible to simulate the Boost Control Cutout by
adjusting the wastegate on the fly to a very high number effectively
disabling it (I take that it is possible to do that). It's a hack, I
don't like it, but ...
The whole thing is a hack anyway; if we *really* wanted a high quality
Merlin simulation we'd type a bunch of tables in (trivially easy, as
far as software goes). Since we don't have the numbers or the
patience to do that, we need to be prepared to handle per-aircraft
features with per-aircraft configuration. Again, we just can't have a
separate input axis for every possible control lever on every modeled
engine.
And regardless: If the cutout lever acts on the throttle (an existing
input) based on the manifold pressure (an existing output), then a
proper simulation ought to be possible using only the throttle
control, no? That is, define an extra input for the THROTTLE control
in the aircraft definition:
piston-engine ...
control-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/
control-input axis=/misc/wherever/merlin-boost-control
control=THROTTLE/
/piston-engine
And then write a little Nasal that sets this property to seek to the
target MAP:
BOOST_CONTROL_AUTHORITY = 0.2; # How much can it move the throttle?
BOOST_CONTRL_RANGE = 5; # When does it start to engage? (inHg)
BOOST_CONTROL_LIMIT = whatever; # Maximum MP (inHg)
updateBoostControl = func {
var mp = getprop(/engines/engine[0]/mp-inhg);
var val = (mp - BOOST_CONTROL_LIMIT) / BOOST_CONROL_RANGE;
if(val 0) {
val = 0; # Can't increase throttle
} elsif(val -BOOST_CONTROL_AUTHORITY) {
val = -BOOST_CONTROL_AUTHORITY
}
setprop(/misc/wherever/merlin-boost-control, val);
settimer(updateBoostControl, 0.1);
}
This has the nice advantage of actually simulating the underlying
hardware, so you get proper fuel consumption figures, etc... And it
doesn't require changing a line of the YASim implementation to do it.
I'm just really wary of adding a new control to the C++ code with an
implementation that doesn't even quite match what the gadget does in
real life. See if the Nasal mechanism fits your needs.
I like it very much indeed. Will it work in practice? Testing and tuning
will take some time as I don't have any exact data. Probably into next week.
With a little extension, it should cater for the Boost Control Cutout as
well. I'll probably convert it to psi gauge, since that's how we do it over
here.
It fits well with the rest of the Merlin engine stuff already written in
Nasal and embedded in the Hurricane and Spitfire models. There is a
downside, however, in that it may not be obvious to other aircraft designers
who want to simulate a Merlin. Naah ... Forget it - it can join the negative
g effect, the Coffman starter, the low speed cutout et al.
Very nice.
Thanks
Vivian
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Vivian Meazza wrote: I like it very much indeed. Will it work in practice? Testing and tuning will take some time as I don't have any exact data. Probably into next week. I suspect it should work fine. The real device would have been an analog computer hooked to a (presumably) slow motor, so the 10 Hz update rate shouldn't be too much of an issue. You could get fancy and use the interpolate() code to make it slew smoothly rather than jumping to the new value instantly. Note that there are at least a few bugs in the sample code: it needs to clamp to the range [-1:0] and then multiply by AUTHORITY, rather than generating the normalized value and then clamping to authority; it doesn't handle the cutout control, the tunables should probably be properties instead of hardcoded numbers, should have a failsafe case for an uninitialized FDM, etc... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
Andy Ross Vivian Meazza wrote: I like it very much indeed. Will it work in practice? Testing and tuning will take some time as I don't have any exact data. Probably into next week. I suspect it should work fine. The real device would have been an analog computer hooked to a (presumably) slow motor, so the 10 Hz update rate shouldn't be too much of an issue. You could get fancy and use the interpolate() code to make it slew smoothly rather than jumping to the new value instantly. I suppose you could define a spring, some bellows and levers as an analogue computer. Come to think of it, I've used a few like that. Add in a potter's wheel and a couple of differentials, and call it a fire control computer. Note that there are at least a few bugs in the sample code: it needs to clamp to the range [-1:0] and then multiply by AUTHORITY, rather than generating the normalized value and then clamping to authority; it doesn't handle the cutout control, the tunables should probably be properties instead of hardcoded numbers, should have a failsafe case for an uninitialized FDM, etc... Bugs, typos. It's running now, but doesn't work correctly. I need some info: Is this control-input axis=/controls/engines/engine[0]/throttle control=THROTTLE/ control-input axis=/controls/engines/engine[0]/boost-control control=THROTTLE/ Additive? I.e. are the input axes added? V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Vivian Meazza wrote: Additive? I.e. are the input axes added? Yes, all control axes are added to get the final value (clamped to the natural output range, of course); this is how trim works, for example. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
Andy Ross Vivian Meazza wrote: Additive? I.e. are the input axes added? Yes, all control axes are added to get the final value (clamped to the natural output range, of course); this is how trim works, for example. I thought so, thanks. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Vivian Meazza wrote: Andy Ross wrote Vivian Meazza wrote (in a CVS checkin): I've removed all the features that rely on the diff to YASim that I posted recently, I don't expect any reaction from Andy any time soon! I feel a bit inclined to remind him of his rant against Cygwin recently. I'm willing to be favourably surprised. Good grief. If you guys are going to snipe like this, at least keep it out of the public record. And try giving me more than 24 hours to reply next time. Easy stuff I can handle at work while I read the mailing list, but some stuff requires that I get home and actually run the simulator. Ouch! Many apologies and humble grovelling for the public whinge! Actually this might be my fault. I probably should have left it out of the CVS message. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
I wrote Already the case: see above. I considered a spline, but the extra complication doesn't really give a better outcome. Asymptotic ... OK up to a point, but at some rpm the compressor goes supersonic (depending on the design) and output falls away. I attempt to model this in a general way, while ensuring that the output remains positive for all rpm values, no matter how unreasonable. I'll put the output on my website so that you can see. I'm satisfied with this solution, but others are, of course, possible. I've put the curves here: http://myweb.tiscali.co.uk/vmeazza/FlightGear/supercharger-1.pdf http://myweb.tiscali.co.uk/vmeazza/FlightGear/supercharger-2.pdf You can see that the Hoerl power function (labelled 'power') is nicely behaved for all values of rpm. I would argue that perhaps it ought to drop more steeply past peak power, but that's only instinct - I have no numbers to support it. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
Vivian Meazza wrote: Andy Ross wrote: * For one, I still hate the boost function that goes negative at high RPM I have revised the curve: now a Hoerl power function. It's a good fit over the rpm range up to x4 peak power rpm (unnecessary: x3 is too much imho) and tails off thereafter reflecting less output as more of the compressor stalls. The output remains positive for ALL values of rpm, and won't break under any circumstances. OK, check. This doesn't look bad at all. It's asymptote is zero, which still sounds wrong to me*, but as you point out it doesn't reach that regime until well beyond a meaningful operating range. * My wife, in graduate school, did work with very high vacuum gas phase chemistry. The first line of pumps attached to the vacuum chamber were turbo pumps which, as I understand it, were essentially very high speed fans designed to whack any stray molecules out of the chamber kinetically. This corresponds loosely to a compressor operating in a very high supersonic regime, where inter-molecule reactions are irrelevant -- there will still be some boost just due to the kinetic operation of the compressor rotation. Dunno, just intuition obviously. + Explain better why you want the new CUTOUT control and didn't just make the wastegate setting modifiable at runtime (which simplifies the engine model and seems more general, IMHO). The Merlin (Hurricane, Spitfire and P51d) had a Boost Control which acted on the throttle to control the boost pressure: I briefly considered modelling that, but it is adequately modelled by the wastegate in YASim. The CUTOUT control seems to me to be simple to implement, reflects the way it worked in reality, and is applicable to several models. OK, so the boost control was like a wastegate then: A spring-loaded pressure release value that opened up to keep the manifold pressure clamped to some fixed value? And it was analog-adjustible? The reason I ask is because the Mustang POH I have doesn't (I don't think) mention a control like this. What it did have is a lever to select which of the three supercharger states were active: no supercharging, first stage blower, or second stage blower. Literally, it was just linked to valves that opened up around each of the two gear-driven compressors. No analog control whatsoever -- just a warning not to engage each blower below/above certain altitudes and power settings . And it wouldn't have behaved like a turbo waste gate. The boost for a given stage is more or less solely a function of RPM and doesn't have the clamping behavior that the wastegate setting would show. My guess is that the cutout switch in the UK planes is just a different user interface for the same underlying ductwork, and that using a new control axis is not needed. Instead, how about using the existing BOOST input and setting its value to (for example) 0.0, 0.5 and 1.0 based on the position of the cutout lever and the blower stage lever (or whatever it's called in the Hurricane). I'm willing to be wrong on this; I certainly don't claim to be an expert on engines in general or the Merlin specifically. But even so, here's a software engineering justification for ejecting the CUTOUT control. The existing code tries really hard to be general, and useful for many aircraft. Adding a new control axis corresponding to every control idiom in every aircraft we want to model is going to get out of hand really quickly. Regardless of which one of us is correct above, the CUTOUT axis can already be implemented by using the existing engine code unchanged: the BOOST control is already there, and all that would be needed for the wastegate hack would be to make it configurable (i.e., the engine code doesn't change). This is preferable, IMHO, to mucking with the internals of the engine model. I know your change was a one-liner bit over override logic, but the problem is that the engine code already has a bunch of stuff like that, and it's already getting hard to follow. Your change might look simple right now, but add three more one-liners and it won't be quite so obvious which one has precedence and subtle bugs will get introduced; exactly this kind of thing happened with the gear ratio code. It literally took almost a year for that (conceptually simple!) change to stabilize and work its bugs out. The cleanest solution at this point, IMHO, would to split out the x-charger implementation and do it twice: once for gear-driven superchargers and again for exhaust-driven turbochargers. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
On Wed, 15 Jun 2005 10:26:33 -0700, Andy wrote in message [EMAIL PROTECTED]: The cleanest solution at this point, IMHO, would to split out the x-charger implementation and do it twice: once for gear-driven superchargers and again for exhaust-driven turbochargers. ..these can re-use code between themselves, the most important differences between them is how the compressor shaft is spun, and how these superchargers are controlled. -- ..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] New turbo/supercharger code
Andy Ross wrote: Vivian Meazza wrote: Andy Ross wrote: * For one, I still hate the boost function that goes negative at high RPM I have revised the curve: now a Hoerl power function. It's a good fit over the rpm range up to x4 peak power rpm (unnecessary: x3 is too much imho) and tails off thereafter reflecting less output as more of the compressor stalls. The output remains positive for ALL values of rpm, and won't break under any circumstances. OK, check. This doesn't look bad at all. It's asymptote is zero, which still sounds wrong to me*, but as you point out it doesn't reach that regime until well beyond a meaningful operating range. The graphs I have seen really don't explore the condition much above the normal operating regime. A stalled compressor won't pump much though. * My wife, in graduate school, did work with very high vacuum gas phase chemistry. The first line of pumps attached to the vacuum chamber were turbo pumps which, as I understand it, were essentially very high speed fans designed to whack any stray molecules out of the chamber kinetically. This corresponds loosely to a compressor operating in a very high supersonic regime, where inter-molecule reactions are irrelevant -- there will still be some boost just due to the kinetic operation of the compressor rotation. Dunno, just intuition obviously. Hmmm. Pressure of a few molecules being smacked about - call it zero. But when it's the last few in a vacuum chamber worth doing. + Explain better why you want the new CUTOUT control and didn't just make the wastegate setting modifiable at runtime (which simplifies the engine model and seems more general, IMHO). The Merlin (Hurricane, Spitfire and P51d) had a Boost Control which acted on the throttle to control the boost pressure: I briefly considered modelling that, but it is adequately modelled by the wastegate in YASim. The CUTOUT control seems to me to be simple to implement, reflects the way it worked in reality, and is applicable to several models. OK, so the boost control was like a wastegate then: A spring-loaded pressure release value that opened up to keep the manifold pressure clamped to some fixed value? And it was analog-adjustible? It's actually nothing like a wastegate. Strictly speaking a wastegate stands between the exhaust valves and the turbo to adjust the inlet pressure to the power turbine by allowing more or less of the exhaust gas to bypass the power turbine. It may be controlled by a spring or in more sophisticated applications by sensors on the inlet side. The effect is to control manifold air pressure (MAP). What YASim models should more properly be called a MAP controller. The reason I ask is because the Mustang POH I have doesn't (I don't think) mention a control like this. What it did have is a lever to select which of the three supercharger states were active: no supercharging, first stage blower, or second stage blower. Literally, it was just linked to valves that opened up around each of the two gear-driven compressors. No analog control whatsoever -- just a warning not to engage each blower below/above certain altitudes and power settings . I'm confused - I'd like to see the actual words. All the references that I've seen say that the Merlin came with 3 basic varieties of supercharger: a. Single stage, one speed. E.g. Hurricane I, Spitfire II b. Single stage, 2 speed. E.g. Hurricane II, Spitfire III c Two stage, two speed. E.g. Spitfire IX, Mustang P51 There was only one blower - the 2 stage had 2 impellers on a single shaft. The output of the first stage fed to the input of the second stage via an intercooler and thence to the engine via an aftercooler. Where there were 2 speeds, known, for some reason obscured by time, as 'moderate' and 'full', these were selected by an electro-hydraulic clutch mechanism working in conjunction with a planetary gear train. I know of no reference to an unboosted or neutral position for this mechanism. I thought that the gear change was manual, but I've just written some nasal code for Jim Wilson which changed gear according to height, so perhaps not. (I haven't got a reference to that either - Jim?) And it wouldn't have behaved like a turbo waste gate. The boost for a given stage is more or less solely a function of RPM and doesn't have the clamping behavior that the wastegate setting would show. The Boost Control clamped the supercharger output to the preset value (higher as time went by and superchargers improved and higher octane fuel became available*) by retarding the throttle as the limit was approached. It could only be adjusted by mechanics on the ground. * 6 psi to 9 psi at the start of the war. The introduction of 100-octane fuel allowed a rise to 18 lb, allowing considerable increases in power output. The introduction of 150-octane fuel in 1944 allowed further increases to 25 lb boost. My
Re: [Flightgear-devel] New turbo/supercharger code
Vivian Meazza wrote:
It would be possible to simulate the Boost Control Cutout by
adjusting the wastegate on the fly to a very high number effectively
disabling it (I take that it is possible to do that). It's a hack, I
don't like it, but ...
The whole thing is a hack anyway; if we *really* wanted a high quality
Merlin simulation we'd type a bunch of tables in (trivially easy, as
far as software goes). Since we don't have the numbers or the
patience to do that, we need to be prepared to handle per-aircraft
features with per-aircraft configuration. Again, we just can't have a
separate input axis for every possible control lever on every modeled
engine.
And regardless: If the cutout lever acts on the throttle (an existing
input) based on the manifold pressure (an existing output), then a
proper simulation ought to be possible using only the throttle
control, no? That is, define an extra input for the THROTTLE control
in the aircraft definition:
piston-engine ...
control-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/
control-input axis=/misc/wherever/merlin-boost-control
control=THROTTLE/
/piston-engine
And then write a little Nasal that sets this property to seek to the
target MAP:
BOOST_CONTROL_AUTHORITY = 0.2; # How much can it move the throttle?
BOOST_CONTRL_RANGE = 5; # When does it start to engage? (inHg)
BOOST_CONTROL_LIMIT = whatever; # Maximum MP (inHg)
updateBoostControl = func {
var mp = getprop(/engines/engine[0]/mp-inhg);
var val = (mp - BOOST_CONTROL_LIMIT) / BOOST_CONROL_RANGE;
if(val 0) {
val = 0; # Can't increase throttle
} elsif(val -BOOST_CONTROL_AUTHORITY) {
val = -BOOST_CONTROL_AUTHORITY
}
setprop(/misc/wherever/merlin-boost-control, val);
settimer(updateBoostControl, 0.1);
}
This has the nice advantage of actually simulating the underlying
hardware, so you get proper fuel consumption figures, etc... And it
doesn't require changing a line of the YASim implementation to do it.
I'm just really wary of adding a new control to the C++ code with an
implementation that doesn't even quite match what the gadget does in
real life. See if the Nasal mechanism fits your needs.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New turbo/supercharger code
Vivan Meazza wrote (in a CVS checkin): I've removed all the features that rely on the diff to YASim that I posted recently, I don't expect any reaction from Andy any time soon! I feel a bit inclined to remind him of his rant against Cygwin recently. I'm willing to be favourably surprised. Good grief. If you guys are going to snipe like this, at least keep it out of the public record. And try giving me more than 24 hours to reply next time. Easy stuff I can handle at work while I read the mailing list, but some stuff requires that I get home and actually run the simulator. This is decidedly not a trivial patch*, and takes time to test. No one else reported trying it, so that means I need to manually load up the engine definitions of every turbo/supercharged engine, verify that the plane can't reach the non-physical regime, make sure the solver still completes and that the parameters don't change too much, and only *then* worry about what the new features mean (example: why is there a cutout control? Couldn't that be done more generally by making the wastegate value settable? Did the Hurricane even have a wastegate? What gadget the cutout lever control?) * For one, I still hate the boost function that goes negative at high RPM, and am 60% sure it's going to hurt someone somewhere. For another, it's clearly modelling a supercharger; it doesn't correspond well to turbocharger behavior, nor does it provide a sane migration path to a simulation engine that supports both in a general way (or splits them out into separate objects). Now, of course, I am out of time before work and won't be able to work on this more until tonight. If you want to help me out, stuff like this would be really useful: + Fit a boost function that is asymptotic in the high RPM regime and doesn't go negative. More than anything else, this is what freaks me out the most about your patch. We discussed a few earlier, for example. Note that it can be piecewise: you don't need just one equation. + Try the other turbo/supercharged aircraft in the command line solver and provide output for the before/after case to verify that nothing weird is going on. + Explain better why you want the new CUTOUT control and didn't just make the wastegate setting modifiable at runtime (which simplifies the engine model and seems more general, IMHO). + Convince other folks to try the changes and report success. Just for the record: if this were an obvious fix or an simple/orthogonal new feature, then I would just apply it like I apply other fixes. It is neither, which means (I'm sorry) we are both going to have to do more work. Pissing me off isn't helping. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New turbo/supercharger code
Andy Ross wrote Vivian Meazza wrote (in a CVS checkin): I've removed all the features that rely on the diff to YASim that I posted recently, I don't expect any reaction from Andy any time soon! I feel a bit inclined to remind him of his rant against Cygwin recently. I'm willing to be favourably surprised. Good grief. If you guys are going to snipe like this, at least keep it out of the public record. And try giving me more than 24 hours to reply next time. Easy stuff I can handle at work while I read the mailing list, but some stuff requires that I get home and actually run the simulator. Ouch! Many apologies and humble grovelling for the public whinge! This is decidedly not a trivial patch*, and takes time to test. No one else reported trying it, so that means I need to manually load up the engine definitions of every turbo/supercharged engine, verify that the plane can't reach the non-physical regime, make sure the solver still completes and that the parameters don't change too much, Already done, but you'll want to check, I expect. only *then* worry about what the new features mean (example: why is there a cutout control? Couldn't that be done more generally by making the wastegate value settable? Did the Hurricane even have a wastegate? What gadget the cutout lever control?) I would do this work if it didn't? :-) * For one, I still hate the boost function that goes negative at high RPM, and am 60% sure it's going to hurt someone somewhere. For another, it's clearly modelling a supercharger; it doesn't correspond well to turbocharger behavior, nor does it provide a sane migration path to a simulation engine that supports both in a general way (or splits them out into separate objects). I have revised the curve: now a Hoerl power function. It's a good fit over the rpm range up to x4 peak power rpm (unnecessary: x3 is too much imho) and tails off thereafter reflecting less output as more of the compressor stalls. The output remains positive for ALL values of rpm, and won't break under any circumstances. I agree that this is optimised for a supercharger. I don't believe that a compromise between turbo and gear driven is possible for maximum realism. On the other hand this is better than the present situation. I have a curve for a turbo up my sleeve. However, it is very definitely art not science, because turbo installations vary, and dealing with throttle opening is complex. A very general model should be possible if it is felt that a near linear response is not OK. It will be necessary to identify turbo or gear driven superchargers. Now, of course, I am out of time before work and won't be able to work on this more until tonight. If you want to help me out, stuff like this would be really useful: + Fit a boost function that is asymptotic in the high RPM regime and doesn't go negative. More than anything else, this is what freaks me out the most about your patch. We discussed a few earlier, for example. Note that it can be piecewise: you don't need just one equation. Already the case: see above. I considered a spline, but the extra complication doesn't really give a better outcome. Asymptotic ... OK up to a point, but at some rpm the compressor goes supersonic (depending on the design) and output falls away. I attempt to model this in a general way, while ensuring that the output remains positive for all rpm values, no matter how unreasonable. I'll put the output on my website so that you can see. I'm satisfied with this solution, but others are, of course, possible. + Try the other turbo/supercharged aircraft in the command line solver and provide output for the before/after case to verify that nothing weird is going on. I had already checked every propeller driven YASim models (supercharger and none, even with legacy code). As I said: so far as I could see there were no adverse effects. I should have been explicit. + Explain better why you want the new CUTOUT control and didn't just make the wastegate setting modifiable at runtime (which simplifies the engine model and seems more general, IMHO). The Merlin (Hurricane, Spitfire and P51d) had a Boost Control which acted on the throttle to control the boost pressure: I briefly considered modelling that, but it is adequately modelled by the wastegate in YASim (as you yourself said here earlier). The Boost Control Cutout bypassed the Boost Control. The CUTOUT control seems to me to be simple to implement, reflects the way it worked in reality, and is applicable to several models. It avoids any complex interaction between it and the supercharger output curve. However, if this change gives you real difficulty, then I suppose setting the wastegate value to a very large value would be the equivalent. Bit of hack though and therefore feels unprofessional when a proper solution is so easy (and available). + Convince other folks to try the changes
