After setting the stage in the first two installments of this series of article, let’s dive a bit deeper.
Editor’s note: Lin Kayser has written a series of stories introducing the new concept of Computational Engineering being developed by his new company, Leap71. This is a six-part series, with links below to all parts as they are published:
Fundamentals of Computational Engineering: Prologue
Fundamentals of Computational Engineering: Part 1 — A Bit of History
Fundamentals of Computational Engineering: Part 2 — The Technology
Fundamentals of Computational Engineering: Part 3 — Voxels to the Rescue
Fundamentals of Computational Engineering: Part 4 Implicits
Fundamentals of Computational Engineering: Part 5 — All You Need is a Few Functions
I will make an attempt at defining the still nascent field of Computational Engineering.
Wikipedia can help a little:
Computational Engineering is an emerging discipline that deals with the development and application of computational models for engineering, known as Computational Engineering Models or CEM.
[…]
In Computational Engineering the engineer encodes their knowledge using logical structuring. The result is an algorithm, the Computational Engineering Model, that can produce many different variants of engineering designs, based on varied input requirements. The results can then be analyzed through additional mathematical models to create algorithmic feedback loops. [Source Wikipedia]
I would also argue, that the output of a Computational Engineering Model (CEM), while frequently still a traditional 3D geometry, increasingly will be a direct input to a manufacturing process, such as a CNC path, or a sliced file, ready to be sent to the 3D Printer. So it’s a way to go from abstract requirements to the production of the object.
Let’s dive into the various tiers of the technology stack for Computational Engineering:
- A universal Computational Engineering Model (CEM)
- A specialized CEM for a narrow field
- A generalized CEM that is used for many use cases
- A shape kernel for that abstracts the generation of complex computational geometry
- A compact, robust and fast geometry engine with a small instruction set
The 4 (5) Tiers of the Computational Engineering Technology Stack
Let’s start with a fictional top tier that doesn’t exist yet: A universal Computational Engineering Model: A large software model, that allows you to high-level-specify the properties of a physical object without worrying about any engineering details. Such an interface could be used by non-engineers, it could be interacted with through a natural language model, and it would be very powerful. Think J.A.R.V.I.S.
We are years away from a model that is all-encompassing. But there is a clear path towards it, based on the software paradigm, where more and more building blocks lead to increasingly powerful features.
So, enough fiction, let’s start one level down, where we are today.
Tier 4: A specialized Computational Engineering Model (CEM)
A specialized Computational Engineering Model, such as LEAP 71’s RP/CEM for rocket propulsion, is a sophisticated set of algorithms, an integrated software stack, that takes high-level specifications in a relatively narrow field (bell nozzle rocket combustion chambers), and produces a manufacturable result, all with little user interaction. It uses the base tiers of the software stack to create sophisticated geometries automatically. Through parameter modifications, feedback from numerical simulation or practical tests, a specialized CEM can produce objects in a vast parameter space, honing in on the desired capabilities.
The Computational Engineer refines the algorithms through direct modifications of the code, eliminating more and more edge cases that produce incorrect results.
A CEM essentially captures as much engineering knowledge, physical formulas, rules of thumb, etc. as possible, and benefits from contributions that engineers make to the code base, producing better and better outputs over time. If implemented thoroughly, a CEM can capture the entire body of knowledge in a field, and make it usable to a wide group of engineers, who are now free to innovate on top.
This is the power of software. Once something is implemented as algorithm, nobody needs to revisit it, we all benefit, and everyone always uses the best version. My partner Josefine Lissner will talk in the later parts of this article series, how you build and apply a CEM.
Tier 3: A Generalized Computational Engineering Model
In engineering, there are a lot of things that are used everywhere. Routing of pipes, generating manifolds, designing aerodynamic or hydrodynamic surfaces — this is the fundamental core of engineering knowledge, and regardless of what you do, you will utilize parts of that toolbox somewhere in your designs.
It makes sense, to keep these in a generalized CEM, ideally open-sourced, so that everyone, everywhere can just access it. A generalized computational model for engineering will increasingly eliminate tedious repetitive basic work, and provide a vast code library for engineers to build their more specialized solutions on.
Tier 2: A Universal Way of Creating Shapes Used in Engineering
Now we are moving away from the world of engineering and diving more into computational geometry. In our current CAD paradigm, engineers are constantly creating geometric shapes by hand. Tier 2 abstracts the high-level geometry generation, so that the Computational Engineer doesn’t have to worry about the details of building shapes. They work on a higher level with the focus on the engineering of the object, by using generalized shape generators.
Tier 1: A Computational Geometry Kernel
This is the lowest level and the foundation of everything. A computational geometry kernel needs to be robust and fast. These are the most important properties. When I started Hyperganic in 2015, we thought of licensing a traditional CAD kernel, and building our technology on top. Unfortunately CAD kernels are huge pieces of software, which use complex math to describe relatively simple objects. They were not built for a world of algorithms which generate incredibly complex geometries without human interaction.
Since, generally, large software libraries tends to be less robust than simple software, today, I would add another important requirement to the list: the geometry kernel must have small footprint and only provide a reduced set of functionality, which produces verifiable results under all circumstances.
A geometry kernel for Computational Engineering needs to be compact, robust, and fast.
Wait! I Need to Code?
Let’s finish off this article by stating the obvious: As a Computational Engineer you will not visually draw objects on screen, neither will you typically navigate the spaghetti wires of “nodes”. You will write and modify computer code, which in turn produces a visual object. Increasingly this computer code will at least partially be written by Large Language Models (made famous by ChatGPT). But let us make no mistake about it, if you are an engineer and don’t know how to code, it’s a good idea to learn it now.
The good news: it’s not hard.
I started to code when I was 8 years old, and I was not a child prodigy. Once you get going, it is surprisingly simple. Engineers already think algorithmically, so why not translate these thoughts into code? If you stick with us for the duration of this series, you will have learnt a great deal about it, and will never go back.
Editor’s note: Lin Kayser has written a series of stories introducing the new concept of Computational Engineering being developed by his new company, Leap71. This is a six-part series, with links below to all parts as they are published:
Fundamentals of Computational Engineering: Prologue
Fundamentals of Computational Engineering: Part 1 — A Bit of History
Fundamentals of Computational Engineering: Part 2 — The Technology
Fundamentals of Computational Engineering: Part 3 — Voxels to the Rescue
Fundamentals of Computational Engineering: Part 4 Implicits
Fundamentals of Computational Engineering: Part 5 — All You Need is a Few Functions
Via Leap71
