Personally I believe that a cooling system should be able to:
a) Run indefinite on the ground - like long waiting cues on taxi ways, any wind direction
b) Support a min 1 min full power run-up
c) Support a min 5 min Max Power climbout at any possible speed (slower being the worst....)
I'd rather play with movable cowl-flaps, etc. than accepting that I might not be able to pull full power at any point.
What if you are already maxed out, because OAT is high, you are heavy, in a nasty turbulence and have to do an "emergency" climb out.
You have an engine, that could do it easily, ....if you had a system that would cool it.
Plan starts with rereading all cooling posts, get the calculator, get familiar with heat transfer tables, plan on spending some serious money for custom coolers....
Plan is to built for the worst case. I always can reduce cooling....
Thomas
On 5/21/07, Ernest Christley <echristley@nc.rr.com> wrote:
al p wick wrote:
> Ernest, take a look at all of your responses to my previous posts. I
> think you'll find you've never agreed with anything I've ever posted. Not
> the tiniest thing. I have the impression you are so keen to find fault
> that there really isn't any chance for exchange. If you could throw me a
> bone every once in a while, I'd at least think you were reading my posts.
>
Quite the contrary. My fuel and brake lines have supports every 6 to 8
inches. You can take full credit for that.
I initially jumped in with both feet trying to determine the failure
probability of various components, making charts to assign values to
failure probability and seriousness of effects. I threw my hands up in
frustration over that effort for the same reason this one frustrates
me. It was an exercise in replacing "That's About Right" (TAR)
engineering with more precise TAR engineering. I didn't know the
failure rates of the components, and had no way of finding out.
Predicting the seriousness of the failure was a further exercise in
pulling numbers out of the darker regions of my anatomy.
It's a very clear distinction. You state a clear problem with a clear
solution. Not only do I support you, I implement the solution in an
airplane I'll be betting my life on. Even if you only state a problem,
even just make it a little clearer, I'm 100% behind you. But when you
break down to the "do fuzzy math with fuzzy numbers" preaching I can't
support you.
Now, how about throwing us a bone, Al. We are not making hundreds or
thousands of an identical item. We're a varied group, working in varied
environments, with varied amounts of skill on various types of
projects. Statistics are irrelevant when you have a sample size of
one. What we have done here is share as much information as we're able,
relating what works and what doesn't. If you'd like to meet up with as
many as possible at flyins and setup a battery of tests, I'm sure you'd
get support. But I doubt anyone but you on this list has ever heard of
Taguchi, and wouldn't have time or energy to set up a battery of tests
if he were an inlaw. We're hobbyist working part-time with limited
funds. To set up a Taguchi experiment I'd need a lot more of both, and
only AFTER I spent some time studying how to do it. That is guaranteed
NOT to happen before I've studied and understood K&W. Why go taking
shots in the dark when someone has provided a light.
> I agree, the human factor is not easy to change. With businesses, I found
> I could influence the human factor a bit...but not much. So I always
> place my efforts in those factors that are changeable.
> I interpret your statement to be "you can't improve something if you
> can't define the goal clearly". I disagree. We can still lower that temp
> during climb by measuring and testing. I appreciate how that may make you
> feel uneasy.
>
>
So you lower the temps during climb? What did it improve? How much did
it improve it? What did you give up in order to achieve that goal? Was
it worth the effort?
You can make a plane faster by making the gear retract, but in the
process you have to add loads of complexity and the weight of all the
extra equipment will offset the reduction in drag. Lots of work.
Potentially no payoff. You can design a cooling system to survive
indefinite full-power run-ups. I would say the the person who designed
such a system failed to consider the goals as badly as one that would
put retracts on a J-3 Cub.
> I would define my max temperature same as what an Arizona RX car sees.
> The peak temp. Including water and oil. So if I can push my Arizona RX to
> achieve 220 F coolant, then I would define 220F as my absolute maximum. I
> think Perry did this. Not in Arizona.
>
>
Now this I support. Real numbers for which you can design a real test.
I can disagree, saying your numbers are to high or to low, but I'd have
to counter with other real numbers. If I come back with, "That's
marginal", it would beg the question of what should the numbers be.
I'll answer that the numbers should go back to the original design
goals. How many passenger cars are designed to run WOT from one end of
Arizona to the other, uphill, both ways? That's what it means to have
an indefinite climb, after all. The RX in Arizona will have an
air-conditioner. My airplane won't ( it is actually the passenger
cooling that is marginal). I wouldn't attempt the Arizona death drive
without AC and I won't do it in my airplane; therefore, why would I make
the sacrifices (top end speed reduction) required to have the airplane
handle conditions it won't see?
Here we get to my point. Engineering is making the most with the
least. You start with a big chunk and shave off everything that isn't
necessary to achieve THE GOAL. Without THE GOAL, you won't know what is
necessary and what is wasted resources. What you are really saying is
that THE GOAL of some rotary builders is misguided. You're stating that
they are exchanging safety for performance. That's OK. I'm behind
that. I support that. But if you can't tell where they're crossing the
line, then you're back to TAR engineering. I do some TAR engineering,
but I won't argue that others should follow it.
> That means my engine would have same risk as that Arizona vehicle, which
> statistically is likely to be low risk. Just based on assumption they
> would not place any engine into service that can't handle normal
> environmental variation. This all based on my background in automotive
> product validation. You guys have anyone on the list familiar with
> validation testing? It's pretty cool stuff. Way different than historical
> methods.
>
>
I'm familiar with validation testing. I do it for a living. You start
with a design spec, and develop tests from that. You VALIDATE that the
product meets the design goals. We're fighting a battle right now where
one strain of the software is taking to long in boot up. Fighting back
and forth with development. We write a bug. They close it as bogus,
saying we need to open up our test times. The root cause of this
problem is that the design team wrote something along the lines of, "The
software will boot in a reasonable amount of time." Sorry. My test
scripting language doesn't have a construct such as:
if { bootTime <= reasonable } {
set testPass TRUE;
}
I have to give it a number. "Marginal" and "reasonable" are both weasel
words that I personally use as often as I can when I don't know what the
real limits are, but they have no place in a design document, other than
as a placeholder in an incomplete design.
> Johns plane with turbo has unlimited hp. So I'd record the parameters
> that cause me to peak at 220F. Let's say that's climb at 1500 fpm,
> 100mph, at 80F oat. Then I'd do Taguchi experiment with those items I can
> change easily. The goal being to climb at that same rate, but get temp to
> drop. For sure that would include all sorts of duct mods, as air flow
> thru rad blew away my last test results.
>
>
Al, some of us want to fly our airplane to actually go somewhere some
day. To many experiments. Not enough daylight. At some point you have
to say, "Good enough" and be done with it. John could build 100 ducts
with his unlimited funds, or he could power back to a cruise climb once
he's over the trees. I know which I would choose, and it involves
thinking about the next duct design as my wife and I stretch out on the
beach we just flew to. I have to argue with my software engineering
comrades on a regular basis that the user is part of the system. It's a
waste to invest resources making a dialog box flash to the screen
faster, when I already lack the reflexes to respond immediately. I'm
the limiting factor. Resources should go to making the human-computer
interface faster. Likewise, it is possibly a waste for John to build
duct after duct to get incrementally more cooling when he still has
reserve after leveling to a cruise climb (which he will have to do at
some point anyway, if for no other reason than to search for traffic.)
The climb time is limited by a necessity other than cooling, ie. prudent
flying; therefore, the system is not marginal.
--
Homepage: http://www.flyrotary.com/
Archive and UnSub:
http://mail.lancaironline.net:81/lists/flyrotary/List.html
|