Computational Engineering 101 – Part 2: What is Computational Engineering?
What is Computational Engineering?
At the time of this writing, the state of the AEC industry is quite fragmented when it comes to the term of what comes after Building Information Modelling (BIM), as I discussed in a recent post. There are so many terms out there like “digital design”, “parametric design”, “generative design”, “computational design” and many more. There’s not clear consensus yet as to the difference between all of these things and equally, we lump many of these things with the idea it means using a specific piece of software. So now I’m coming along and using the new term “Computational Engineering”, a term coined at the Computational Collective group of BuroHappold, and making things even more confusing! In this post, we will try to define Computational Engineering as well as give a background to why it is so important.
Let’s define Computational Engineering as follows:
Computational Engineering is
the use of bespoke code
created by engineers
to facilitate the application of first-principles and deliver projects.
The two pillars of this definition are the ‘what’ and the ‘who’ of Computational Engineering:
- What? – bespoke code
- Who? – engineers
In the next post, we will get into more detail on the litmus these two items and introduce the concept of the hierarchy of skills of
- engineers
- computer scientists
- computational engineers
In this post, we will focus on why the need for Computational Engineering is so great, particularly in the design and construction of the built environment.
Starting ‘On Paper’
This series is coming from the vantage point of somebody who designs the built environment – designing objects ‘on paper’ that will one day be made in the physical world. Therefore, it’s important we first define that the Built Environment includes, but is not limited to:
- Buildings
- Cities
- Infrastructure
Basically, unless you are living ‘off the grid’ and just sleeping on the ground or in a cave, you are living in the built environment – everything that surrounds you (roads, bridges, buildings, telecom towers) did not magically appear there. Most everything you take for granted started on paper somewhere and required an engineer to assure it would work for you. The fact that buildings don’t fall down is no accident – you can thank me and other structural engineers for that (you’re welcome). The fact that you can have fresh air, plumbing, and electricity in your house also didn’t happen with pixie dust – you can thank MEP engineers for that. Next time you go to the bathroom, ask yourself “Where does this water go when I press flush” – all that water goes down the tube and to some unknown place that you don’t have to worry about all thanks to a Civil Engineer.
“…design is a purely informational operation, and its processes are defined by a specific range of cultural and media technologies.”
-Mario Carpo
The Alphabet and the Algorithm, 2011
Literally anything you see around you – from your pencil sharpener to the windows in the room you sleep in – if its man-made, it started on paper. What does it mean for something to start on paper – it existed before it existed!
Let us define generically what it means to ‘start on paper’ for an engineer. Most of the aforementioned types of engineers create ‘on paper’ objects that eventually are created in the real world by others. During this phase, engineers usually:
- Envision the Item being Designed
- Perform Calculations about the Envisioned Item
- Re-Envision the Item based on the Calculations’ Results
- Portray the Engineered Item to the World
Usually, there is a bit of a loop occurring between steps 2 and 3, and an engineer may need to iterate to find a suitable design for the item that meets all the design criteria. It is important here to remind everyone that the key difference between engineers and say artists, architects, or other similar professions is steps 2 and 3. This difference is what makes us engineers – our number crunching and its impact upon the design at hand. This isn’t to say that a bit of Computational Engineering mindset won’t be useful to my artist or architect friends – please read on guys – but in the end, they can’t be Computational Engineers because they do not have the education to perform steps 2 and 3 responsibly.
When designing, communication is a fundamental skill, for every one of these 4 steps. In the days of Brunelleschi and the master builder, that communication was largely verbal. In those days, ‘starting on paper’ meant that Brunelleschi had a vision in his head of what a basilica would look like and he’d tell the worker’s each day what to do with the building materials such that the vision started to take physical form. Sometimes, to supplement his words, he would even make physical models using turnips to describe better what he wanted.
Although we are living in a very different era, we still have fundamentally the same job – translate the ideas in our heads in a physical form (check out my other series on the history of data here). Therefore, our design really is only as good as it is communicated and perceived by others – Brunelleschi’s basilica may look amazing in his head, but, unless he’s a real poet, it’s not going to take your breath away solely by him speaking to you about it. Again, engineering is about teamwork and communication and in the design of physical objects, it is extremely important to be able to define those objects before they exist when ‘starting on paper’.
In the modern era, the ‘paper’ is digital and therefore, you communication is only as good as your digital communication skills. Computers, as will be shown, have the ability to help us communicate our designs in ways that are orders of magnitude more powerful that other, more traditional methods. It is for this reason that the combination of computation and engineering first-principles is so powerful.
New Paradigm, New Possibilities
The benefit of the Computational Engineering approach extends beyond communication. What is equally transformative about Computational Engineering is that it allows engineers to explore new areas that would otherwise be impossible. By tapping the power of the machine, the timescales of our designs go into the digital realm – meaning exponential gains over traditional, more manual tasks. This is an important change, not just for speeding up our work – remember in the 4 key steps of the engineer’s process, steps 2 and 3 are an iterative, heuristic process of solving a bespoke problem. Any engineer will tell you that this heuristics process is the fun part about their job, however, many time, the fun of these iterations are bogged down by mundane, repetitive data exercises. These exercises could include shopping for data from multiple sources, inputting data manually, or wrestling with not-so-user-friendly GUI’s of software. These obstacles slow down our design process, separating us from the task at hand – amalgamating data with a bit of engineering theory and getting insights from the output.
The figure above shows the key relationship between a Computational Engineer and the Machine. It really boils down to again the idea that the Computational Engineer has the ability to interact in a way that defines designs algorithmically, not just via manual input in off-the-shelf software – hence the fork on the ‘Input’ path of this diagram. By having the ability to codify some of the more mundane aspects of the heuristic portions of engineering design, this frees up the engineer to be able to focus on heuristic problem solving inspired by insights and less on faffing around with data manually.
In Part 3 of this series, we will explore in more detail what skills are needed by a Computational Engineer and discuss how these skills set a Computational Engineer’s approach apart from a traditional Engineer.
