Published by:

Imagine that you are an engineer working for a mid-sized company and your responsibility is to perform simulations.
Your department is working on the latest and greatest version of the company’s product.
The team tasked with the development follows a tight schedule: designers implement changing requirements, they apply changes to the model on a daily basis, and as soon as they are done, push the latest version on your todo list for simulation. The task comes also with an email note – marked important, of course – that first simulation results on this version are needed for tomorrow 10:00 AM latest, before meeting the product managers.
So you look at your watch. It’s 5:33 PM already, you were just about to go home, or at least have been trying for half an hour. With a silent sigh you fire up the simulation environment to load the model, and zoom in to check how it looks like.
Then you see this:
“Great… another long shift” – you think. You reach for your phone, and check when the last train is leaving. Needless to say, you already put the train timetable on the home screen, as leaving late has become the standard in these weeks.
But what is happening?
What you are facing is one of the fundamental problems in the world of simulations: creating a simulation model from a design that was not created with analysis in mind.
The difficulty of this process comes from the so-called mesh generation step, that most simulation approaches require. Usually, without a mesh, there is no simulation. However, mesh generators are very sensitive. They happily work if they see clean geometries like the one below.
But, mesh generators throw up the sponge if they encounter this.
There are at least a dozen reasons why meshing can fail, but most commonly a failure is caused by defects in the geometric model, e.g. holes or small openings, overlapping faces, just to name a few. Designers don’t necessarily see them because their primary focus is on the design itself and not readiness for simulations. Therefore, defects often go unnoticed until mesh generation.
The pain with these flawed models is so high that a whole industry has been established around the promise to fix them, offering various ways to overcome the issue, ranging from automatic or semi-automatic ways to completely manual solutions.
Of course, these healing solutions offer a remedy, but a rather sour one. After all, there needs to be someone who operates the healing software, and this someone needs to have the expertise and know-how to make the fixes efficiently.
Healing is a solution, but a one that fails to address the root cause. Instead of closing the gap between designers and simulation engineers, healing even widens it, by introducing another phase in the product development cycle. Right after a digital model is ready, but before it lands on the simulation engineer’s desk, someone is up for additional work to check and fix errors in the model.
In the best case, there is someone in the team who has the time and expertise of doing that. In the worst case, there is no one, and an unfortunate engineer ends up staring at his screen at 5:33 PM, googling the term “meshing failed”.
Good luck catching that night train.
Wouldn’t it be more efficient to avoid mesh generation completely and simulate models as they are? Can we do better, and simulate directly?
Scientists and engineers developing simulation technologies have been thinking about these questions for a long time and came to the conclusion that the best thing you can do is to avoid meshing in the first place. If there is no mesh, there is no meshing problem, simple as that. Starting from this idea, extensive research followed and new, meshless technologies appeared on the horizon, promising to bridge the gap between designers and analysts.
“Alright,” – you ask – “are you telling me that it is possible to take a flawed model and simulate without worrying about any mesh?”
Yes, this is exactly where we are going.
Let’s demonstrate it with the example that makes people miss the night train.
I loaded a typical flawed model in ReveaL, and set up a scenario where the model is squashed together vertically.
This is the point where you would start generating a mesh, murmuring prayers that no failure will occur.
Let’s forget the prayers, and click simulate instead:
Within a couple of seconds, the simulation result pops up.
This is great. Let’s crank up the precision and create a couple of screenshots for that meeting tomorrow:
Within a couple of minutes, the work of a whole day has been accomplished.
And now hurry up, you have a train to catch!
The benefits of having a direct bridge between the designer world and the simulation world are immense. Design alternatives can be evaluated within a matter of seconds, allowing the analyst to give almost immediate feedback to the designer team about how changes in the model affect the mechanical performance indicators of the product. This makes it possible to tighten the development loop and lets the team shift its focus on revealing the design flaws faster and more efficiently.
By avoiding meshing, the door opens for applications way beyond the analysis of flawed models. Stay tuned for the next article, where we will discover how surface scans can be quickly and efficiently simulated, ReveaLing the unseen in the world.
Thanks, Laszlo! It is a really great insight!
Very interesting article. I am curious where is the catch. Is there any cost in terms of performance or precision?
Thanks a lot for the feedback. Indeed, there are computational costs that arise because of skipping the mesh generation step. If you start from a directly meshable geometry and thus a clean mesh, the solution time for meshless methods falls behind classic, mesh based approaches. Where ReveaL really shines is when it comes to handling flaws. It doesn’t matter whether there’s a single flaw or a hundred of them, the computation time will not be much different. However, fixing these flaws manually – as it is done in the standard workflow – will impact the complete simulation time in the standard case drastically.
As for the precision question, I invite you to follow our upcoming blog posts where we will demonstrate how our results compare to those computed by classic, mesh-based simulation tools.
Thank you for the response. I look forward to your future posts.
Great demo! As close to free-lunch as one can hope for thees days =]