Thursday, September 28, 2006

Great Design: Money versus Savvy

I love to see great design. I love small and efficient design and I just hate waste in any form. One engineering concept that shows the striking difference between good design and bad design is in traditional manned space travel versus the new Virgin-backed concept. In the Saturn V rockets we had enormous rockets on a launch pad with a design based on dumping big chunks of metal in space, and expending huge quantities of fuel. These were necessary because of the problems of launch and re-entry. The launch idea was based on the launch of the unmanned V2 rockets in WW2, mainly because the designer of both was Werner von Braun. But manned spaceflight doesn't actually need a launchpad - it has people to guide it. Take away the launch pad and piggy back the rocket on a standard aircraft and much less fuel is needed and no parts need to be thrown away. The re-entry idea was even better! The amount of money NASA wasted on a badly designed reusable shuttle should be enough to disband NASA. Worse still, they actually blamed the shuttle disasters on a lack of funding. Eh? In fact the shuttle and the rockets before it were designed by an enormous complex of people with phd's but no imagination. The main problems with the shuttle are the enormous launch boosters and the heat of the re-entry on the fixed wing design. But we already knew that a dropped capsule worked just fine without all these hugely expensive thermal tiles so why not have a movable wing design and just drop back through the atmosphere and then glide again when we've dropped. Totally brilliant in its simplicity, and the result of just one inspired designer with a background in flight. What are the lessons learned here?
1. Unlimited money leads to an expensive design. Limiting money forces better design.
2. One person with savvy is worth more than several thousand Phd scientists.
3. You probably need experience of flight if you are going to design flying machines.

On a related note. You may have noticed that Western weapons technology is generally outperformed by Russian technology. In fact the West is usually playing catch-up in capability terms (Mig aircraft, T-34 tanks in WW2, Sunburn misssiles etc, etc.). Of course the Western stuff costs billions and the Russian stuff costs peanuts. Western companies are much better at marketing than technology it seems. A glaring example being the patriot missile, whose projected 99% success rate was discovered to be in reality about O%. There are many, many other examples of this type of unjustified hype! However, now that the cold war is over and the Russians are clearly our friends, perhaps someone should suggest that the West could save a fortune by buying it's weapons from Russia. Just a thought, in case someone was wondering how to fund all these retiring baby boomers.

Sphere: Related Content

Tuesday, September 26, 2006

Fatigue Stress Assessment

Introduction

Resistance to fatigue was long thought to be a property of the metals because some metals react worse than others. Steel is good against fatigue, titanium is not. Titanium though is preferred by engineers because it is lighter and more exotic. So much for designing against fatigue failure! Lucky for us punters titanium is too scarce.

Total Life Fatigue Design

Fatigue we are constantly reminded is responsible for about 80% of failures. Straight from the department of guesswork or should I say from the sales dept. All we really know is that all structures are dynamic and undergo cycling so unexplained failures are probably caused by a fatigue mechanism. Just as well we have well-defined and long-standing techniques for calculation the onset of fatigue. Ho ho ho! Let us recap. Actually the reason that fatigue is blamed so often is that it is the most likely miscalculation in the design path. Yes I know the software salesmen tell you that their fatigue software can predict failure to an incredible accuracy. As you will see though, when you know the end result it's very easy to fiddle the in-between calculations to get there. In fact fatigue calculations are an endless series of fiddle factors.

Try this one Kf=Kt*Ks*Ke*Km*K.......

Kf is the fatigue strength reduction factor, introduced because the mathematics of the Kt calculation doesn't actually match with real life. So you need a material factor, an environment factor, a shape factor, a temperature factor etc. This equation alone is enough to invalidate your results.

Try this one too; Miner's cumulative damage rule:

n1/N1 + n2/N2 + n3/N3 ....... <=1.0

Where n is the number of cycles in each cyclic load condition and N is the corresponding number of cycles which it needs to fail. Simple and universally utilised but, unfortunately it doesn't compare well to real life situations. Instead of 1 you can substitute C. Wikipedia says "C is experimentally found to be between 0.7 and 2.2. Usually for design purposes, C is assumed to be 1", which Miner suggested on the basis of logic. I have seen data though which suggests C can be as low as 0.1. Ergo this calculation is thoroughly useless. Furthermore, N has to be adjusted for temperature by yet another fiddle factor. Why do we use this formula you may ask? Because no one has come up with anything better. There is really no mystery that it doesn't work because it ignores the effect of a previous cycle on the next cycle and it assumes uniaxial loading which only ever happens in a laboratory tensile test.

