Is Chemical Engineering Applied Maths?

So, we've been having a lively discussion about what chemical engineering is, and job prospects for new grads here, and a few things have come out of it which can't be addressed in a comments box.

I'll start with the suggestion that the foundation of chemical engineering is mathematics. My initial reply was this was "clearly not correct either historically or experientially". I have expanded upon that over on the original thread to some extent, but let me unpack it a bit here.

First, a bit of history. It is undisputed in the UK that the teaching of chemical engineering started in Manchester with Davis (a practitioner) , and that calling the thing he was doing chemical engineering came from that. These lectures included the key concepts of chemical engineering as we know it today, such as the "unit operation". The academics were very sniffy about his lectures, and considered their content to be "commonplace know-how".

The idea of a unit operation is not mathematical, and Davis was not a mathematician, though like all engineers, he could do a sum when he needed to. So the idea that chemical engineering is founded in mathematics in the sense that it grew out of it is clearly incorrect. Chemical engineering grew out of mechanical engineers with a smattering of chemistry and chemists with a smattering of engineering knowledge trying to make large quantities of chemicals. Davis was an empiricist, not a theorist, and he came up with some useful concepts to turn chemical industry from a fumbling, dangerous trial and error process into something a bit more predictable and safe.

Then consider your own experience upon graduating, and becoming a tyro engineer. Almost universally, we find that we have not been taught the most basic things about what engineers do all day, and that the things we do know are of little use. Many young graduates write to me and ask how they can get a real engineer's job. They don't think that they have one because they spend all day talking to people, and no-one ever asks them to do a Laplace transform. It's as if the stuff they learned in university is almost entirely useless, but surely that can't be true can it?

James Trevelyan talks about this phenomenon in his excellent book "The Making of An Expert Engineer". I'd recommend that anyone interested in this subject reads it (as well as mine of course) . I tell these young engineers that the only place the job they were expecting exists is in academia. Academia trained them to be academics. Engineers will need to make them into engineers, and that people stuff they are doing all day is a lot of what engineering is about. Meetings, office politics, negotiations, persuasion, etc.

James has persuaded me that the higher mathematics which all engineering courses contain might have a purpose, as a lingua franca between engineering disciplines. However, the idea that it all belongs in the syllabus is disputed by people who can do far harder sums that I am ever called upon to do in their sleep, such as Myke King. They tell me that some of it is there only because it's been there so long no-one knows why it's there any more. Its original application is long obsolete. But anyway, the vast majority of chemical engineers never even use calculus again after graduating.

I'm pretty lucky in that I'm a process design consultant, so I really do get to design a lot of things, and review the designs of others. I have a job that involves doing a lot of sums, (or getting Excel to do them for me) unlike the vast majority of chemical engineers. I have no difficulty countering the idea that we need to have a firm grasp of higher mathematics to spot problems with the process designs which we and other produce, as this is the basis of our designs.

My argument is that to the extent that our designs are based in such maths we tend not to understand them. It produces too complex a model. Anyone who has seen the nonsensical product of Hysys driven by incredibly bright but entirely inexperienced students will see that the problem is never in the maths. The problem is mostly in the assumptions and other inputs made, and an unavoidable lack of understanding of a very complex bit of modelling software that is scarcely fully understood by any of its large team of authors.

When I check the design of others, the first thing I check are the outputs. Do they seem sensible? I use rules of thumb based calculations you can pretty much do in your head, as well as olfactoritmetic : "does it smell right?, and whether it conforms to the calculation methods in relevant codes and standards. Then I look at the assumptions and inputs used. I rarely have to check the arithmetic, though when I do, there are often errors in Excel spreadsheets, often caused by trying to be too clever with functions the user doesn't really understand, or worse yet, VBA. Don't play at being a coder, kid!

Like other expert engineers, what I bring to the task is experience. I have a good idea of what the answer should look like. I know which regulatory guidance, codes and standards should be considered, and which complied with. I know the limitations on applicability of design heuristics, and their pitfalls for the inexperienced. I know where to look for the things beginners forget to consider.

It's like that old joke about the guy who taps a machine which has inexplicably stopped with a hammer, and sends in a bill for $20,000 for five minutes of work. Management balk at this and ask for an itemised bill, and receive the following: Tapping with a hammer: $5 : Knowing where to tap: $19,995. Our practical profession was and is founded in know-how, not maths. It is not however commonplace know-how, contrary to what academics would have us think, and despite the massive oversupply of graduates they are producing.