In the previous post, we saw that results delivered by meshless techniques, such as ReveaL, are within 1% of those that standard finite element software compute. When the geometric model and the material parameters are identical, this is not a surprising result. It is not surprising because the technology behind ReveaL builds upon the same mathematical foundations as standard finite elements. As pointed out in the comments on our first blog post, when we start from a clean CAD model that mesh generators are able to digest, meshless methods might fall behind in terms of sheer computational time. However, as the quality of the CAD model deteriorates, ReveaL’s shine gets bigger and bigger. But what happens if there is no CAD model at all to start with?
We are so much used to the fact that every analysis starts from a CAD model that we forgot about a tiny question. What happens even before the magic mesh generator button is clicked: what if the object we want to simulate doesn’t have a CAD representation at all?
Think about it. Many things in the world around us were designed by mother nature instead of an engineer: the bones in our body, rock formations, landscapes, riverbeds, all things with interesting physics yet impossible to simulate directly. Further, a digital model might be missing even if a human-designed the object. Prominent examples for this case are from the world of cultural heritage. Statues or historical monuments for example are human-made structures without a CAD model. When we want to simulate them, someone needs to do a complete re-modeling before even thinking about generating a mesh. This reverse engineering is a time-consuming process.
If the object is simple, like a cube made of stone, it is easy to re-model it. Take a ruler, measure one edge, make a cube in CAD, done. But what happens if we need to reverse engineer the model from the previous post?
Using a simple ruler, reverse engineering this model will take forever. Thankfully, there are alternative techniques that make our lives easier. There are coordinate measuring machines that rely on mechanical contact between a probe and the object. There are also contact-free measurement techniques, e.g., laser scanning of photogrammetric reconstructions. The common feature of these shape measurement methods is that their output is a bunch of points representing the object’s surface. They are usually called as point clouds.
While a point cloud might spare the time of measuring the surface of an object, it does not help the analyst further at all. There is no way to generate a mesh directly on a point cloud without first turning it into a surface model. There are different ways to recover a surface model. However, many of the recovered models are full of flaws that prevent analysis in the first place.
In a previous project, our client recorded a surface scan of the cast aluminum part that we investigated in a post in the past. They started turning this into a surface model when we were asked to have a look:
It is clear that before standard finite element analysis, there is a lot of clean-up to be done before mesh generation can take place. We thought that this is a great opportunity to test the capabilities of ReveaL, especially that we have a reference result computed on the original STEP model. So we set the goal to perform a modal analysis just like in the previous post, but this time on the surface scan. This will make it possible to make a three-way comparison on the reference computed by a standard CAD tool and our results from the standard geometry and the surface scan.
Therefore, we loaded the surface scan in ReveaL and performed a modal analysis. As always, let’s start with the colorful pictures about the first three eigenmodes, comparing ReveaL and the reference result:
First eigenmode, ReveaL on surface scan and reference solution
Second eigenmode, ReveaL on surface scan and reference solution
Third eigenmode, ReveaL on surface scan and reference solution
Just like we did before, we compared the values of the first 9 eigenfrequencies in a tabular form:
|Eigenmode||Eigenfequency ReveaL on surface scan||Reference solution||Difference|
|#1||742.782 Hz||744.85 Hz||0.27%|
|#2||805.674 Hz||827.87 Hz||2.68%|
|#3||1309.51 Hz||1310.83 Hz||0.1%|
|#4||1380.75 Hz||1406.44 Hz||1.83%|
|#5||1542.1 Hz||1542.16 Hz||0%|
|#6||1786.01 Hz||1748.12 Hz||2.17%|
|#7||1985.97 Hz||1944.03 Hz||2.16%|
|#8||2385.65 Hz||2317.98 Hz||2.92%|
|#9||2554.06 Hz||2503.14 Hz||1.7%|
As seen in the table, every eigenfrequency stays within 3% of the reference solution. This in my opinion is quite good for a method that spares about 80% of the preprocessing time!
Yes, it is! It turns out that there is no need to reconstruct any surface from the point cloud. Instead, it is enough to feed ReveaL with the point cloud directly. In the upcoming weeks, we will have a look at examples where not even a partial reconstruction is available, and the analysis is performed directly on the cloud. Stay tuned!
Clients often ask us about the accuracy of ReveaL. Usually, these questions are phrased as “Are you sure the results are correct?“, “Have you compared your meshless method to standard finite elements?“. This makes complete sense: a novel technology needs to build up its reputation before people consider adopting it.
One can think of various ways to compare values that ReveaL and a standard FEM tool delivers. For elastic problems, a good basis of comparison would be to look at the displacements or stresses at specific points of the object. Also, the amount of elastic energy that the body stores during its deformation is a popular indicator of correctness.
If we don’t only want to look at specific points or the strain energy, a possibly more spectacular way is to compare the natural frequencies of the body computed by ReveaL and another FEM tool. Let’s have a closer look on such an example from the automotive industry and perform a meshless eigenfrequency analysis of a cast part.
“If you want to find the secrets of the universe, think in terms of energy, frequency and vibration.” – Nikola Tesla
If an object made of some elastic material is struck, it starts to vibrate at certain frequencies. These natural frequencies depend on its shape and material. For example, a tuning fork made of steel is shaped so that it will sound exactly at 440Hz if you hit it against a surface. This makes it very useful for tuning musical instruments.
There are cases when having a natural frequency at the wrong spot will cause unfavorable effects. Take a skyscraper hit by an earthquake, for example. If the frequency of the ground’s motion matches one of the natural frequencies of the building, it might even collapse. The designers of the building need to avoid that this resonance occurs when designing the building.
Similarly, if you build a car, you want to make sure that the metal parts will not resonate at the frequency where the engine operates. If you don’t do that, the driver will hear disturbing sounds when driving at certain speeds. Even if we forget about acoustics, it is an important job for structural engineers to determine the natural frequencies. For example, when performing a dynamic simulation on a part, the natural frequencies are key indicators about the right time step size.
In one pilot project, we were given the following part in the form of a STEP file:
This is a cast aluminum part from the automotive industry. The goal that we set for this case was to compute the first 9 natural frequencies of the object using ReveaL, while our partners perform the same analysis on their side using another commercial FEM tool. Ideally, the results from our end will match their results computed by them.
So we loaded the part in ReveaL, set the material parameters and let the computation run. Fortunately, we could avoid the mesh generation step, and directly have the eigenfrequencies (=natural frequencies) and eigenmodes computed. The first three eigenmodes look as:
First eigenmode, ReveaL and standard FEM tool
Second eigenmode, ReveaL and standard FEM tool
Third eigenmode, ReveaL and standard FEM tool
“Great, the eigenmodes match very well” – we thought. What about the values of the eigenfrequencies? After all, we are interested in numbers, and not only the colorful pictures about eigenmodes.
To answer the question of accuracy, we compared the first 9 eigenfrequencies to standard FEM in a tabular form:
|Eigenmode||Eigenfrequency ReveaL||Eigenfrequency Standard FEM||Difference|
|#1||745.784 Hz||744.85 Hz||0.13%|
|#2||830.133 Hz||827.87 Hz||0.27%|
|#3||1304.5 Hz||1310.83 Hz||0.48%|
|#4||1394.59 Hz||1406.44 Hz||0.84%|
|#5||1539.16 Hz||1542.16 Hz||0.19%|
|#6||1745.49 Hz||1748.12 Hz||0.15%|
|#7||1937.53 Hz||1944.03 Hz||0.33%|
|#8||2311.54 Hz||2317.98 Hz||0.28%|
|#9||2503.14 Hz||2511.47 Hz||0.33%|
As the table shows, the results delivered by ReveaL are within 1% of those that are computed by a standard FEM tool. However, a very important feature that distinguishes ReveaL from standard FEM approaches is the minimum amount of preprocessing effort. The only manual labor required in our workflow was to load the model, set the material parameters and the problem type, then launch the computation.
To be fair, the mesh generator of the standard FEM tool did succeed for this model. This makes ReveaL’s advantages less apparent for this specific case. But: imagine now that the engineer who is looking at the results realizes that one of the frequencies lies exactly at an unwanted value. Clearly, he needs to apply a modification to the design. For standard FEM, changing the design would mean generating a new mesh, an extra step which is pretty much unnecessary. In fact, it’s not only unnecessary but a potential show-stopper, as every design change carries the danger of introducing geometric flaws. Flaws can brake mesh generators in spectacular ways, as we saw in the last post.
If, however, we remain in the meshless world, the hassle of going for another design iteration can be drastically reduced. The real power or ReveaL becomes more pronounced if we turn our attention to flawed geometries.
There is something that is even more interesting than standard CAD-based applications. In the next post, we will leave the CAD world behind and look at questions that do not start from CAD geometries at all. We will perform the same analysis on a surface scan of the cast aluminum component, leading us in the direction of reverse engineering. Stay tuned!
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.