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.

Monday, 29 July 2013

Internships and Employability

My summer intern from Nottingham (Jessie) is doing an excellent job.

Without a great deal of support from me, Jessie, (who has just finished her second year) has been to site alone to take and analyse effluent samples, identified and in some instances quantified problems, produced enquiries for new plant, and produced professional quality drawings of the plant in situ based on supplier data.

Last year's summer intern was also excellent. Giselle (like Jessie) was self-starting, capable of independent work, and had good judgement for when to ask for help. Giselle has gone on to be a highly sought-after engineer in her home country, as I am confident Jessie will.

However, unlike Giselle (a Master's student who already had a few years of experience) Jessie is a product of our new Year 2 Plant Design module. That she is an employable engineer with useful professional skills at the end of the second year of our degree is greatly encouraging, when so many chemical engineers graduate from UK universities without such skills.  

The skills I am looking for chime with those other small to medium sized process engineering contractors tell me that they are are looking for. BP may have the time and money to train someone for a year or two before they want them to do any useful work, but smaller outfits want people who can hit the ground running. These skills are more important to SMEs than degree classification (though both Jessie and Giselle are also academically excellent).

For any potential employers reading this, there's plenty more where these came from...

Saturday, 20 July 2013

Engineering and The Mind's Eye

3rd Century Roman Bronze Water Pump

I'm just finishing "Engineering and The Mind's Eye" by Eugene S Ferguson, a truly excellent book which crystallises a misgiving I have been developing about the teaching of engineering for some time now.

Basically, the engineering curriculum emphasises mathematics above all else, next science, then language. Visual reasoning and intuition tend not to get much of a look in. It is as if engineering were a child of science and mathematics, rather than their precursor, as illustrated by the Roman pump above. Professional engineers still make far more use in professional practice of analysis by drawing, by analogy and using experience-based intuition than they do of mathematics and science.

As Ferguson says: "the art of engineering has been pushed aside in favour of the analytical "engineering sciences" which are higher in status and easier to teach...an engineering education that ignores its rich heritage of nonverbal learning will produce graduates who are dangerously ignorant of the myriad subtle ways in which the real world differs from the mathematical world their professors teach them"

One of the many great quotations in the book: "It is usually a shock to [engineering] students to discover what a small percentage of decisions made by a designer are made on the basis of the kind of calculation he has spent so much time learning in school"

This knocks on to discussions I have been having recently about the possibility of teaching creativity, or development of a personal style by beginners, as advocated by Gibbs.

The constrained creativity of professional designers is often grounded in recombination of things they have used before, or have seen others use. For example, I have a favoured way of combining static mixers, piston-diaphragm pumps, loading and pressure relief valves in order to create a robust, economical and reliable way to dose acids and alkalis into water under control of a pH probe.

I know from multiple experiences which areas of this design need the greatest attention in order to construct a system which control pH to within 0.1 pH units. I (and other professional designers) can reliably do this based on very sketchy information about the water which is to be treated.

In no real case is there sufficient sampling data to even determine a statistically significant estimate of the values of key parameters. Furthermore, the buffering capacity of the water is a key determinant of how much acid or alkali will be required. No scientifically valid estimate of a representative range of buffering capacities is ever available to the professional designer.

The way we do this is based partly on some mathematical analysis, and partly on an old scientific paper, but the end result is based at least as much on a feel for the data and certain qualitative aspects of situation as is its on science and maths. My choice of technology is based on a personal style, grounded in repeated experience, and to some extent the preferences of those who taught me the art of engineering.  
The details of how I put the system together in space, considering that it contains strongly corrosive chemicals under pressure, requires manual interventions and maintenance from time to time, and that it carries a client expectation of a neat and professionally designed appearance has very little at all to do with science and maths.

I reviewed the book on layout we used to use at Nottingham, and was amused to note that back in the 80's people were already speculating that computer programmes would soon be laying out plants, just as there are those now who think that process design will soon be done by computer programmes.

If someone put in sufficient effort, I am sure some sort of programme could be written to lay out plant and make process design choices. In fact I know that some already have been. They are not used much by practitioners because they are inferior to the art of a real engineer (and always will be) - they are at best only as good as their programmers, who are not professional process engineers.

To give a simplified example, I have a friend who used to cut fabric for upholstered furniture. This was a very well-paid job, as the material was very expensive, and a good cutter could get a few more suites out of a roll of fabric than the cutting pattern suggested by the best computer programme. They could also do it faster, as it was piece-work. My friend went into this job straight out of school, and served an apprenticeship with experienced cutters which gave him an extraordinary visual reasoning ability in this one application.

Being a process design engineer is orders of magnitude more complex than this. One learns to do it by doing it, and in doing so, building up reliable approaches to problems, tried and tested sub-assemblies of components, a feeling for appropriate margins of error and so on.

I am now teaching our students process design in this way. I had been considering attempting to teach formal approaches to creativity, but I see now that I am already teaching real engineering creativity by teaching process design based on my professional experience. This is how I learned, so this is how I will teach.

This is harder than teaching science and maths, and the process being taught is too complex ever to be practically replaceable with software. When we allow our students to use such software, it reliably causes them to have less understanding of the process. They get very precise answers, but hidden in the black box of the software are hundreds of tiny assumptions which no-one (perhaps not even the programmer) really understands.

The key skill of the process engineer is an intuitive grasp of the ways in which a complex system fits and works together. If process design were ever to be handed over to software, process plants would be produced than no-one really understood. This would be very bad from a safety point of view. 

Academics love the precision of maths, and the certainty of pure science, but real engineers know that there is far more to reality than these disciplines can usefully express, and we can meet society's needs better with rough calculations and our mind's eye than scientists and mathematicians ever will.

Tuesday, 16 July 2013

Package Plant Problems Revisited

My summer intern is visiting the package plant at the Indian restaurant today to take samples and photos to establish what is happening there.

What is already clear is that the owner and his monkey have been attempting to improve the plant - Oh Dear! - that never goes well.

Samples were duly taken and analysed, and videos were made. The plant wasn't doing a thing, which  might have had something to do with the fact that the power to the plant had been switched off for three days.    

We are producing a proposal to solve the problems at this site once and for all.

Wednesday, 3 July 2013

Sewage and Effluent Treatment Operations Training

It looks as though I'll be going to Doha in September to give a course on Operation and Maintenance of Effluent Treatment Plants, and possibly a couple of other courses as well.

Lots of other things are up in the air, but no problem, as I have a few final things to sort out at the University before I start preparing for next year's teaching, (and get a bit of real engineering work in).