This paradigm applies in many spheres. I've just read a blog rant from Steve Yegge about how he is among the small minority who think that code bloat is a major problem. So I'm not alone! Yes it's true, people actually boast about the number of lines of code they have written. I well remember a Southampton lecturer did that very thing when he was describing his Fortran monster of an optimising fluid-structure code. I really found it difficult to decide what expression to show him as a sneer would have been too impolite. However he must have been used to people falling over with delight when he described his code bloat so my passive face made him leave shortly after. I hadn't cooed over his baby I guess. Actually, maybe he was psychic because I was thinking at the time "if you can't even see the need to optimise your code, then what the heck do you know about optimisation"?
Though all engineers are really amateurs at code churning, the professional programmers are just as lame on this point. I remember being told that programmers used to be paid per line of code written so maybe it's the old survival instinct. Anyway if you went into any programmers forum a few years ago and said you want to use mainly C rather than C++ to avoid code bloat you were treated as a complete idiot. The standard responses were roughly:
a) programmers time is much more costly than that extra RAM or processing power,
b) Do you want to go back to using a Sinclair spectrum or a Citroen 2CV instead of using modern tools,
c) Don't you realise that object orientation, data-hiding, multiple inheritance, blah, blah,... pick your buzzword.. is essential to code readability, security, reuse, sharing, blah, blah, blah.
Of course it's funny that now the same people have brought their same arguments to bear, en masse, to C#. For example, you say; "I don't want my users to have to download 60 megs of crap just to use my software, I'll stick to C++ thank you" and these same guys who had previously hurled abuse at you for daring not to drink the wondrous elixir of C++, now apparently find that C++ is a veritable pile of steaming dung compared to the new religion of C#. Fashions eh!
In the same vein I lament the death of the Atari ST which started instantaneously just like in the films (but not real life). An operating system in ROM what a great idea. Like the QL, it was doomed by the rise of the Amstrad and other clones. Another triumph of mediocrity over elegance! There was even an alternative pre-emptive multitasking operating system called SMS2, based on Sinclair's QDOS, which actually fitted in a 250k pluggable ROM cartridge - I bet it would still give most operating systems a run for their money. And why can't we even now have our operating system in ROM or RAM. I have 1 Gig of fast RAM in my pocket, the size of a postage stamp and it even plugs into the computer, but I still cannot store an operating system on it to overide Windows. Too simple an idea?
Anyway the same paradigm applies to engineering design and this time I'm paying no heed to the fashionistas. Fewer parts mean less maintenance, less chance of a fault and more chance of the thing working in the first place. When applied to the motor car this obviously means the best engine is no engine at all. Well Ok, I've never liked the conventional IC engine: It's like one big collection of kludges and bad ideas wrapped together in a needlessly complex and self-defeating system. Controversial but I'll explain what I mean in a future blog article. The rise of the battery / fuel cell cars is at last coming - 100 years late but it's coming and unbelievably I'm involved in it. More of that later too.
Friday, January 25, 2008
Simple is efficient
Friday, January 04, 2008
Designing against fatigue failure
I had a useful comment to my previous fatigue post to the effect that; regardless of how inadequate the traditional methods are, the commenter - an expert in failure analysis - had never seen failures from components which used these methods. Failures happen when no actual fatigue calculations are performed, or when over-reliance is placed on fatigue crack growth calculations. As a designer who has also used these methods extensively and not had any failures either, I can endorse that observation. And it is an important point to make. However, it begs the question, how did we get the right answer with poor methods? And that is worthy of a new post, especially since it's been over a year since the last:)
That the designer is aware that fatigue may be a problem is really half the battle. This may have been by accident - that is having had parts fail during testing - or by being better engineers in the first place. I have lamented that many design engineers actually don't have that much savvy. My experiences in industry indeed suggest that many engineers actively try to forget whatever they have learned in University and others seem to have gained a degree just by turning up, because they often don't demonstrate enough intelligence to design a box. However, and fortunately, most if not all, engineers are honest people and they are more than willing to admit their deficiencies. The ones who don't are usually pushed into management, where lying is considered a positive asset, or into paper-shuffling jobs where they cannot do any real harm. Those honest engineers will always go to more experienced or clever individuals for advice and guidance. That is indeed one of the really nice thing about engineers - they are never too proud to ask for help; because everyone is aware that being wrong can cost lives. So, getting back to the point, how do we produce good results - parts that don't break - from quite poor methods?
If you are aware that fatigue failure may be a problem, then you know that sharp discontinuities will be where it will occur, so you always use generous radii and long tapers. That insight saves many designs, especially in weaker materials like plastics. In fact, in cast parts you often have to do this anyway just to make manufacture possible. The next thing a savvy designer will do is to find out the local stresses by FE analysis. If the stresses are too high then you are immediately forced to redesign the component either by redistributing the load over a wider area or by stiffening up the area concerned. This is the second fallback. Hence, by the time you come around to doing the fatigue assessment, you have already eliminated many of the problems which would cause fatigue. Lastly, a savvy designer will always try to use steel. It isn't just that it is cheaper, it is also very forgiving of bad designs because it will plastically flow to redistribute the high stresses. Many engineering materials don't have that property so you will find a high proportion of unexpected failures occur in more exotic materials. Steel's plasticity automatically gives you a safety factor of up to 50%. Et voila, this is how so many parts fail to fail; not by the methods themselves but the savvy and experience of the lead design engineer.
The big fatigue problems usually stem from welded connections. Either there are fillet welds where the crack is inherent, or there are inclusions or porosity. The last two can be spotted by x-rays or ultrasound (and then repaired) and the first one has a well established fatigue analysis procedure originating from the UK Welding Institute and the US Welding Research Council. In these procedures every type of weld joint has been extensively tested and charts have been produced under different weld categories, steel types and heat treatment conditions. It is really a marvelous body of work which has undoubtedly saved many engineering structures from failing. If you follow these procedures you simply cannot go wrong. However, they are only for steel structures. Aluminium and it's alloys, which are being more frequently used need the same treatment but I believe they are on the case.
