Wednesday, 23 April 2014

Expert Witness : Noise and Odour Nuisance from Sewage Treatment Plant

I have been fixing dates today for an appearance in court as an expert witness in respect of odour and noise nuisance caused by a old filter bed type sewage treatment plant impacting on an adjoining campsite.

That makes two court appearances I now have planned for the autumn. I hope at least one of them goes ahead, I'm looking forward to making use of the expert witness cross examination training I had earlier in the year.

Tuesday, 22 April 2014

Industrial Chemical Process Design

As part of my background reading for the upcoming book, I have just skimmed through Douglas L Erwin's "Industrial Chemical Process Design". which is basically about how to use Visual Basic to carry out tasks to support engineering design (rather than solve engineering problems - computers can't solve problems)

The book has a narrow focus: "The great majority of the process engineer's work is strictly with organic chemicals". Whilst that is clearly Mr Irwin's experience, it hasn't been mine, or that of the majority of process engineers I know.

But Erwin is a practitioner, and his approach is practical. He recognizes upfront that even the programs he supplies with the book on disc "have not been put through an exhaustive beta test", so he says that the "quest of this book, to correct the program through your good ability". He is not implying that we should forget the IChemE's Guidance on Use of Computers

So I'd recommend this book to those who wish to use VB to carry out design tasks (especially those in the petrochemical industry), but they should be aware that by the time you have written and tested your programme, other methodologies might well have given you an answer a great deal more quickly, unless the programme is to be reused many times.

I have some Excel spreadsheets that I use to do hydraulic calculations, which have a bit of VB in them. I went to all of the trouble of having them third-part validated because I knew I would be using it many hundreds of times in subsequent years. It's just not worth the trouble for a one-off task.

Monday, 21 April 2014

Detailed Design Development : Water Process Engineering

In view of all of the pilot trial and prototyping work we have had recently we have put a new page on our website advertising the service.

I'd have liked to put pictures up on there, but since all of the work is commercially sensitive, they will have to wait until pictures are in the public domain.

Thursday, 17 April 2014

Process vs Plant Design TCE Article

I submitted a new article to The Chemical Engineer magazine yesterday, which starts like this:

Chemical Engineers are often known as process engineers in professional life, but we do not design processes - we design process plants. Engineers design physical artefacts, and a process is not an object. Process plants, however, are – they are made of concrete and steel, wires and pipes, tanks and pumps. Processes happen in them.

The process designer specifies the physical sub-components of the plant and how these are to be connected and controlled in order to carry out the process safely, reliably and economically. The process is an emergent property of the specified collection and interconnection of parts.

The job of selecting and specifying the parts and their interconnections involves a great deal of professional judgement, as well as the judicious application of engineering science and mathematics. The documentation of these choices is done largely by means of drawings. Drawings allow the communication with other engineering disciplines which is necessary to optimise the plant design.

Drawings are the things which the people who will build the physical plant need to do their jobs. The plant itself is the ultimate deliverable, but the immediate deliverables are mostly drawings. This is process plant design, a rather messy, intuitive, collaborative, multi-disciplinary, multifactorial business. It involves knowledge of the needs of electrical, software and civil engineers, equipment suppliers and of those who will procure, commission and operate the plant. It also involves communication and negotiation with these other disciplines...

You'll have to get a copy of the TCE to read the rest (they hide all of their articles behind a paywall) but it covers many things I have written about on here before. There will be lots more on this in the book, chapters two and three of which also went to their publisher yesterday.

Friday, 4 April 2014

The Essential Tension in Plant Design and The Modified Scotty Principle

Things are moving on with the design projects we have on the books, and we are close to pilot plant construction in both cases. With novel designs like these I use pilot plants as both prototypes, and a source of detailed, plant-specific data to allow the final design to proceed.

There is an tension between external design consultants and product managers in client organisations, explored in this paper, but even when designer and product manager are within the same organisation, there will be a tension. Designers are usually risk-averse, and management are usually risk-tolerant (I'd give you a link to a TCE article on this a while back, but they hide all of their articles behind a paywall)

In essence, management usually want to get a product to market as soon as possible, and with the absolute minimum possible margins of safety, and highest possible profit margin. Designers don't want to design things which don't work, they have a good idea of the limits of their analytical techniques, and they know that all design relies on approximation and heuristics.

When non-designers look at our calculations and drawings, it all looks very mathematical, very sharp-edged, but these are precise calculations of approximate values, and those straight lines on the drawing might be different in ten thousand ways.

The use of computer modelling and simulation programmes as design tools can cause many to be lulled into thinking that such slick-looking output must carry some weight. It can seem as if engineering has become such a straightforward application of scientific principles and mathematical modelling that computers can do it for us. It isn't, and the IChemE's guidance on use of computers has not been reversed.

I hear that management are now asking engineers to justify adding any margins of safety to designs done substantially using modelling programmes, but that engineers are then being asked to carry out de-bottlenecking of plants which have been designed in this way.

So there will always be a tension between engineers and management. The Scotty Principle addresses this tension with respect to timescales:

Scotty Principle(n.) The defacto gold star standard for delivering products and/or services within a projected timeframe. Derived from the original Star Trek series wherein Lt. Cmdr. Montgomery 'Scotty' Scott consistently made the seemingly impossible happen just in time to save the crew of the Enterprise from disaster.

The premise is simple:

1) Calculate average required time for completion of given task.

2) Depending on importance of task, add 25-50% additional time to original estimate.

3) Report and commit to inflated time estimate with superiors, clients, etc.

4) Under optimal conditions the task is completed closer to the original time estimate vs. the inflated delivery time expected by those waiting.

(Urban Dictionary)

Margins of safety are not just about gaining a Scotty-style reputation as a miracle worker, however. When things are uncertain, designers should err on the side of caution, "underpromise and overdeliver". Occasionally you will lose out to those who are willing to gamble, but winning in that way makes them lucky, not good. Let's not trust to luck.