As if the level of guesswork wasn't enough we come across the "what you see is what you fiddled" miracle of rainflow counting in which you can manipulate the number of peaks and troughs of the load cycle by changing the sampling amount or "bucket size". Rainflow counting is not even logical because once you have opened a crack in one cycle, a further cycle which opens it half as much has no actual effect. So adjusting the bucket size is just a technique to magically reproduce already known results which is why those fatigue computer programs seem so accurate. It is a lot easier to predict failure when you already know what happened but we really want to predict failure before it happens.

Useless fatigue calculation summary; Find your SCF based on a fillet radius and thickness from Peterson's handbook of hopelessly limited 2D shapes, then multiply it by a variety of guess factors for environment, loading type, etc. Next reduce the factor by the fracture toughness factor which corrects for the fact that SCF's hopelessly overpredict the onset of fatigue in real life. Of course this value is only of use if the test was done on your actual structure, which it wasn't. Apply the final factor to your field stress, which is the general stress away from the discontinuity. The field stress concept is also based on simple 2D shapes and simple loading. It is not possible to obtain a field stress in any real situation unless you linearise the highly nonlinear stresses. A technique which is controversion and idiosyncratic, even impossible in a 3D situation. Finally find the expected life from a suitable endurance curve. This curve was produced for simple 1D specimens under simplistic loading and it had originally a phenomenal scatter which someone plotted on a logarithmic scale and drew a couple of straight lines through it: They could easily too have drawn a dancing bear through it. Of course you must further adjust the lines according to the extent of compression in the load cycle. For every cycle find a life fraction and add these fractions to get a total life value for the part using Miner's cumulative damage rule which has long been proven to be total nonsense. If you have a load history which is not conveniently sinusoidal then use rainflow counting to capture each mini-cycle within the larger cycles, then disregard the majority of these cycle "buckets" so as to not to be too conservative (because rainflow counting doesn't represent real life). Finally you will arrive at the conclusion you need. In this case, if it is someone elses design you must fail it by including for all eventualities, but if it is your design you must consider all the unnecessary assumptions until you manage to pass it.

Well that procedure was for high cycle, elastic stresses. There is a low-cycle, strain-based calculation for materials in the plastic regime. However it is currently carried out by using elastic stresses and assuming a Neuber plasticity curve. NAFEMS adroitly points out the inadequacy of this approach in a book on it's website, wherein it is pointed out that plastic computations would not only be possible but far more desirable. For me this approximation alone is enough of a fudge to render the calculation useless so I avoid discussing the remaining fiddle factors. However this technique is universally used in current Fatigue software. In fact the prostitution of several prominent academics in presenting this approximation technique as the last word in fatigue design is really quite disagreeable. I suggest you avoid said software and get instead the AFGROW program from the net. It's probably no better but it is well documented, well used and free. We may do a user interface for it one day.

Meantime, there is a module in FEMdesigner to plot the fatigue strength of the material but we use stress ratios instead of life predictions. Here there is only a maximum and minimum stress, an endurance strength (obtained with consideration of the design life) and a fatigue strength reduction factor. The software reads all the stresses in the current output file, calculates the maximum & minimum equivalent stresses, makes them tensile or compressive (+/-) according to the sign of the largest principal stress and applies the Goodman mean stress correction, then finds the endurance limit and adjusts for temperature of the material and presents the result as a red/green contour plot of Actual to Allowable stresses at each point in the model. It repeats this for every load step in this file and in selected other files presenting the worst values in all cycles. This test was developed and tested with performance forged pistons and it works well. Assuming only one maximum and one minimum stress for all cycles is a perfectly valid, well-used technique and avoids both the discredited rainflow-counting technique, Miner's rule and log-log plots. Goodmans stress correction has a lot of actual tests to back it up. The addition of the temperature correction is crucial as it seriously degrades fatigue life in many materials. In FEMdesigner that is made easy. In other fatigue codes it is not. In the nuclear engineering field we also used to prepare low-cycle, strain-based fatigue curves, for which this technique becomes usable. Fatigue tests are best done with the actual component under the actual loading of course. That may seem nonsensical since you may think you don't then need the computational test, but the key idea is to computationally replicate the actual results for the old design, identify the failure areas, modify the design to improve it, then compare the old design to the new one.

The alternative to total life calculation is fatigue from Fracture Mechanics considerations.

Fracture Mechanics and Fatigue

Fatigue it is now accepted is really just fracture in disguise. Hence fatigue is really the initiation of a crack from a material or geometric imperfection and propagation of that crack. This should have seemed obvious but for many years fatigue has been regarded as something that happens by repeated cycling of a body in an elastic state. Although it was material related, it was considered as load-controlled. Fracture mechanics grew up separately by looking at material behaviours at low temperature and then at what happens to notched specimens. We had realised that fatigue and fracture both happen at sharp corners so we invented Stress Concentration Factors for fatigue and Stress Intensity factors for Fracture. Still the penny never dropped because fatigue and fracture calculations were done separately. For both types of calculations we had so many assumptions so we still uultimately fall back on material testing of the actual component whenever possible.

There are two official stages Crack Initiation and Crack Growth. A crack growth calculation seems silly. You know there is a crack but instead of repairing it you calculate how long it will take before catastrophic failure occurs under a variable multiaxial load. When it does come, the crack apparently proceeds at 1/3 of the speed of sound, hence the term "catastrophic". Now I ask you, in all seriousness, would you get on an aircraft if you knew it had a crack in the wing? The answer is obvious, so a crack propagation calculation is largely an academic exercise. In practice if you see a crack you should stop using the component and repair it. Unfortunately, that was the easier calculation of the two. Crack growth calculations are summarised below:

Useless fracture calculation summary; You receive your NDT report which either shows you a crack in an X-ray from one angle, from which it is impossible to tell the real shape, or from an ultrasonic report which states that there is an "indication of size below 3mm". As you then don't know a crack shape you must do a "sensitivity analysis". That is, try every pertinent shape from the list of impossibly clean and mathematically perfect crack shapes to get your SIF. Ignore the extreme unlikelihood of not having an elliptically shaped crack. Then guess the positive residual stresses adjacent to the crack (because cracks in compression won't grow) assuming some fraction of yield. The final report will state that the crack will undoubtedly grow, and hence the structure will fail, under at least some of the fake scenarios you have been forced to use. Again you can happily pass your own design but fail someone elses depending on your assumptions and your degree of malevolence.

