Engineering is sometimes a weird discipline. Any discipline is probably replete with idiosyncrasies when you’re immersed in it, but engineering is what I know, and what I’ve noticed is that it sits at this sometimes-awkward intersection between science and manufacturing/mechanics. An engineer’s role is to develop new solutions to problems, but attempting to solve most problems from scratch is both an enormous amount of work, and reveals the limits of our understanding. To do something new, therefore, engineers often do the bulk of their work by copying what’s already been done, so they can spend the bulk of their time making the incremental advancement that will make what they are developing new, an improvement on or an evolution from what’s come before. What we develop is, therefore, rarely based on first principles, but rather on reference tables, previous developments, and intuition, so that only the most sensitive components of a design are traced directly to something fundamental, like physics equations. The world is simply too complicated, most of them time, for traditional engineering approaches to support design from first principles. Yes, this hearkens back to a digression I made in a book review to complain about the lack of a parametrically optimized toilet.
What if the truism that the world is too complicated to design things from first principles is becoming less true? What if some of its continued relevance is due to assumptions about what an engineer is and what it means to do engineering? In many ways, engineers are still doing engineering that the engineers of previous generations would recognize. The tools are different, the outputs are different, but our powerful CAD software and modeling and simulation suites largely let us do better or more easily what we’ve long done. If you imagine someone sitting down and designing a thing sketching out geometry and so forth, you would not be far afield. But where does that geometry come from? What is driving it? Is the act of engineering really about simply making geometry and modifying it to work for a given application?
While searching for something completely different, I came across a company called Leap 71. On the surface, they are a design firm, offering custom engineering services to customers, and they have a portfolio bursting with elaborate CAD models for various customers and purposes. Such design firms are not unique, but the approach Leap 71 takes to design is divergent from how engineering is typically done. They are pushing something called “computational engineering,” the basic premise of which is that traditional engineering is done backwards, and modern computational technology has the capacity to enable us to do it forwards.
There is something of the obsessed-prophet-in-the-desert impression one might get from reading through some of Leap 71’s materials, not helped by being based in Abu Dhabi, but mostly arising from the conviction and absolutism of their claims. I don’t entirely buy it, but I think the basic premise has merit, and there is enough substance available from Leap 71, in the form of actual code, including open-source code for computational engineering like what they offer, that I do not dismiss them entirely. They are probably overstating their case, but there seems to be something there. One of their founders is even writing a textbook of sorts on the subject of computational engineering, Coding for Engineers, which he is releasing chapter by chapter online. I was curious enough to read through what he’s posted so far.
At its core, computational engineering is engineering from first principles. Rather than the engineer’s job being to develop geometry, in computational engineering the engineer’s job is to determine the specifications and parameters which will drive geometry and provide them to the computer. The computer then develops a suitable geometry which will satisfy the specifications and parameters. If I wanted to design, say, a hinge, in the old way I would made some sketches of existing hinges, modify them as much as necessary to work for my particular application, and then conduct testing on it to see if it meets my needs. With computational engineering, I would instead put my requirements, in the form of equations or mathematical parameters, into the program, and the program would generate a geometry to those specifications. Direct, straightforward, and it allows the engineer to focus on the high priority aspects of the engineering process, rather than spending time with basic geometry and drafting. Well, it does require a certain capacity with C.
What Coding for Engineers does not quite address is the extent to which we lack, in many cases, the ability and knowledge to generate parameters and equations to use in computational engineering to enable this kind of design from first principles. Modeling, simulation, and testing come after initial design because they usually need to inform modification to that design, modifications necessitated because we don’t have the ability to perfectly define and describe, mathematically, all aspects of the system we are attempting to engineer. Aside from needing to improve my C-based programming abilities (programming in general has never been my strongest suit – I tend to be “good enough” at coding to make whatever I’m trying to do work (eventually), but not much beyond that), I would need to significantly develop my mathematical abilities to derive and describe the relevant parameters to implement computational engineering, and I suspect I would be far from the only engineer with some knowledge gaps.
Leap 71’s founders have a vested interest in depicting computational engineering as the ultimate form of engineering that everyone should implement for everything. Lacking such interest (maybe I’d feel differently if someone wanted to pay me a lot of money to proselytize for the technology), I view computational engineering as a powerful and versatile new tool in an engineer’s toolbox. It won’t be suitable for every situation, but there is enormous potential, especially in optimizing designs which might ordinarily be clumsily executed geometrically and then refined only far enough to work. Commentators have said much about how AI tools like LLMs will partially obviate engineering jobs. I don’t see anyone using a general purpose LLM to design a rocket anytime soon, but I do see tools like PicoGK, Leap 71’s open-source computational engineering tool, becoming a significant component of engineering workflows. In that sense, the way the job is done may change, but the job won’t disappear. I probably need to read Coding for Engineers again first, but I fully intend to try out some computational engineering for myself.
IGC Publishing 