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
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)
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
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
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
-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
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 *
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.
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
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
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
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 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
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
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
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
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.
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
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
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
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
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))
22 matches
Mail list logo
