Check those initial assumptions!

I bought a science magazine (Science et Vie No. 102) last month with an article about a radical new ecofuel which would apparently incorporate the benefits of a Diesel engine but without running on Diesel fuel. It was being developed by engineers at Mercedes-Benz: the DiesOtto and Opel: the CAI engine. The idea? A fuel that can be compressed to ignite and so approach the efficiency of the Diesel engine, which - the journalist reported - is caused by better mixing, but without the attendant high-temperature and high-pressure which cause high NOx emissions. The new fuel could stand the higher pressures without pre-ignition but would not be as inert as the traditional Diesel fuel which needed much higher pressures to ignite.

At this point I hope I'm not alone in spotting the obvious error in thinking. The Diesel cycle is efficient because of those high pressures and temperatures, not because of better mixing. But remember this is Mercedes talking here - they made the first Diesel engine - so what was the result? A table was produced and this is the really good bit. They showed 15% reduction in fuel consumption, 15% reduction in hydrocarbon emissions, 80% reduction in CO2 emissions, and an almost complete elimination of NOx emissions. But wait, let's revise those numbers from an engineering perspective rather than a marketing one and point out the bits that weren't mentioned. They reduced fuel use by 15% compared to SI engines but their new engine is still less efficient than CI engines. This much was mentioned in the text but not in the headline graphic. So the laws of thermodynamics are safe after all. The hydrocarbon reduction would also obviously be less than those of the Diesel engine. With the emissions figures the marketing men were even trickier. The NOx reductions were impressive except that this time they were comparing emission levels against Diesel engines, not petrol, which would likely have the same level of NOx emissions. Worse still, the stated reduction in CO2 seems to be utterly incredible unless the laws of chemistry are to be broken too: The amount of CO2 out is totally related to the amount of fuel in, so they can't be comparing that result with either engine. The only way to reduce carbon dioxide for a given amount of fuel is to increase carbon monoxide - it's poisonous cousin - and soot. I doubt that is what they did though because that would be the very definition of an inefficient engine. So the number must be a convenient error in transcription or they are capturing carbon in some other unmentioned way.

So what we are left with after a spend of several million euros is a 15% reduction in fuel use but producing a new fuel which may very well cost more than 15% more to make and buy. Actually if they limited their top speed they could have achieved the same result for zero cost. Or they could have reduced their total weight like the Loremo car designers did to achieve 150 mpg. I find it difficult to know what to make of this saga. Did these auto engineers really know nothing about the meaning of the Diesel and Otto cycles? Are they just paying lip service to fuel efficiency, trying to falsely show us that it's not really that easy. Or is it just another demonstration of the many easy ways that dumb ideas can take root. Was it poor journalism and the actual aims of these companies were not really as high as reported?

Update: On second thoughts, despite falling well short on being as efficient as a Diesel engine I have to admit that getting rid of spark plugs etc. and removing throttle losses is after all a good idea. Since ignition problems are pretty much 80% of all IC engine problems they have made the engine more reliable while retaining the acceleration of petrol/gasoline and without the NOx emissions of Diesel. Nevertheless the PR men who advised the journalist concerned crossed well over the line of truthfulness - especially about the falseness of the extent of the CO2 savings.

Sphere: Related Content

Solid Modeling Software

Updated 6th March 08 because the price of CADMAI has increased for the new version 3.

FEMdesigner works best via it's import iges command. The other model creation methods are a little out of date by now, though perhaps still ok for teaching purposes. So the next question you may ask is which solid modeler should I use? My own criterion is basically "power without the price" (as the old Atari slogan went). And the one I've been using for day to day work on prototypes is CADMAI which costs a very reasonable 499 euros which (so far) includes all upgrades and email user support. It is a very easy program to use. In fact I don't think I've needed to read the manual yet. My one regret is that the iges models produced from it don't seem to be very compatible with FEMdesigner. However very soon we will have fully integrated FEMdesigner with CADMAI so there will be no need for switching programs, the total package price will be around the same because CADMAI already has a FEM mesher. However I've discovered a better alternative called "Moment of Inspiration" or MOI for short, which has the most fantastic user interface and is even easier to use. Better still, the iges models import perfectly. Even better still it is only 138 euros which is well within anyones budget. Lastly there is the free solid modeler called Alibre Xpress, which I haven't used myself yet but one of my users reports that it's iges output works well with FEMdesigner. Of course if you have the thinkdesign software already then the Stressout plugin is clearly the way to go, since it is fully integrated into your thinkdesign environment.

Once you have your solid model tool you really won't want to do FE modeling any other way. Now assume you have tested your part in FEMdesigner and you want to alter a fillet or change a dimension then you just make the changes and re-import the model. If the changes haven't been too drastic then your old loads and restraints will still be valid for the new shape.

Sphere: Related Content

Simple is efficient

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.

Sphere: Related Content

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.

Sphere: Related Content