Author: Alexandru Dadalau

25th January 2021, Reading time 20 min.

Today I'll tell you how Finite Element Analysis (FEA) has evolved over time. Most importantly, I want to highlight why the (vast) majority of FEA programs today work the way they do. And finally, I want to explain why I think that rethinking is a good idea for users.

Computer Aided Design (CAD)

FEA has been tied to the development of CAD systems almost from the beginning. Therefore, it is first important to look at how CAD has evolved.

In the early days, CAD programs were simple 2D sketching tools, with no particular intelligence.

In 1960, Ivan Sutherland developed the first modern 2D CAD program, SKETCHPAD, as part of his doctoral thesis. For the times, the new program was a revolution. The two most important, groundbreaking unique selling points of SHETCHPAD were:

• The automatic solution of complex geometric constraints (e.g. perpendicular, parallel, collinear, equal length, etc.).
• Object-oriented approach (individual drawings could be reused and assembled to create larger drawings).

The following video demonstrates the impressive way of working with SKETCHPAD: Play video

It took 12 more years until the first 3D CAD program in 1972: SynthaVision. The next video shows some animations created with SynthaVision. However, 3D CAD programs were too resource-intensive for the computers of the time. Mass distribution could not yet take place for this reason. Play video

In 1978, a new standard in 3D CAD modeling was set with the release of Unigraphics: Play video

In 1985 Pro/Engineer was released by the company PTC. Despite initial teething troubles, a real revolution! Pro/Engineer immediately eclipsed all previous systems. As a side note, Pro/Engineer was the first 3D CAD program to consistently implement the concepts of SKETCHPAD(!) into the 2D and 3D world. Here is a demo video of the software version at that time: Play video

10 years later - 1995 - SolidWorks appeared. It offered most of the functionality of the existing leading CAD programs, but cost only a fraction of them. Here is a demo from 1995: Play video The success of SolidWorks was so great that the small company was bought by Dassault Systemes two years later. Finally, here's a demo video of SolidWorks from 2007 that focuses on assembly modeling: Play video

If you have watched the above mentioned old software demo videos, you have probably already recognized the milestones of the CAD development:

• First: 2D sketches
• after that: 3D single parts
• much later: 3D assemblies

I would also like to draw your attention to something else: The concept of assemblies was already known in 1960 (at the latest by SKETCHPAD). Despite the obvious advantages of assembly modeling, 3D CAD had initially focused on modeling individual parts! It was not until 25 years after SKETCHPAD that the concepts of that time were taken up and implemented in a 3D CAD program. This was also one of the main reasons why Pro/Engineer became so successful.

Finite Element Analysis (FEA)

Now that we have an overview of CAD development, I would like to turn to FEA development.

The basis of FEA is the FEM (Finite Element Method), which has its origins in the 1940s. The first commercial FEA software was introduced to the public in 1971: NASTRAN.

Originally, the available computer power was only enough for rough calculations of individual parts.

For today's computers, large assemblies are less and less of a problem. At least that's what all FEA software vendors claim. For some, that's true; for some others, it may be only half true. In talking with engineers from various mechanical engineering companies, I often hear that larger CAD assemblies are first merged into individual parts before they are imported into the FEA environment. I then ask why, and the answers are often: too many individual parts lead to too many contacts, too many contacts can no longer be checked for correctness. Or also that the FEA software cannot properly close the larger gaps between the individual parts. Or that purchased parts such as roller bearings, linear guides and ball screws can only be modeled too simplified or not at all. These would be just a few reasons and we realize that with assemblies and FEA, the devil is in the details.

It almost looks like the big FEA vendors want to focus a lot on parallelizing the solvers and look less at the many little "devils". They focus on solving more and more millions of model degrees of freedom even faster (which is basically good for assemblies), but neglect the hundreds or even thousands of - inherently small - individual components in common CAD assemblies.

When I started with FEA 20 years ago, I immediately had to deal with entire machines in simulation. That was jumping in at the deep end, but it was fun. My first FE simulation was a lithography machine (manufacturing TFT screens). Then followed laser cutting machines, milling machines, lathes, etc.

