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 wha
> -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 S
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
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,
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
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/turbochar
> 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.
> 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 d
> 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
> 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.)
>
>
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
>
> Vi
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
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 th
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 c
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 th
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 pr
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 perform
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
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
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
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 tranc
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 b
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
23 matches
Mail list logo
