Tuesday, 30 July 2013

Rationality and Rationalisation

I'm reading Petroski's "To Forgive Design" at the moment. I'm sure I'll do a review of this and its predecessor "To Engineer is Human" at some point, but one carefully chosen word caught my attention this morning.

In a chapter on how the author moved from being an academic theorist to being far more driven by empiricism in his attempt to understand what professional engineers do, he describes a University course in engineering mechanics. He refers to its content as a "rationalisation" using mathematics to arrive at a justification of an approximation of engineering practice.

Rationalisation is not rationality, rather it is a making of plausible excuses, often used in the context of logical-sounding reasons given for emotionally-driven decisions. Rationalisation is not quite the same as intellectualisation, another closely related psychological defence which might be the most accurate description of the phenomenon he describes.

Why would we need a psychological defence? - because the real world of stuff is less well understood, less predictable, and scarier than the comfort - blanket precision of science and mathematics, else Petroski's initial book on engineering failure would have been a short one with no sequel.

Heinlein, the science fiction writer (and graduate engineer) noted that "Man is not a rational animal, he is a rationalising animal". Minds untrained in rational analysis make decisions on the basis of their emotional responses, then they justify them post-hoc with excuses whose sophistication reflects their degree of education.     

Engineering practice is (as Petroski explains) founded in the failures of the past. A knowledge of what works and what does not is gained during our post-university years which in the professional engineer comes to take a far more central role in their decision making process than the science and mathematics comprising most engineering courses.

Codes of practice, specifications, engineering standards of design, construction, operation, maintenance and so on embody this knowledge, which is also transmitted by the engineer's habit when gathered in groups to discuss failures, ideally ones they have seen at first hand. This may all seem a bit fluffy to "engineering scientists", but these anecdotes and their codified written versions carry information about how to avoid failure in a world less well understood than we would like to think.   

An example from my personal experience - I have carried out hydraulic design (the practical aspect of fluid mechanics) on many different full-scale plants, as well as some other things. In carrying out the hydraulic design of the Alnwick Castle water features, I spent eight months of fifty-hour weeks carrying out hydraulic calculations for very complicated three-dimensional shapes of weirs and channels. I also had to figure out how to produce certain aesthetic effects using jets, plumes, and miscellaneous other desired appearances of water imagined by an architect with little thought of how they might be made real and reliable.   

I got this job because the more theoretically-minded engineer who usually did such design work within the contracting company had proclaimed it impossible. For a view of the impossible in action see here.

Many university courses in fluid mechanics may accurately be described as rationalisation. They use mathematics to seemingly create a rock-solid rational basis for hydraulic calculations. The same authorities are used everywhere as far as I know: Newton, Bernoulli, Reynolds, Froude, Navier, Stokes - all were mathematicians, not engineers. Fluid mechanics is applied maths, rather than engineering.

Well taught, you might almost miss the bit where they admit that no mathematical analysis of even the simplest example, the loss of pressure with distance due to friction along a level, parallel sided, circular pipe running full with a steady flow of water is possible without recourse to an empirically determined relationship and its accompanying fiddle factor, which has to be looked up on a chart produced by empirical experiments.

So the maths which we teach students up to that point are really almost window-dressing. The requirement to use the Darcy-Weisbach equation and accompanying Moody Chart (to name them) tells us that there is still more to the mechanics of moving water in a real setting than we can presently determine from theory, and ultimately we have to extrapolate from experimental data.

We could teach students how to do this in practice without teaching them the maths we do, as they are in fact nothing to do with how hydraulic calculations are done by engineers. It should be noted at this point that Darcy, Weisbach and Moody were all engineers.

I really do use the Darcy-Weisbach equation to calculate the frictional pressure drop of water flowing in a pipe. I do not however use the Moody Chart as more or less all students are taught to do, because life is too short, it is easy to misread a chart, and I cannot automate the calculation using a spreadsheet programme. I use an iterative method based on the Colebrook-White approximation, an atheoretical equation generated entirely on the basis of matching experimental data, albeit by scientists.

Water and hydraulic engineering has existed since maybe the sixth century BC. Water pumps, hydraulic drives, control valves, and so on were being put to practical use for millennia before Bernoulli or the other mathematicians name-checked in the rationalisers' fluid mechanics course were born. As Henderson remarked in a related context " before 1850 the steam engine did more for science than science did for the steam engine."

Practical hydraulics is more black art than science above quite a low threshold of complexity. We can get workable approximate pressure drop calculations using the method I have given for the very simple case detailed. This case is however more or less trivial, even if one is only designing a water feature. To do more complex things without recourse to more or less unlimited resources, one needs to have the humility to realise that we just don't understand fluid dynamics at all in any practically useful way. We can generate rightish answers, but we don't really understand them. As engineers don't need to know about as much as they need to know how, this isn't really a problem.

At Alnwick, I used techniques from river engineering to predict the free water surface in variable area sloping channels, and generated my own experimental data in a large scale model to predict the aesthetic appearance at given flowrates for nozzles, weirs and so on. I added margins of safety, controllability and turndown capacity to pumps, because I know that I don't know and I plan accordingly.

As the public were not to be fenced out of the feature it is designed to comply with guidelines used in swimming pool design.  As is commonplace in real world design, the necessary negotiations between disciplines to obtain an optimal solution were more significant in the case of Alnwick's design choices than maths or sciences.

I had to ask the architect to reduce the complexity of the shape of the weirs to satisfy myself that we would obtain even flow across their full width at the expected range of flows. The feature had to be made mostly of concrete (shaped and coloured to look like stone) to match the desired complexities of its shape, and the required resistance to erosion of its weirs. In order to obtain the desired effects, it was necessary to design two or three independent but adjacent features to look like one.

And then there was the fact that the Duchess was herself head of the design team, and my employers were owned by Enron, run by people who apparently had no idea who to talk to a Duchess, amongst other failings. If you are ever watching a telly programme that implies that Charlie Dimmock or someone else was responsible for the design of the Grand Cascade, and there is no mention of my input, the above facts may have something to do with that. That, and my having a great face for radio.

No comments: