Thursday, 26 December 2013

Teaching and Training Engineers: Problems and Tasks

Qatari engineers work in a group to solve practical engineering problem
I was in the Middle and Far East until Monday, training practising engineers as well as academics from the University's China and Malaysia Campuses. The picture above is of a particularly good group of course attendees in Qatar.

Most of my teaching and training features a lot of groupwork, and I have quite a number of exercises which replicate the real-life problems I have encountered in designing, commissioning, and troubleshooting plants. I have given these exercises to maybe five hundred undergraduates, postgraduates, researchers, academics, and professional engineers from many countries, and I can't help but notice a pattern in competence.

The group in the picture were very experienced ex-pat operational staff with an oil and gas background. They required no assistance from me to solve a problem which has reliably completely baffled many academics.

The pattern of competence I notice is as follows: Highly experienced practical professional engineers>Top-flight academics>Less experienced professional engineers = My best under- and post- graduate students>Run-of-the-mill academics>Engineering management>Less-able under- and post- graduate students.

Many of the most able groups of all are in my experience those like the one in the picture, made up of the ex-pats who run a lot of the plants in Gulf states. Local conditions mean that they tend not to stop working as engineers, and become hands-off managers. Similar extreme competence can be seen in the UK with many of the free-lancers often known as contractors. Selection by drop-out and decades of immersion in a pressured, practical problem-solving group environment seems to produce the required competence.

Top-flight academics (usually full professors) often do pretty well on these exercises too. Management roles in an academic setting also involve knotty problem solving, as I know from my own experience, and people do not make professor without a certain amount of smarts.

So why does "problem based learning" have such a poor track-record in academia? There are a number of reasons, but I am coming to the conclusion that much of it is to do with a misunderstanding of the nature of a "problem".

Pahl and Beitz helped me out with this, by differentiating in "A Systematic Approach" between a task and a problem. When there is a well-established methodology which produces unambiguous guidance on how to choose between design options, following such an approach is not problem-solving activity, but is merely a task.You gather the data, enter it into your computer program or design methodology, and a reasonably straightforward answer is produced - this is monkey-work, not engineering.

Much of what is done in academic engineering courses focusses on such scenarios. Sinnott and other textbooks provide turn-the-handle methods to "design" various unit operations. So-called "design projects" consist in many institutions world-wide of getting students to knit together a group of tasks of this nature,  operating a simulation program like Hysys, or grinding through pinch analyses.

In order to turn the vague messiness of real engineering problems into a collection of unambiguous tasks, a great deal of data is given, the problem is very tightly framed, and in a "successful" example, (judged by student satisfaction) it is very clear to students that they are faced with carrying out a number of the tasks which they were previously trained in. Though these are very often supposedly group exercises, they are so structured that students can readily split them into a number of standalone tasks.

When you examine students who have carried out such exercises, it becomes clear that none but the very best of them have any understanding of the overall picture - the majority are just grinding through the textbook method, or operating the program. Neither do they have any appreciation of the complexity of the sub-structures of a process plant. The method has produced neither system-level vision, nor a grasp of detailed considerations.

My exercises are very different, as all are based in examples from my professional practice. The students or trainees are given quite complex materials, the same ones I had when I had to solve the problem. They are not an academician's attempt to obfuscate a reasonably clear instruction to follow a number of standard methods.

There are no clues in the question, so they have first to figure out for themselves what the problem is. When they do, they will find that the solution requires both system level thinking, and a detailed grasp of the sub-units which the plant is constructed from. Even understanding the answers well enough to put them to some practical use is intellectually challenging.

Standard methods are of no use when there is insufficient data to apply them. There may well be some "tasks", such as checking the sizes of unit operations using heuristics, but these are mathematically trivial, and the product may be ambiguous. There is no opportunity to start thinking that engineering is a branch of applied maths, or that a computer can solve engineering problems - computers only carry out tasks. Common sense is what is needed, and a feeling for ambiguity, qualitative knowledge, multi-dimensional evaluation of options - professional judgement.

I can create more of this elusive quality in the best students than the average practising academic or manager has in a single semester of exposure to real problem-solving. I can create enough of it in anyone attending my courses that they will have a new understanding of what engineering is about.

I also note that professors, ex-pats in a very competitive market and the very best students in a top university have something in common. They are a selection within a selection - they have been selected not just for cleverness, but for personal qualities such as persistence, resourcefulness, and a willingness to work hard. They also tend to have the greatest ability to generalise from specifics - Oil and Gas sector staff who can troubleshoot a previously unseen effluent treatment plant, or students who can apply an overall design methodology to a wide range of different types of plant.

If universities were just about sifting these more able students from lesser ones, it may well be that almost any other intellectual challenge would produce the same winners. Alternatively, it might be that different aptitudes are being tested when we move away from thinking that engineering is applied maths, and start asking students to think by drawing, work with qualitative / verbal knowledge, and start to display intuition.

Either way, it is my opinion that the best way to teach engineering is to ask people to engineer something at full-scale with as much realism as possible.

Friday, 6 December 2013

Holidays?

End of term at the Uni is a way away yet, but I'm done with teaching for the year.

I'll be delivering three training courses overseas, having a couple of weeks off, and then getting stuck into the expert witness and engineering work we have on the books before term starts again.

I've also got to deliver the first chapter of the IChemE Plant Design book to the publisher in January.

We took yet another serious new enquiry today for some near-market process/product development work, as well as a call that suggests that one of those we received a few weeks back will be live early in the new year.

Lucky I never really got used to the idea of holidays...

 Water Engineering Safety Training

Sunday, 1 December 2013

Engineering Reality


Nottingham MSc Students learned last week how standing on something 5m high feels, as well as what all of those bits of equipment they learned about in lectures look like, and how they are put together.

Funny how putting them in PPE and giving them drawings to look at transforms them visually into engineers...

Friday, 22 November 2013

Now Booking for 2014

We had another enquiry for some real engineering work this week, another confidential design development job. With all of the work on the books at the moment, we will have to start this in the new year.

I have two expert witness instructions, and three proper engineering jobs on the go now. I'm delivering a couple of training courses in the Middle East at the end of the year, and going to China on University business.

I've also got to get my first book chapter in in January, so it's a busy time.Better get on with it...

Friday, 8 November 2013

Systematic Process Plant Design: state of the literature

As part of preparation for writing my plant design book, I've been reading previous attempts to set out a process plant design methodology for beginners- "Total Design" was just one of many.

Here are my comments on a few more:

Billy Vaughn Coen: "Discussion of the Method" - deep, dense and philosophical, but he does know what design is about - his koan is "all is heuristic". Worth reading.

William D Baasel: "Preliminary Chemical Engineering Plant Design" - written by an academic who did a placement in industry, who came to understand that process design is really plant design, and the importance of what is glossed over in academia. Pity it's so old, but still worth reading.

Backhurst and Harker: "Process Plant Design" - its heart is in the right place, as it understands that what engineers do differs from what uni teaches them, but the authors' academic background makes them emphasise a few areas which they themselves describe as arbitrarily chosen rather than system level design. Don't bother with it - too old, and partial.

William L Luyben: "Principles and Case Studies of Simultaneous Design" - "simultaneous design" considers both steady state economics and dynamic controllability aspects of the process, reminding me of the bar in the Blues Brothers which has both kinds of music. Design for controllability is strongly emphasised in this approach, supported by computer modelling.

The problem is that in achieving his stated aim of producing something smaller and less encyclopaedic than Perry's, he has chosen only two elements. These are without a doubt important partial design elements, but optimising only two variables will not produce an optimal solution- this is process design, not plant design, partial rather than total design, and substitutes modelling for design.

Sandler and Luckiewicz: "Practical Process Engineering, a Working Approach to Plant Design" - Old, but an academic and a practitioner get together get together to try to remedy the shortcomings of academic engineering courses. Has  great deal to say about drawing, and practical hydraulics, but very sketchy and partial indeed when it comes to unit op design - "vessels" covers everything from reactors to storage tanks. Has useful stuff about trace heating lagging and electrical power and motors. Though partial and old, it has useful stuff that none of the others cover. I'm going to expand upon and update some of this unique content in my book.

Peters, Timmerhaus and West: " Plant Design and Economics for Chemical Engineers" - As the title suggest, has a lot to say about economics - also has stuff on technical report writing and delivery. A textbook on partial design for undergraduate teaching written by academics.

Wells and Rose: " The Art of Chemical Process Design"- great title, but unfortunately written by an academic and a software company rep. who think that design starts in the lab and proceeds via simulation and modelling. At least recognises the iterative nature of design, but there is no art here. This looks to be the precursor to the misguided recent books by academics on "Process Design/ Intensification/ Synthesis" which I shall not mention further.

Van Koolen: "Design of Simple and Robust Process Plants" - Simplicity and robustness are indeed  heuristics in plant design, and has some useful summaries of the implications of ten approaches to process or process plant design. Quantifies complexity, which is an interesting and potentially fruitful approach, but then loses itself in combinations of partial approaches, and academia's pointless attempts to substitute modelling and simulation for design. Worth a cautious read.

Pahl and Beitz: "Engineering Design  A Systematic Approach" - Once again, a general text captures the essence of  design in a way that so many chemical engineering texts do not. The Google books review says that " No other book in English provides so detailed and thorough an approach to engineering and design methodology", a claim I am quite willing to believe.

It includes quite a bit of stuff on systematic techniques to supposedly enhance creativity (which I'm not that convinced about) but I'd rather emphasise something which is genuinely a useful aspect of design than things which are not.

The book suggests both explicitly and implicitly that German design teaching is far more closely aligned with professional practice than in the English-speaking world. If true, might this to be to do with the high status of the engineer in Germany? Definitely worth a read, though it's a bit old.

Thursday, 7 November 2013

Total Process Plant Design


 Pugh Elements of the PDS.jpg



















I recently read a book on product design which drew conclusions which I think apply equally to process plant design - Pugh's "Total Design".

He calls the "design" taught in universities "partial design", resulting from the necessary breaking down of a complex and holistic discipline into things which can be taught in an academic setting by non-practitioners.

He talks of the need to contextualise this necessary simplification as just a small part of the real-world total design activity, and to spell out that what is being taught is not really design itself.

The greatest problems with this approach occur when we mistake the bricks for the building - many universities unfortunately teach process design as if processes do not happen in process plants.

This may be elaborated in academia into approaches which ignore all of the real difficulties of total design in favour of an attempt to make design a sort of applied maths in which one or two elements of partial design are combined, to make what they mistakenly think is an integrated model.

In such approaches, the three most important measures of a design's quality (its cost, safety and robustness) are glossed over, in favour of optimisation of a small number of parameters in a greatly simplified model of just part of the plant.

Process plant design is an art, whose practitioners use science and maths, models and simulations, drawings and spreadsheets only to support their professional judgement. It cannot be supplanted by these things, as people are smarter than computers (and probably always will be).

Our imagination, mental imagery, intuition, analogies and metaphors, ability to negotiate and communicate with others, knowledge of custom and practice and of past disasters, personalities and experience are what designers bring to the table.

If more people in academia understood the total nature of design they would see the futility of attempts to replace skilled professional designers with technicians who punch numbers into computers. Any problem a computer can solve isn't really a problem at all - the problems of real-world design lie elsewhere.

In a related issue, on the latest TCE letters page, an article in the previous issue by a vendor of  modelling software which made claims for their software's abilities to co-optimise two unit operations comes in for incredulous criticism.

Setting aside the issue of whether it is worth modelling so precisely something which cannot be built precisely like the model, (because no real world artefact ever is) - If it is questionable whether we can optimise a simple system of a reactor and associated separation process together, it is ridiculous to think we can model a whole process well enough to substitute modelling for design.

Creating a dynamic integrated system level model of a whole process is exactly what process plant designers get paid to do, and they do it in their heads.

The research programme "towards zero prototyping" which inspires and funds that software vendor is a pipe dream. Designers are necessarily people, and any model which runs on a computer falls far short of a reliable description of the real world.

The letter to the TCE pointed out that extensive pilot plant work generated the data which was fed into the modelling software. As the pilot plant work was essential and the software was entirely optional, no progress towards zero prototyping seems to have been made.

Engineering deals with problems which it will almost certainly always be far quicker to ask an engineer to solve than to program a computer to, even if we had the data (which we can never have on a plant which hasn't yet been built), a computer smarter than a person (which we will probably never have), and a programme which codes real engineering knowledge, instead of a simplified mathematical model with no input from professional designers.

I wonder how doctors would feel if scientists and mathematicians suggested that they could produce an expert system which would exceed their competence without consulting any doctors?

This is a classic academic purist's mistake: The psychologist claims that sociology is just applied psychology, the biologist says that psychology is just applied biology, the chemist that biology is just chemistry with legs, the physicist that chemistry is just applied physics, and the mathematician that physics is just applied maths. Emergent properties are irrelevant to the theorist, but in practice they are everything.

To paraphrase XKCD: Engineering is to maths as sex is to masturbation.

Sunday, 3 November 2013

Expert Witness Water Engineering Cross Examination Training

I attended a Cross-examination for Expert Witnesses course on Friday last week with Paul Garlick QC. Great course, which confirmed that I'm unusually good at this already, but there's always more to learn.

Mr Garlick's course gave me an understanding of the strategy and structure behind the different stages of examination of evidence which will make it easier for me to prepare in depth for the two court cases which I have provisionally booked in the medium term.

Friday, 25 October 2013

Expert Witness and Engineering Design Consultancy : Confidential Appointments etc...

I got the expert witness job for which I was interviewed yesterday.

Like the proper engineering job I picked up earlier in the week, it is subject to a confidentiality agreement, so I can't say anything about either of them, other than that they are interesting.

I'm glad to have another expert witness appointment, but gladder still to be doing some engineering design consultancy. 

I wouldn't want to become someone who used to practice engineering, and now just talks about it.

On the training side, China course now solidly booked, Abu Dhabi firming up, and a course in Malaysia next summer looking very likely.

Feedback from TCE article on practitioner based teaching has been consistently good, and I'm talking to them about writing another. Must make sure to leave room to write the book.

Wednesday, 23 October 2013

Water Engineering Process Design Expert Witness and Training Consultancy

There is lots of new interest in our expert witness and process design services at the moment.

I am having a teleconference for a potential new expert witness engagement this week. Of the two current  expert witness jobs, one has settled out of court, and the other is still proceeding to set a court date. I've booked a place on a training course to hone my court appearance skills, as I have only been to court once before, most things settle before then.

On the practical engineering side, we have signed a confidentiality agreement and contract for some development work, and are meeting a new client next week to discuss supporting their design and tendering activity.

Training courses are being booked in Abu Dhabi and China for the end of the year.

The book is coming along, I expect to have no problem delivering the first chapter to Elsevier in January

Saturday, 5 October 2013

Practitioner based engineering education spreads...

I get a mention in a research paper here, based on an edited snippet of a conversation I had with a journalist at The Chemical Engineer magazine. I don't remember being that incoherent at the time....

Friday, 4 October 2013

Expert Witness: Sewage Treatment: Chartered Engineer: Court Appearance

It looks as though at least one of the two waste water engineering expert witness engagements we have on the books at present is going to make it to court around the turn of the year.

I'm quite looking forward to it. I have written quite a few expert witness reports now, but few cases of the sort on which I produce reports (usually for the specialist technology and construction court) go all the way to a hearing before a judge with expert witnesses present.

Getting more court experience will be interesting.

Friday, 27 September 2013

TCE Article: Practitioner Led Teaching

I've got an article in the latest edition of the Chemical Engineer magazine. It starts like this....
It seems to practising engineers like myself that in recent years, Chemical Engineering education in universities has had less and less to do with engineering practice.

As recently as the 1980s, Chemical Engineering courses were delivered with significant input and guidance from experienced practitioners, but the content of many UK degree programmes now consists almost exclusively of mathematics and science delivered by academic researchers, very few of whom have ever practised as an engineer.

Whilst an engineer is a competent mathematician and scientist, there is far more to an engineering education than acquiring knowledge in these areas. Engineers bring these together with professional judgement, intuitive understanding and a number of key creative skills to provide viable solutions to a certain class of real world problems.

So what has been lost in the move from practitioner-led to researcher-led engineering education?

Firstly (and arguably most damagingly), drawing skills. Engineers think and model plants using drawings, as well as mathematics and science. For example, you cannot work out the system head associated with a pump from first principles. You need to prepare a scale drawing of the system, fit the pipework where it goes (taking into consideration zoning, safety, aesthetics, planning considerations, economics and so on) and then measure the length of the resulting pipe and the number of fittings required to take it from source to destination.

That plant layout will always generate few research papers may be the reason why many departments no longer teach it at all, but engineering practice is more art than science. It is creative, but what makes it interesting is that its innovation is constrained...

Monday, 9 September 2013

An Applied Guide to Process Design - Welcome to the world of publishing!

I got my contract from Elsevier today, and was surprised to find my book has a new title (courtesy of the marketing department), but I'm as happy with "An Applied Guide to Process Design" as I was with "21st Century Plant Design".

Update: Now we are on "An Applied Guide to Process and Plant Design", which I like better, because there is no such thing as process design, only process plant design - processes happen in plants.

Thursday, 29 August 2013

21st Century Process Plant Design

I've just heard that Elsevier's board have approved my proposal to write a new textbook for the IChemE on Process Plant Design, which will be called "21st Century Plant Design".

I'm quite excited, it will be the first book I have written.

Wednesday, 28 August 2013

Training: Water and Wastewater Treatment Plant Operation and Maintenance

I've just confirmed that I'm going to Doha in a couple of weeks' time to deliver my Operation and Maintenance of Water and Wastewater Treatment Plant course for a new partner company.

It'll be nice to get away from the murky weather we've been having here of late.

Sunday, 11 August 2013

Expert Witness: Water Engineer: The Meeting of Experts:

I'm getting the reports of the other expert witnesses in the ongoing sewage treatment case next week, in preparation for the "Meeting of Experts". 

The "meeting of experts" is probably more important than a trial, (as most cases do not go to trial, and handled badly they can create grounds for legal action against an expert witness).

Expert Witnesses are no longer immune from negligence claims as we were were before a recent supreme court ruling, so they are a delicate matter.

It isn't just a question of being a technical expert - less than professional behaviour in such meetings has resulted in negligence claims being made against experts.

I've done a few "meetings of experts" now, but this will only be my second since the Jackson Reforms of April this year. 

Sunday, 4 August 2013

To Forgive Design

I've finished Petroski's "To Forgive Design", and very useful he was too in clarifying some ideas we share about the nature of design. To quote the book in summary of its content:
“It is imperative that the realistic prospect of failure be kept in the forefront of every engineer’s mind.”
The history of technology and engineering is littered with failures. When designers ignore this, and focus instead on past successes, they become complacent. Over around a thirty-year cycle they as a group forget the limitations of a novel design technique as its use becomes commonplace, and the technique is pushed beyond its limits, leading to failure.

We learn from our life and professional experience about the limitations of technology, and we retain the information as concepts, to be applied by analogy or metaphor.  A history of failures by means of specific and concrete examples is instructive to the designer, as most of the causes of failure in the real world do not exist in the mathematical world of "engineering science". These causes undercut the assumptions which the theoretician must make to allow mathematical analysis. They may be divided into hardware and software failures, but most contain aspects of both the known and unknown limits of designs and the uses to which they are put.  

Failures are mostly founded in phenomena which are known about, but not well understood - the known unknowns. Our lack of scientific understanding is reflected in the design codes and margins of safety we apply to an always incomplete mathematical model. Knowing the extent to which one is operating beyond one's knowledge should inform a decision about suitable safety margins, but complacency and pressure from management conspire to remove the margins of safety which should reflect the designer's lack of knowledge. Pressure from risk-tolerant management on risk-averse engineers is commonplace, as a recent TCE article by Mohan Karmarkar discusses.

The decision about whether and what to build is not made by engineers - cost, risk, economic, social, aesthetic and political considerations may dominate these decisions, and be fed back to designers as limitations on scope, budget, programme etc.  People get the design which they are willing to pay for.

Materials in the real world do not always meet specification, and testing protocols to reject non-compliant inputs may be compromised. Similarly, construction and commissioning is never carried out exactly as the designer intended, operation and maintenance "develops" from the approach given in the O+M manual, and the plant may well come to be used for purposes other than those for which it was designed.

In recent discussions I have had to do with plant design, a few ideas have come up. They remind me by analogy of other failures which I have witnessed in the wider world, as does the process of the growth of irrational exuberance until catastrophe ensues which Petroski describes.

These failures are referred to as "bubbles", or boom and bust cycles. Many of them match the cycle of "design bubbles" quite closely. The things which people say which tip me off as an investor that an asset class might be subject to a bubble are as follows: 

"You can't lose"- the idea of high, uninterrupted and irreversible growth in the value of anything ignores all that we have learned of the history of economic value. Things which have a high rate of growth in value are in general more risky than those with a low rate. Human nature means that high-growth assets can very rapidly become assets whose high rate of growth is based solely on a bandwagon effect. In the 17th Century, tulip bulbs were subject to this effect, an episode now referred to as "tulipmania", most famously described in Mackays "Extraordinary Popular Delusions..."

"The old rules don't apply" -  The dotcom crash came as no surprise to those who knew about other tech-stock crashes of the past, such as railway mania, and the stock market crash of 1929 (which owed much to bubbles in the prices of then-novel electrical, radio, automotive and aviation technology companies). The idea grows that these new technologies will mean that unlimited profits are available, and that consequently old models of pricing do not apply.  

But you can always lose in any game worth playing, and 21st century people are just people, whose natural inclinations are just as they always were. Greedy overconfidence is followed by disaster, followed in turn by the forgetting of the cause of disaster, and the substitution of wishful thinking for rational analysis which restarts the cycle. Unless we act in a way which does not come naturally to humans and remember the past, we repeat it.

Another idea which has come up in several forms is that design based on computer models so complex that their users cannot fully understand the provenance of their outputs is so much better than old methods that margins of safety can be cut to the bone, and management should not come back to operational staff to ask for debottlenecking and optimisation exercises.


Clever computer programmes devised by highly numerate engineering graduates turned finance wonks were in large part responsible for the depth of the most recent crash. Some of these programmes in fact attempted to apply versions of physical science and engineering formulae to financial calculations. Economics is not only not a science, it is irrational nonsense, founded in obviously false axioms of rational behaviour by humans as a mass. However, betting the world economy on substituting an equation from a completely unrelated field into an automated stock trading programme is less rational still.

As soon as people start telling me that they can use the shape of stock market price graphs to predict where they will go next, I smell cow. Similarly, anyone who hears claims that computers can do anything other than handle complex but essentially dumb tasks such as pinch analysis better than people, they should walk away. Computers are not creative, and engineering is a creative activity. Therefore computers cannot engineer.

The cleverest computer simulation in engineering is just a model based on applied maths and science which does not fully describe the thing being modelled, and the best software written has 4% errors. Having more faith in such models than the professional judgement of a group of experienced engineers is foolish.

Petroski notes a way in which the focus on the very recent past of professional researchers, and a move away from paper to electronic records made it difficult for him to fully explore the history of failure. Mohan Karmarkar's TCE article points out that histories of Chem Eng accidents on the internet seems to only go back 20 years, and the IChemE's Accident Database is now both out of date and hard to obtain. The only useful records of the limits of design seem to be in the minds of highly experienced designers, so they cannot be programmed into simulation programmes. 

I do however have sympathy with the idea that management should not come back to operational staff and ask for things on the plant to be tightened still further, not because a simulation-informed design is better, but because the idea that it is means that safety margins have already been cut in the design process.

Design starts as in the minds eye, as Ferguson notes, just as it has for thousands of years. That starting concept comes not from science or mathematics, but from the designers ingenuity, experience and ability to see analogies.

All that has changed to allow technology to progress is that the designer's mind's eye envisages concepts based on a more sophisticated state of the art, more powerful tools have been devised to allow us to winnow good options from bad, and smarter information storage devices have been produced to allow us to better learn from our past mistakes.

Engineering is in essence the same activity as it was before it was even known by that name. Unlike the professional researcher who needs to give only the most recent references, designers can go back to the ancients, as Petroski does to great effect.

Friday, 2 August 2013

From Theory to Sharp Practice: Competitive Bidding

My intern has been learning this week about a few practical issues in pricing, as a result of sending out enquiries for a package sewage treatment unit and some associated plant for what will be the final resolution of the Indian Restaurant job. 

Non-compliant bids came back from more than half of the potential suppliers. Bids were made with less than the specified capacity, for less than the required scope, and for other then the requested terms. The offer letters from the worst offenders were full of phrases which attempted to make the potential purchaser responsible for ensuring that the offer was  suitable for the duty to which they intended to put it, even though the bids were counter-offers which ignored the basis which the client asked for.

I can tell whether the alternate basis implicit in the offers is is likely to be valid, but how about the guy who owns an Indian Restaurant, who tries to buy one of these plants directly? Is it fair and reasonable to offer him something on the basis that he is an expert purchaser?

I'm not sure that it is - I'll have to see if there have been any cases where this has been tested in court. I'm involved as an Expert Witness in two cases at the moment where this might come up as an issue. Unless these suppliers always fold before getting into the courtroom, it seems likely that these terms have been the subject of a legal ruling.

As is often the case, when we had adjusted all of the bids to reflect what had been left out, what had been the cheapest bid was the second most expensive, despite being undersized. Buyer Beware!

Our bid is in with the client now, and it is almost four times the unadjusted low bid received, though around the same as the highest bid received despite including a good deal of consultancy and site time, and a number of key items missing from the cheapest bids. Let's see if the client has learned from his experiences to date that he who buys cheap, buys twice....

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).

Friday, 28 June 2013

Expert Witness: Water and Wastewater: Duty to the Court

I had a conference call today with a legal team with respect to an issue which required expertise in both water and wastewater treatment.

I am relatively unusual in having a lot of experience in both areas, due to my background in industrial effluent treatment, which borrows from both approaches, as well as my early career working in the proposals departments of design-and-build water and waste-water process contractors.

My report with respect to problems with a package plant in a restaurant application is complete, and undergoing extensive checking prior to submission to the court.

I see some other expert witnesses boast on their websites about the number of cases in which they were on the winning side, but I think that this betrays a misunderstanding of their responsibility to the court. The expert witness's job is not to twist the facts in their client's favour, but to educate the court and explain the issues such that a informed and just decision can be made.

We aim to make our reports clear, accurate, logical, readable, unbiased, and to the point. If we were going to boast about anything, it would be that.

Thursday, 27 June 2013

Teaching Soft Skills: Creativity

In a recent issue of The Chemical Engineer, the IChemE's magazine for members, Jamie Cleaver wrote an article with similar content to this one, which was brought to my attention again in comments from one of the Chartered Engineers who review our Year 3 design projects. Dr Cleaver specialises in teaching soft skills courses for engineers, so he presumably thinks that they are teachable, but personally I'm not so sure with many of them.

I'm pretty sure from personal experience than entrepreneurship isn't really teachable, and that it may well be diametrically opposed to employability, but I'm still exploring the skills which impact upon employability for Chemical and Environmental Engineers. The main problem here for anyone wishing to base such an attempt on empirical evidence is that there are no real social sciences - standards of proof in the things which are referred to by that name are pitifully low. Then there is the fact that the commonly held understanding of these subjects relies upon the popularity of books aimed at the general public - take for example "Emotional Intelligence". The idea that there might be such a thing as Emotional Intelligence, and that this might be a predictor of success in the workplace may be thought uncontentious truth by many outside psychology as a result of the best-selling book of that name, but it is just one theory of many within its field, and not widely considered the best.

Then there is the Myers-Briggs Index, which many in human resources circles think a solid way of understanding an applicant's personality and potential value to an organisation. The index was devised by an mother and daughter without relevant experience or qualifications, based on their amateur understanding of Jung's personality types, in turn based on nothing more than the intuition of Jung, an hallucinating psychotic.
   
The least contentious idea in this area is that of there being a big five personality traits : openness, conscientiousness, extraversion, agreeableness, and neuroticism. Whilst the idea that an individual has a persistent ranking in each of these things throughout life is extremely well supported (by social science standards) by empirical evidence, there are a number of problems with attempting to use even these broad measures to help us to teach employability.

1. The vast majority of variability in these traits between individuals is a combination of genetics, and early life experience, including birth order.We are teachers, not gene- or psycho- therapists.

2. Whilst one might think initially that for each of these parameters there might be a good - bad continuum, this does not follow. For example, low agreeableness amongst men is linked to high earning power, but it may be that extremes of all of these traits are more or less as bad as each other. 

3. Against the background of a relatively fixed personal set of traits, there is a common trend for agreeableness and conscientiousness to increase with time, and extraversion, neuroticism, and openness to decrease. If we trained students over a year with a view to making them more agreeable and conscientious, and had a reliable way of measuring these traits, how would we know if it was simple maturation which had caused any improvement we saw?

4. These traits for which we have some evidence are too broad to be able to be useful in either screening or training. The things other than technical ability which make a good engineer are not on the list.

5. The idea that there are limited number of sets of personality traits which make a person a good employee in general, or a good engineer in particular is without factual basis.  

So as engineers, we have a problem. In order to control something, we need a reliable measure of the thing we want to change, but there are no reliable set of parameters to measure here, and no agreement on what would constitute a good or bad set of scores.

Neither are there any reliable ways to intervene to alter any scores which we thought required such intervention. All kinds of things are done to try to do this, bit no-one has actually proved that they have improved matters relative to no intervention, or relative to a standard intervention (in teaching there is a tendency for all interventions to improve matters slightly, known as the Hawthorne effect).

Nor is it even that plausible that we can alter people's personalities to our liking when the best evidence we have suggests that almost all of the variability on the most reliable parameters is other genetic or based on early life experience. Even if we had the requisite knowledge and power to alter people's personalities to suit potential future employers, do we have the right to require students to sign up for personality surgery? To return to the issue of creativity, many extraordinarily creative people have been highly neurotic. Assuming we could train students in creativity, what if it also increased neuroticism? Would this be ethical?

But it isn't really our job to alter students personalities, and I'm glad that it isn't in our power to do so. Kathryn Eccleston's "The Dangerous Rise of Therapeutic Education"addresses this issue in a broader context, and is well worth a read. It isn't in our power to help students in this area, but we may harm them with our cack-handed attempts to do things outside our professional competence.

In the HR field things are particular complicated: HR staff cannot admit the truth (that there are no reliable means to predict someone's performance in a job) or people will start wondering why they hire HR people. Pseudo-science like the MBTI may come to their rescue, but engineers generally have little time for ill-founded nonsense.

Engineering as a profession has places for people at the extreme end of every one of the big five personality traits. There are jobs for highly creative neurotics in design, the most nitpickingly conscientious in QA, extraverted agreeable salesmen as well as introverted, disagreeeable commissioning engineers. There is no wrong personality type, and if there were, we would have to consider it a disability, and let them in too. So my job in this area is not to try to measure or change students personalities, but to help them discover for themselves what they are, and learn their own ways of coping with working with others with different personalities in an often stressful high-stakes environment where measurable outcomes are more important that harmonious relationships.

My approach is to put students in groups which I choose randomly (and strongly resist changing), and set them very challenging tasks with short and inflexible deadlines, with a close watch via peer assessment over group dynamics. Students are given an opportunity to learn for themselves in an academic setting how to work with other engineers to get a job done. This methodology simply replicates the situation many young engineers find themselves in at the start of their careers. It is my observation that the best products do not always come from the most harmonious, democratic, or well-balanced groups, and engineering is all about the product.

And as for creativity? I might try out some of the structured methods to facilitate creativity in my design courses, most likely the Adapted McMaster 5-point strategy which Jamie Cleaver highlights, which was developed by Chemical Engineers. This isn't an attempt to teach creativity. Such methodologies do not alter the properties of participants, but they might provide a formalised way of maximising the efficiently of their interaction. Unlike amateur personality surgery, this seems possible, and worth a try. If nothing else, such exercises at the start of a course can be fun, and can give nascent teams something soft to cut their teeth on. Even if they are only a bit of fun, some engineers like fun. Here's an engineer joke to prove it:

A man in a hot air balloon realized he was lost. He reduced altitude and spotted a man below. He descended a bit more and shouted, "Excuse me, can you help me? I promised a friend I would meet him half an hour ago, but I don't know where I am."

The man below replied, "You are in a hot air balloon hovering approximately 30 feet about the ground. You are at approximately 42 degrees north latitude and 83 degrees west longitude." "You must be an engineer," said the balloonist. "I am," replied the man, "but how did you know?" "Well," answered the balloonist, "everything you told me is technically correct, but I have no idea what to make of your information, and the fact is I am still lost."

The man below responded, "You must be a manager." "I am," replied the balloonist, "how did you know?" "Well," said the man, "you don't know where you are or where you are going. You made a promise which you have no idea how to keep, and you expect me to solve your problem. The fact is you are exactly in the same position you were in before we met, but now, somehow, it's my fault."

There are other supposed "soft skills" such as communication and critical thinking which don't look to me like soft skills at all, as they have a great deal of hard fact behind them in an engineering context, allowing performance in these areas to be measured, and plausibly improved. I'll save them for another post.

Tuesday, 18 June 2013

Who's an Engineer?

Recently the issue of who or what an engineer is has come up in discussions I have been having within the IChemE, the University, and in a legal case where I am an expert witness.

The discussion within the IChemE is to do with legally reserving the title "Engineer" for Chartered Engineers, as is done in other countries. If you hear me describe someone as an engineer, that it what I personally mean by the term. A fellow professional engineer, with a UK-accredited degree in Engineering, at least four years of experience working as an engineer in the design or technical supervision of full scale-engineering projects, and the letters CEng after their name.

My investigations during the legal case disclosed that British Water accredit a two day, zero-entry-qualification course which allows you to describe yourself as a "British Water accredited service engineer" for £200. But even this is not required-anyone can call themselves an engineer in the UK.

So, in the UK at present, someone like myself  recognised by the IChemE as "an engineering professional of distinction" (the requirement to be a Fellow of the Institution), and as a professional engineer by the European accrediting body covering jurisdictions where the term is protected (FEANI) has the same professional title as someone with no relevant qualifications or experience. No wonder people are confused.

Then there are the people who have degrees in engineering but never practice as engineers, (designing or providing technical supervision of full scale-engineering projects). Are they engineers? Sure - the guy who unplugs your drains is an "engineer". Can they do what I can do, do they know what I know? - mostly not.

A UK degree in chemical engineering meets "the academic requirement for the formation of a chartered chemical engineer". That doesn't make you an engineer - that make you someone who can be made into an engineer by other engineers. The IChemE think that the minimum period of practice as an engineer (based on a definition functionally identical to mine above), required to understand what the academic foundation means in context, and have a basic level of understanding of professional practice is four years.

It's the difference between someone with a law degree and a barrister, or someone with a medical degree and a doctor, though the Engineer's minimum period of professional training is longer than a barrister's pupillage, and a doctor's internship put together. I completed this process eighteen years ago, and have practiced continuously as an engineer ever since. Who's an Engineer? I am.

Who else is an "engineer"? It depends what you mean by "engineer". Here is how professional engineers around the world see the hierarchy (though we are often too polite to point it out unless pushed):

"Engineer" =  CEng/ PE/ EUR ING = Accredited Master's degree and 4 years + of specified professional experience - governed by the Washington Accord

"Engineering Technologist" = IEng = Apprenticeship / Bachelor's degree + specified experience - governed by the Sydney Accord

"Engineering Technician" = EngTech = Apprenticeship / Bachelor's degree/diploma + specified experience - governed by the Dublin Accord

"Monkey" = everyone else, in an engineering context

So what about the people who teach and research in HE Engineering departments? They are members of a different profession, that of "academic". I am also a member of this profession, so I know as a member of both that they have very little to do with one another, though there is a polite fiction that all of those who work in academic engineering departments can consider themselves engineers.

This is not to say that there are no Engineers in Universities - just as I am an Engineer who is also an Associate Professor, there are some academics who are engineers, and even a few who are Engineers. Note however that just as the University refuses to use my professional titles in the academic setting, academic titles do not map onto the hierarchy above. A "Professor of Engineering" may be a "Monkey" from a Professional Engineer's point of view - though again it would be impolite to say so.

Friday, 14 June 2013

Enquiries - Busy Summer Forecast

We have lots of new enquiries-for training work in the UK and Middle East, for expert witness work, and increasing numbers of jobs as an international consultant, overseeing engineering projects in India. We haven't lost a bid so far this year, so the HAZOP job and so on are still in play.

We are finishing up a CPR Part 35 compliant expert witness report, which is an opportunity to practice my recent training in producing such reports to the highest standards.

The Indian industrial effluent job is also being wrapped up, with a consideration of vacuum evaporation/distillation technology for disposal of RO concentrates.

Other than that I'm just doing all of the little jobs which  have to be set aside during teaching term-time. Nice to get them off my desk.

Saturday, 8 June 2013

Expert Witness Training

I attended a CPD course on writing Part 35 compliant expert witness reports yesterday, which was helpful with respect to all sorts of easy-to-overlook details. I shall be incorporating its insights into the report I'm writing at the moment.

Quite a few other enquiries on the go, another expert witness proposal in the UK, a HAZOP in Saudi, training in Qatar, and oversight of design, construction and commissioning in India,  as well as a few other bits and bobs.

University teaching has finished, other than some post-grad work, and I'm going to drop my teaching hours next term to allow time for me to do more proper engineering work via Expertise Limited.  

Tuesday, 4 June 2013

Expert Witness: Part 35 Report: Waste Water Treatment

I drafted the part 35 report for the latest expert witness job yesterday and today. It's to do with package sewage treatment plants and reedbeds for waste-water containing fats,oils and greases.

It's the usual story - poor specification, poor design, poor installation, poor maintenance, and poor operation all feature. 

I'll put it on my package plant problems page when the dust has settled.

Thursday, 30 May 2013

HAZOP Chairman / HAZOP Training

A hazard and operability study or HAZOP is a "what-if"procedure for checking the safety of a proposed design prior to commencing construction.

I have done a good amount of HAZOP training and teaching, as well as some HAZOP chairman work, and I have received enquiries this week for both HAZOP training and HAZOP chairman roles in the Gulf region in Autumn 2013.

Tuesday, 14 May 2013

Expert Witness: New Instruction: Package Plant

New instruction today regarding an expert witness report for a packaged effluent treatment plant installed at a pub, combining several things which I have seen many times before:

1. Foaming
2. Fats, oils and grease
3. Inept installation
4. Inept specification
5. Monkeys passing themselves off as engineers

The level of ineptitude at this site is however quite special...

Friday, 10 May 2013

Expert Witness : Joint Statement

The joint statement I have been preparing with the water plc's expert under CPR Part 35 rules goes into the court today.

It has been interesting to note the apparent difference between the logic of engineering and the sort of things which a court can find pertinent. 

The essence of the complaint is to do with whether a plant is causing odour, noise and fly nuisance, and whether any such nuisance has occurred as the result of  poor design or operation of the plant.

To an engineer, what matters is the propensity of the particular technology on the site to be prone to such nuisances, how well the plant was operated, and how well it was designed.

To the court, it seems that there are other considerations, which an engineer might classify more as rhetorical than logical.

Tuesday, 7 May 2013

Package Plants Again...

Just got off the 'phone for a representative of the management company who have taken over the plant under a playground we modified and recommissioned a while back. Still running well, according to his account. We're going to offer them ongoing support.

We have done quite a few of these upgrade/ recommissioning jobs now on undersized/ badly specified package sewage treatment plants, and they are all still working well. As far as I know, we are the only ones offering this service.

We've also had an expert witness enquiry to do with package plant problems, as is so often the case specified and installed by monkeys who went bust not long after taking the client's money.

If you want to save yourself money, involve an expert at specification stage. Salesmen for package plant companies are not generally speaking any more professional engineers than the guy on the yard at Jewsons. You should not assume that their opinion will count as professional advice in court, and you will in any case find that they aren't actually guaranteeing anything. Neither should you assume that they will still be in business to deliver on any promises they might make.

Friday, 26 April 2013

Design Practice

I'm looking as usual at design teaching at the University, and planning changes to make our design projects more realistic. We are coming to the end of the year 2 plant design course, and the students are making great progress.

We are starting to ask them to undertake design projects as part of the Easter field course now, and the improvement in group-working and design ability as a result of the new design course was obvious to all.

This weeks I'm also looking at what is being done at another university as part of their IChemE accreditation, and I've spoken to someone who thinks that the process control taught as part of Chemical Engineering courses is too theoretical.

The harder I look, the more obvious it is that most practising engineers know exactly what is wrong with academic courses, but the information is not finding its way back, or not being translated into changes to courses, for a number of reasons.

An interesting bit of expert witness works continues alongside teaching, and we are now looking to fill the order book for the University summer break, starting only a few weeks away.

Friday, 12 April 2013

Expert Witness

I'm just finishing an urgent expert witness report regarding a number of nuisances allegedly arising from municipal sewage treatment plant operations.

High-intensity stuff - you plough through a couple of banker's boxes of files, looking for the nuggets of fact buried in the mountains of opinion, bluster, hysteria, accusations and counter-accusations, then you find a few reasonably clear things on which you can base a professional opinion, and from them construct an argument as to the balance of probability as to what is/has been happening.

All of this happens under the constraints of CPR Part 35: 

(1) It is the duty of experts to help the court on matters within their expertise.

(2) This duty overrides any obligation to the person from whom experts have received instructions or by whom they are paid.

So clients might possibly pay someone for the privilege of destroying their argument. That doesn't look to be happening in this case, though I am not finding myself in support of all of it either.

Wednesday, 3 April 2013

Design Philosophies

I was discussing academic design philosophies with a colleague from the Malaysia campus last night. Apparently, academics interested in the area have proposed a number of different new approaches to process design. Such experimental philosophies are popular in academic circles, and also in a certain type of consultancy (more akin to a management consultancy than an engineering consultancy) engaged only at the most loose-weave conceptual phase of design.These philosophies are(my colleague agreed) more proposals for how process design "should" be done than a reflection of how it is done - they are normative, rather than descriptive as they say in the humanities.

But I talk to practical process design engineers all over the world, and how it is done varies surprisingly little- why is this? I think it is for the same reason as all animals which live in similar ecological niches look somewhat similar-convergent evolution. I was not taught a design methodology/philosophy - I evolved one.

My initial experience was in a university spinout, where I saw the pitfalls of attempts to base process design on research output and the first principles academic engineering I learned in university first hand.

Next I went to work for process contractors, where I spent five years producing proposals for competitively bid design and build contracts. At first I was too cautious, and won nothing,then I swung a little too far the other way, and nearly won a contract or two I was lucky not to bring in.Eventually I learned how to win tenders consistently through competitive design. I learned where I needed to place my attention and effort to get a working design for the right price.

Then I went to work for consultants and operating companies, and learned the mistakes they make in specifying plant, and their lack of knowledge of what works and what does not in design. I knew from previous experience that contractors do not like to embarrass clients by pointing out that their designs are not going to work, they just quietly adjust the design so that it will work and keep it to themselves. Operating companies on the other hand have a lot of information about how well designs work in practice which contractors do not have. There are longer term implications of design choices which are unknown to designers in contracting companies.

I then gained a fair bit of installation and commissioning experience, and found another layer of design requirements, and after that I did a lot of process troubleshooting, de-bottlenecking, and resource efficiency studies across a wide range of industries. I could now see the big picture - all of the mistakes process designers make again and again, often because of a narrowness of experience and vision.

Most people who work for consultancies have no real experience of process design, and they receive little genuine feedback on the effect of the choices they make in conceptual designs. They are not in a position to learn from their mistakes-they cannot evolve into process designers.

Proposals engineers in contracting companies only care about winning the work. It is a stressful job, which few do long-term. They may learn how to win, as I did, but their designs are frequently sub-optimal, due to their frequent lack of experience, pressured working environment, and the over-emphasis on cost reductions.

The build team may fix some of their errors, but may well not feed back to them how to do it right next time. Proposals engineers can evolve into competitive designers, and indeed must if they are to survive. They have to start winning quite quickly if they want to keep their jobs.

Only after seeing the errors and elegance of the hundreds of  designs by others I have now been employed to fix, and provided long-term process support for plants I have designed do I think I really understand process design. Robustness, Safety and Cost should be the process designer's watchwords.

The common methodologies of the world's process designers are fitted to their environments. Operating companies, contractors and consultants each see different parts of the puzzle, and have different possibilities for feedback. Communication between them is poor for a number of reasons. Information from all three sources must be combined to truly understand process design, but if one must be chosen, contracting organisations are where the maximum information of how to design plants which work is concentrated.

Essentially none of this knowledge is available to academia. Operating companies and contracting companies have their design and operating manuals, but these are jealously guarded secrets. The consultants which academia engages with know nothing useful about how to design plants which work.If they need to know the financial or practical implications of something they are thinking of doing, they call a contractor and ask a favour.The contractor doesn't tell them how they worked it out.

So academic design practice drifts ever further from professional design practice. Expensive mathematical modelling at the conceptual stage, using software with cheap academic licences which is prohibitively expensive and unfit for purpose on a commercial basis, designs based on first principles or primary scientific research, groundless theorising, the list is endless.

Philosophy is about what might be true, so a design philosophy is about what might work, but no-one is going to give you £100M to build a plant which might work.

There is nothing wrong in an academic setting with telling students about your vision for alternative futures, but when I did my teaching qualification, I had repeatedly to stop lecturers and ask if they were telling me about how things were, or how they ought to be. In the humanities department, they seemed to have little interest in how things were. In fact they repeatedly told me that there was no such thing as how things are. All very clever in its way, but there is no postmodern school of engineering.

In engineering, practitioners and academics agree that there is a difference between "is" and "ought". We need the descriptive far more than the normative.We need to teach our students how design IS done.


All very interesting...













A week in China last week, where they could not be more in need of training and consultancy regarding environmental issues. I'm expecting some more work from China...

Just finished delivering my long-running industrial effluent and sludge treatment course in Malaysia, to excellent delegate feedback. It looks like here will be orders for the more advanced version of the course to the same audience.

Back in the UK and elsewhere, follow-on work is in the pipeline for an odour problem at a domestic installation, and some treatability labwork and consultancy in industrial effluent treatment for a pesticides manufacturer is also coming in in the near future.

Friday, 22 March 2013

Another quality course...

Break for Easter at the UK campus, though I will be spending a fair bit of mine at the China and Malaysia campuses.

I've just delivered a course on open channel hydraulics to an expert audience from a UK process contractor to very good feedback, and I had a call on the way back to deliver a new course quite locally.

Malaysia course is now firmly booked, so there will be time for a mix of academic training and teaching and interaction with working engineers whilst I'm over there.

I'm glad I've got a few overseas engineering contracts on the books, I'd hate to only do teaching and training, and gradually lose touch with my profession. I do love design and troubleshooting, it's like being paid to do crossword puzzles....

Friday, 15 March 2013

Winding Up...

Coming to the end of term, ready for trips to China and Malaysia. Malaysian training course booked up, with the same sort of Oil and Gas operations audience as I'm used to in the Gulf. There may however be a problem with the course provider, which we are looking into.

First year students were set a design challenge this week, (which many made a good job of) designing the grande cascade part of the water feature at Alnwick Castle which I did the process and hydraulic design of for Invent back in 2000. As always in teaching, it is the misunderstandings and misconceptions in students assessed work which is of greatest interest. I will get a chance to correct these when I teach them design again next year....

Saturday, 9 March 2013

Reboot

An industrial effluent treatment job in India which has been dormant for a while has rebooted, so I'm looking into evaporative technologies for them.

I hosted the IChemE Safety road-show yesterday, which went down quite well with the Year 2 students. They used a slightly new approach to HAZOP, which I will borrow in future - it's good to keep current with best practice.

We have a few new training enquiries, including our first from Hong Kong ( for our industrial water and effluent treatment course).

I'm spending today producing training materials for my forthcoming open channel hydraulics course, which I'm pretty pleased with. I'm explaining things which a lot of people find hard to grasp such as hydraulic jumps, and giving them practical, simple ways of solving some technically knotty problems, such as the interactions between a weir, a penstock and a flume used to passively set stormwater overflows in a sewage works.

Tuesday, 5 March 2013

Open Channel Hydraulics

I've been writing a manual on open channel hydraulics today for my forthcoming course with a UK contracting company. That's quite a small part of the work, as devising the exercises that make a course interesting for attendees is a lot more involved than writing the manual.

All arrangements are in place for visits to China and Malaysia over Easter, finalising discussions on what I'm going to cover in my teaching and training. Chinese visa form even trickier than the Saudi one...

Friday, 22 February 2013