Received-SPF: softfail
 receiver=logan.com; client-ip=171.68.10.86; envelope-from=echristley@nc.rr.com
Message-ID: <4651C665.7030508@nc.rr.com>
Date: Mon, 21 May 2007 12:18:45 -0400
From: Ernest Christley <echristley@nc.rr.com>
Reply-To: echristley@nc.rr.com
User-Agent: Thunderbird 1.5.0.10 (X11/20070403)
MIME-Version: 1.0
To: Rotary motors in aircraft <flyrotary@lancaironline.net>
Subject: Re: [FlyRotary] Re: Marginal Cooling
References: <list-2056510@logan.com>
In-Reply-To: <list-2056510@logan.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.