Despite my enjoyment of simulation, dissatisfaction soon crept in due to the many repetitive steps. Design changes to individual CAD components resulted in a disproportionate amount of change to the FE assembly. If a new machine had to be simulated, I had to start from scratch, although perhaps 50% of the new machine was the same as the old machine. This way of working is still the current state of the art today.

Why is that?

Well, amazingly, the idea of the assembly stops completely with FEA systems. So when a CAD assembly is read into an ordinary FE program, the first thing that happens is that the assembly structure is broken down. You get a bunch of individual components, without any sequence, structure or relation to each other.

Next, the usual FE contacts (the connections between individual components) are automatically defined. This results in another bunch of hundreds, even thousands of contacts. The user is then supposed to check these countless contacts for correctness. Because, not every automatically defined contact is a real contact. That's no fun.

Presumably, the whole thing has grown historically. Before 1985, the idea of assemblies was not present in the CAD solutions of the time anyway. Probably for that reason FEA developers simply designed their FE programs without the idea of assemblies. It is certainly also true that in the past, computer resources were limited, so the most one could calculate anyway was simple models with few components. I have another possible explanation for this: FE simulation of assemblies only became possible with the development of composite contacts. By that time, most of today's FEA programs had already been developed.

Meshparts

And now back to my early experiences in FEA. About 15 years ago I realized that all these problems can be solved by a consequent continuation of the assembly idea into the FE world. Thus, the idea of Meshparts was born. At that time I was about to graduate and had decided to develop the idea at a research institute at the University of Stuttgart (ISW). Five years later I founded Meshparts. The result is a new kind of FEA software - Meshparts, which does so much different than all other current FEA programs that it needs access to the historical arc of CAD and FEA development to properly understand how it works.

Meshparts started out as a simple configuration tool that could be used to automatically combine various individual FE models into FE assemblies. There was also a way to instantiate the same FE model multiple times. And one could move the positions of the components arbitrarily to each other. The whole thing was created at the end of my studies. I then developed the tool further as part of my research work at the institute.

In parallel to the development of the tool, I did research on how to efficiently and reproducibly model the common purchased parts in mechanical engineering. In fact, I also had the idea that all these purchased parts should be put into one FE model library. The same idea had been standard in the CAD world for decades (Traceparts, CADENAS and the like).

After the time at the research institute and during the first years of Meshparts, I was able to win some customers and generate sales with the already developed tool. That was all well and good and this tool already saved a lot of work for the users at that time.

At the beginning of 2014 I decided to turn the tool into a real FEA software. The new development took a year until the first release. Just like Pro/Engineer at the time, the new Meshparts suffered from many teething problems. The reason: we had to rethink, redevelop almost everything. To understand a little bit why Meshparts is so much different, a first hint: The FE model of an assembly in Meshparts is a file that is only a few kilobytes small. The same FE model in the other known FE programs would be at least one order of magnitude larger.

The assembly idea

Meshparts models are real assemblies. This means that the models do not contain the information of their individual parts, but only a reference to the individual parts. The individual parts only contain the actual FE meshes (which, after all, require a lot of storage space).

But now the first important property of Meshparts: If a CAD assembly is imported into Meshparts, then as many Meshparts subassemblies as CAD subassemblies are created. And as many Meshparts parts are created as CAD parts. Finally, all Meshparts assemblies contain the same assembly structure as their corresponding CAD assemblies. This is why we call the result of a CAD import into Meshparts: "CAD Twin".

The library idea

The second important feature of Meshparts is the integrated online library. This can be thought of as similar to CADENAS, but just for FEA. So in Meshparts, no purchased parts are modeled. Instead, the corresponding CAD models are replaced by existing FE models.

We quickly realized that eliminating the need to model purchased parts has huge benefits, some of which I'll mention here:

