About the attempt to merge CAD and FEA

Author: Alexandru Dadalau

22th February 2021, Reading time 15 min.

In a previous blog article I wrote about the parallel development of the CAD and FEA programs.

From what has been told, one could also draw the following conclusion, among others:

In the beginning, 3D CAD programs were too expensive and too slow to use. Then they became a matter of course.

FEA programs were even more rare and, if we're honest, even until the turn of the millennium, rarely used and highly localized.

Moreover, the manufacturers of CAD programs and those of FEA programs were always different houses that had little to do with each other.

At some point, CAD manufacturers started thinking about additional markets and discovered FEA for themselves. Slowly but surely, more and more existing FE solvers were linked to their respective CAD programs so that data (geometry, FE mesh and results) could be exchanged between the two worlds. Additional graphical elements for FE model creation and evaluation were added to the CAD interfaces.

This historic evolution of CAD programs meant that a much broader group of users suddenly had access to the world of FE analysis. When I think back to my industrial experience 20 years ago, even in large mechanical engineering companies it was the case that an entire development department consisted of fifty CAD designers, but only one FEA engineer. And the absolute majority of other medium-sized companies had no FEA people at all.

This makes it clear what an invisible, silent revolution was set in motion by the addition of FEA functions to CAD programs. This revolution, interestingly, continues to evolve to this day, so I'm not so sure I should necessarily call this a revolution. In any case, this is a slow revolution.

However, the introduction of FEA into the CAD world has also had another important side effect: FEA manufacturers have been put under massive pressure. Before that, FEA was a tool for the absolute specialists. In companies, these were always the colleagues who never understood what they were doing all day long anyway. All of a sudden, any designer, no matter how FEA-inexperienced, could now generate the "pretty little colorful pictures".

As a long-time former FEA nerd, I must confess that in the beginning, like many others, I too thought: This can't work. Today, however, as befits a self-organizing system, the market has solidified. The users know the limits of applicability and apply the software tools with reason. On the one hand, there are the designers who occasionally use the CAD extension for simple FE analyses. And they are now very aware that there are limits and that these cannot be exceeded by the CAD extension. On the other hand, there are still the long-time FEA specialists. Some companies employ a permanent FEA specialist for this purpose. Many others, however, rely on external service providers. "They know what they're doing," to quote a frequently heard phrase.

Now I come back to the FEA manufacturers. I suspect that the inroads from CAD have triggered some rethinking among them. Before, FEA was seen as a tool of the experts. Now they had to admit, whether they liked it or not, that those days would soon be over. A period of modernization of the graphical interfaces of FEA programs began. Ansys, for example, made a significant leap with the introduction of Ansys Workbench, about 15 years ago. Today, the graphical interfaces of FEA programs are becoming more and more like those of CAD programs to make them as palatable as possible to CAD users.

In short, CAD programs have integrated more and more FEA, while FEA programs have integrated more and more CAD.

Personally, however, I have noticed another point that is likely to be crucial to further development in these areas: CAD extensions are still dedicated to simple simulation tasks, FEA-only programs to experts. Now all the FEA and CAD vendors will jump up indignantly and contradict me. I can only say: Sit down again, it is not meant that way at all. First of all, I am only talking about the subjective perception of the end users. I know them very well because I get to talk to many of them every day.

So, if we first accept the users' opinion, then the question arises: why is that? What makes a CAD extension for FE analysis different from a dedicated FEA software? And why does the convergence of CAD and FEA programs last so long? Will this convergence eventually converge so that there are only CAX programs that can do both beautifully?

My personal opinion is that FEA, by its very nature, requires a lot of knowledge on the part of the user. I don't necessarily mean FEA-specific knowledge. Rather, I mean a deep, technical, mechanical and physical understanding.

Now, the strategy of CAD vendors in developing FEA extensions has been this from the beginning: Ease of use by sacrificing features. This is somewhat similar to what is at the forefront of smartphone app development. Now this strategy can only work to a limited extent in the FEA world. As long as the task to be simulated fits into the given framework, everything is fine. For all other cases, you need the expert programs.

For the FEA vendors on the other hand, the development strategy has been to "spruce up" the graphical interface while keeping the feature richness the same. This is great for the FEA nerds, because they keep their "old" playground. For the not so experienced CAD users, however, many questions remain open and a lot of uncertainty in the application. So it's more about the questions: Which of the many possibilities may I use, under which conditions? Or quite basically: what am I allowed to do with the program, and what am I not allowed to do?

As you can see, the difficulty is that an FE program cannot replace the necessary understanding. Only by renouncing features, just not everything is solved.

So where do we see ourselves as Meshparts in this global development? Well, Meshparts was born out of the urge to rethink. Our specialized approach to FE modeling allows our customers to do more simulation with less specialist knowledge. At this point, I would just like to briefly mention our FE model libraries and the CAD twin. This allows the user to focus more on the actual simulation task. However, we see the need to keep FEA strictly separated from CAD. This may sound surprising but please do not misinterpret. We want to offer a CAD independent solution that can communicate perfectly with any CAD software. Via the CAD twin we achieve a perfect symmetry between FEA and CAD. FE models can be created automatically via the PDM connection. Changes to the CAD model are automatically transferred to the FE model.

Since a picture is worth a thousand words, and a video even more, I'd like to conclude by illustrating the whole thing with a video. Below you can see the perfect symbiosis between a CAD program (SolidWorks in this case), Meshparts and RISTRA (the GPU-based, live solver of Fraunhofer IGD). The video was recorded on three screens; however, it would work just as well with two. Play video

The interesting thing about this video is, on the one hand, the speed with which RISTRA computes on the graphics card. Another is that the CAD user remains in their familiar CAD environment the entire time and can watch the stresses in the part live on another screen. On that note, as always, I look forward to your feedback on the article and until next time.

Like what you're reading? Subscribe to our top stories.

We update Meshparts several times a month; if you have any questions or suggestions, please contact us!