In our first blog post we want to demystify the topic of optimisation in engineering.What is it? Why would we want to use it? What are the challenges for practicing engineers today? If you wanted to implement design optimisation, where should you start? What are the mistakes to avoid?
Read on for answers to these questions and more!
What is optimisation?
Optimization
noun [ U ] (UK usually optimisation)
The act of making something as good as possible
Cambridge Dictionary
Engineers “optimise” designs and processes every day. In the process of solving problems we make incremental improvements to designs to make sure they perform better, last longer and cost less. So, what is new? The question is not whether engineers do optimisation or not — the real question is: how repeatable, robust and efficient is the process we use? That is why we tend to use another definition for optimisation:
Design optimization
is an engineering design methodology using a mathematical formulation of a design problem to support selection of the optimal design among many alternatives.
Wikipedia
The advantage of using mathematical formulations of our engineering problems is that we can solve these problems using mathematical approaches and algorithms. The problems become tractable — controllable. Complexity can be reduced to large numbers of equations that can be solved using computers.
iFetch — a worked example of design optimisation
Let’s imagine we are designing an indoor ball-launcher toy for dogs. Our (fictitious) market research tells us that 90% of our pet-loving customers live in houses or flats with one room that is at least 5m long and with a 2.4m high ceiling. We also know that dogs enjoy running after a ball, so we want to maximise the ball velocity. Assuming that we want to fix the launch angle to 45 degrees:
Question: “How fast can we launch a ball without bouncing off walls and ceilings?”
We assume that we can approximate the motion of the ball using Newton’s equations and neglecting aerodynamic drag. This allows us to write 2 constraint inequality equations (where g is the acceleration due to gravity): as long as the terms on the left are smaller than zero, the balls won’t hit the ceiling or the wall.
Of course, we could solve this very simple problem analytically on a piece of paper, but what if the constraints or objective were less intuitive? Or if there were hundreds of these equations, or hundreds of variables?
An alternative would be to solve this problem numerically — using a computer. The simplest approach would be an exhaustive search, where we evaluate the equations for a range of launch velocities between 0 m/s and 10 m/s. We would quickly identify the range of feasible launch velocities for our design (in green on the plot). If the problem was more complicated, doing an exhaustive search could take a very long time indeed. Instead, we could use one of many different algorithms that suits our problem best.
This sounds great but why isn’t everyone doing this?
There are four challenges that can be hard to overcome when implementing optimisation methods in practice.
Challenge # 1:
The first challenge is to formulate the design optimisation problem. Engineers must be able to transfer what they know about their design into a mathematical formulation. They must consider the problem variables, any constraints on the design as well as the overall design objective.
For instance, are we trying to make the product lighter, or is the aim to reduce energy consumption? What about minimising the production cost? Perhaps we want all of these? One thing that is clear is that the engineer must have a good understanding of their design and its overarching requirements to formulate a meaningful design optimisation problem.
What happens if we formulate the design problem incorrectly? Well unfortunately for us computers do exactly what you tell them to do: nothing more, nothing less. A poorly formatted design statement will quickly lead to incorrect results and a bad design.
Challenge # 2:
The next challenge is to pick the right tool (algorithm) to solve the problem — just like you wouldn’t use a hammer to tighten a screw, you can’t use every algorithm for every problem.
Not every problem is the same and choosing the wrong tool can result in worse outcomes than if you didn’t use optimisation at all! More on that later…
Challenge # 3:
The third challenge is making sense of the optimisation results. Let’s face it, no model is perfect, so how can you check that the “optimal design” makes sense? Is it better than what you started-off with? Could you get an even better design?
In most practical applications, finding the optimal solution is less important than finding a solution that is ‘good enough’. You may get several ‘optimal’ solutions — which one do you choose? How robust is your optimal solution — do small changes to the input parameters result in large performance changes?
More often than not, the decision on whether a solution is ‘good enough’ largely relies on the engineer’s understanding of the design problem.
Challenge # 4:
The final challenge is communication with stakeholders who have no understanding of what optimisation is or what the benefits may be.
For example, customers don’t usually formulate exactly what they want from a product — so translating the customer preferences into actual design targets can be truly challenging. Also, budget holders will want to see a business case, which explains how much time you will save, or what the performance or cost benefits will be.
It can also be difficult to find the time and resources to implement optimisation approaches in the first place.
And things get even more complex …
In most cases, the design process is a complex chain of interactions between different engineering teams and disciplines, but what does that mean for our design optimisation problem?
Imagine your designers use an exciting new ‘generative design’ tool (marketing teams really have a knack for selling meaningless terms!) to somehow reduce the structural weight of component A by 50% — ‘Great!’ you say. Except, a month later, the other team working on component B tells you that the weight of their component has increased by 70% because the loads coming in from component A changed. Less great.
The lesson here is that when you deal with complex systems, it is not enough to optimise only a part of your system. Instead, the better approach is to optimise the whole system at once to achieve a better design (for example, using MDO — see acronyms below).
In the example above, if the designers had optimised components A and B at the same time, they might have found a solution where the total mass of both components A and B was minimised, leading to a better overall design. Jackpot!
Ok, I feel confident, where do I start?
So, remember the four challenges we outlined above? It would make sense to start with formulating your problem and deciding what you want to get out of the optimisation process — right? Unfortunately most users will choose a tool first (probably the one that comes with the CAD package or simulation tool they already use) and then decide how they can squeeze their problem into it. This can be a problem, because not all tools are made equal.
Have a look at the Wikipedia page on mathematical optimisation, you will see that there are a good 20 different sub-fields of optimisation mentioned, all used for different purposes. Even worse, if you look at vendor marketing materials or journal papers, you are likely to come across a myriad of acronyms that are even more confusing. Here is an attempt at summarising some of the most common acronyms you will come across.
Welcome to the acronyms jungle…
MBE
Model-Based Engineering is an approach to engineering that uses models as an integral part of the technical baseline that includes the requirements, analysis, design, implementation, and verification of a capability, system, and/or product throughout the acquisition life cycle. (INCOSE)
MBSE
Those aspects of MBE specifically associated with systems engineering. Model Based Systems Engineering can be defined as the formalized application of modelling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. (MBSE wiki)
MDO
Multidisciplinary Design Optimisation is a field of engineering that uses optimization methods to solve design problems incorporating a number of disciplines. It is also known as Multidisciplinary System Design Optimization (MSDO) and Multidisciplinary Design Analysis and Optimisation (MDAO). MDO allows designers to incorporate all relevant disciplines simultaneously. The optimum of the simultaneous problem is superior to the design found by optimizing each discipline sequentially, since it can exploit the interactions between the disciplines. However, including all disciplines simultaneously significantly increases the complexity of the problem. (Wikipedia)
MOO
Multi-Objective Optimisation can generate multiple solutions, optimal under certain trade-off conditions (a set of Pareto optima). The decision-maker then chooses one of those solutions.
PIDO
Process Integration and Design Optimisation tools facilitate and automate the integration and interoperability of all different enterprise applications involved in the simulation of engineering tasks. Wikipedia lists some examples of PIDO tools.
Note that these terms are not exclusive. Hence, there are PIDO tools that implement MBSE and MDO and MOO.
What optimisation tools are available today?
In practice, you could write your own optimisation framework from scratch (good luck and see you in a few years!) — or you could make use of any one or more of the different commercial, open-source, and research codes out there today. Here are some of the options.
More realistically you could use the tool that is bundled with your existing CAE environment — optiSLang in Ansys, SOL200 in MSC Nastran or Altair’s OptiStruct are just a few examples here. These tools tend to be well suited for single discipline and single model workflows, however, it can be difficult to integrate different models and tools or include custom optimisation algorithms.
Instead you could invest in a purpose-built PIDO software such as ModeFrontier or ModelCenter. These tools are marketed as MBSE tools and are aimed at systems engineers, who want to set up and run systems models (as opposed to higher-fidelity physics-based component models) and post-process data in the GUI of the software itself. Access to the simulation and optimisation data is limited and some of the algorithms, such a pilOPT in ModeFrontier are clearly advertised as a ‘one-click’ optimisation experience — “such as not to confuse the users”.
Finally you can use an open source library like OpenMDAO or SciPy (Python). Both of these include some very powerful tools and have the benefit of a large friendly user community. However, you will need some programming basics to get started and many hours of on-the-job learning to become a confident user. Be warned — there are no native integrations with 3rd party CAE solvers — you will need to figure out how to set up, run and recover results from your simulations.
The future
Thanks to the advent of computers the toolset for optimisation has been expanding since the 1940s. Despite this, it seems that there are still a number of challenges to fully taking advantage of optimisation in practical applications. What does the future hold? An engineer’s wish list …
- Distributed and cloud compute to optimise design problems which rely on computationally expensive models (without endless tinkering)
- Less restrictive licenses which let us parallelise our simulations — what good is 200 cores if we have a single license?
- Algorithmic differentiation tools which calculate gradients of simulations without needing a PhD.
- Surrogate and meta model frameworks to enhance our most expensive optimisations.
- Take into account the uncertainty that goes into our models to reflect non-deterministic outcomes in the design — we want a design that works well 99.9% of the time, not one that is amazing only 5% of the time.
- More collaboration between engineering teams throughout the use of digital workflow integration, automation and design optimisation tools.
6 questions to start your first optimisation problem
There is still a way to go on the road to optimisation. For now, here are some recommendations for a successful journey.
Always start by defining the problem you are trying to solve and the outputs you expect. Here are 6 questions to ask yourself before you chose a tool to solve the problem:
- What is the target? What do I expect to get out of this optimisation?
- What is the scope and size of the design problem?
- Do I have access to all the input data and models I need?
- How will I decide if the optimised design makes sense?
- How much customisation and access to the data will I need?
- Do I have the time and skills to implement design optimisation?
Final words
Beware of anyone promising you an optimisation tool in a black-box. Optimisation models should be verified, just as you verify your other simulation models. For that, you need to have a basic understanding of how optimal solutions are generated.
Finally, talk to the experts. There are a number of professional associations out there that can point you in the right direction (have a look at the NAFEMS optimisation community page for example), or get in touch with the Dapta team via contact@dapta.com.
Now, buckle-up and enjoy the ride!