1. The user no longer needs to be an FEA expert to model the complex mechanical behavior of purchased parts.
2. Since the same purchased parts appear again and again in different models, the user saves time twice, no, many times.
3. The reproducibility of the FE results is ensured; a notable source of deviations, sometimes also errors, is closed. As is known simulation engineers tend to model their models sometimes so, sometimes differently.

The FE model library is therefore a super work relief and almost more importantly, a real quality gain.

Part Mappings

Soon, however, we considered that even replacing purchased parts is, after all, in principle a tedious, repetitive job. A solution had to be found.

In the middle of 2020 we introduced the "Part Mappings". You have to think of it like a table with two columns. In the left column are names of purchased parts (just like CAD file names). In the right column are the paths to the FE models from the library. This table can be created right at the beginning for all parts. Or the table is automatically extended with each new manual replacement. So Meshparts remembers your actions for later. So when a new CAD assembly is imported, there is no need to re-mesh the CAD add-on parts; they are automatically replaced according to the part mappings.

The Part Mappings were a logical continuation of the library idea. This gives the user another significant efficiency boost. But we weren't satisfied with that either. The remaining parts and assemblies were next. To understand why we were still missing something in our software, I need to briefly explain how companies work with PDM systems.

If a CAD designer wants to open a CAD assembly in his CAD program, then this assembly is first downloaded from the PDM system and saved locally. Now it could be, then the designer would like to change a certain component constructively. He does this with the functions available in the CAD program. When he is finished, he uploads the modified assembly or component back into the PDM system. In the process, a version number is assigned to the modified part. Each part and assembly in the PDM system has a version number. The file names, on the other hand, remain the same. So when a CAD assembly is downloaded from the PDM system, you can't tell if it's an old or new design status just by looking at the file names.

Meshparts on the other hand tries to reuse already imported models with every new CAD import. Until recently, this only worked based on file paths and file modification date. If an imported part was not already in the import folder, then that part was created and meshed. But if the part already existed in the import folder, the modification date of the FE part was compared to the modification date of the CAD part. This allowed Meshparts to decide whether the finished part should simply be imported directly, or whether it should be re-meshed after all, since the corresponding part had changed.

Now we had identified three problems with the described logic:

1. Due to the fact that the designer kept downloading the CAD assemblies from the PDM system over and over again, the modification date of the CAD files was always different, even if they did not actually change.
2. On top of that, the folder could change even though the assemblies contained common parts. Copies of the same files in different folders were created.
3. And finally, even parts with the same name can still contain different design states.

Due to the above three problems, Meshparts could until recently at best only reuse purchased parts but not self-designed components or assemblies. And this although technically everything would have been possible. The fact is that working with a PDM system has its own peculiarities.

Collection Directories

The solution came at the end of 2020 in the form of "Collection Directories" or "collection folders."

The Collection Directories can also be thought of as a table with two columns. On the left are the source directories, and on the right are the target directories, i.e. collection folders.

Now, when a CAD assembly is imported into Meshparts, all files under a source directory are copied to the destination directory. However, if files with the same name are already in the target directory, they will be copied from there. This already solves the first and second problem (see the listing above).

Now, when using Collection Directories, the file modification date check is no longer performed. That is, existing models are reused regardless of the modification date.

So, the third problem from the above listing had to be solved as well. For this we developed a simple connection to the PDM system, through which the versioning of the imported files is checked. The version name is taken over and a directory with the same name is created in the Collection Directory for each versioned component. The corresponding Meshparts models are then automatically stored in these version directories. Thus, the PDM connection and version number replaces the file change date. Otherwise, everything remains the same.

Closing words

From the very beginning, we were guided in the development of Meshparts by one all-important goal: to achieve maximum efficiency through consistent automation and reusability.

I am sure that our goal would not be achievable if our software was not assembly-based. It's nice for us to see how one optimization leads to the next and how everything makes even more sense in the end.

Finally, I come back to the thought I expressed at the beginning: I think rethinking FEA users would be a good idea. Ask yourself why your FEA software doesn't know about assemblies. Imagine how different your work would be if you worked with FE assemblies.