You can use your FE code to calculate the SIF and a certain Dr. Pook wrote a paper on it using FEMdesigner. For the future though we hope to consistently compute the crack path computationally.

Sphere: Related Content

Monday, September 25, 2006

Analyst or designer?

You will find many people ready to say that novices should not be allowed near FEA software. "It's too easy to make a big mistake goes the argument". It is always left unsaid that it is much more easy to screw up using good old fashioned hand calculations. You remember those don't you? How to reduce your fancy design to a plain cantilever beam! Ignore holes, and fillets and anything else inconveniently stuck on your free body diagram. Remember to check the text of those 1933 reference papers in Roark with their quaint uneven and unreadable graphs conveniently converted to number format.

So why the big downer on FEA from academics? Well it's true that FEA is rubbish in, rubbish out. However, being able to actually see the mesh, the applied loads, the stress plots, the displacements, a reasonably capable supervisor system should be able to spot any howlers; Theres the rub! Your boss usually didn't get there by being good at design: He doesn't know a Von Mises Stress plot from a hole in the wall. In fact Stress= Force/Area is the sum total of his engineering knowledge. This is something many managers (and engineers) freely admit. Somehow knowledge is not trendy. Who wants to be a geek? Hence if a boss needs an FEA system he will choose the most expensive one on the planet, with fully comprehensive user support so that he doesn't have to be exposed on his lack of knowledge.

Well I have gone down the whole route. I learned about discontinuity analysis before I uised FEA and I was thrilled when the results matched up. However, i also noticed that FEA pointed out a few things that I hadn't thought about. This is the true value of FEA. Over the years I have seen many FEA-averse engineers make complete howlers because they used over-simplified hand calculations instead of building a computer model and looking at the results. Hence, the philosophy I have is that everyone becomes a better designer by using FEA. Ignore the naysayers, most of whom couldn't design a box, and get out there and use it. No you don't need to know all about the maths behind it, and the little you do need to know I will tell you - in plain English.

Let me be clear. To me there is no distinction between analysis and design. Analysis is an integral part of design and it should be used at the start, in the middle and at the end of the design process. Either you can do design by analysis or you shouldn't be in the design department. If you are FEA-averse then go find another job: Carry around bits of paper from office to office, attend pointless meetings, write quality specs. and stay away from our design area, where the real work is done.

As a postscript to this, I once showed the engineering manager an ANSYS contour plot of yield fronts in two different annular seal designs. I pointed at the bad design and said that the yield zone (showing a plastic hinge) was in orange. For the other design, the better one, I said that the yield zone was in red. He immediately said - "but you said that the yield zone was orange". There is no moral to this tale except that we soon parted company. I felt if I was going to work for an idiot I might as well be self-employed.

Sphere: Related Content

FEMdesigner

It's about time to introduce some feedback to the website. So I'd like anyone with comments on the site or on the use of FEMdesigner to add them to this thread. Feel free to praise or condemn. All feedback is welcome, or at least until it starts to hurt sales :)

Sphere: Related Content