PrometheusCore

Translate this page:

Difference between classical FEM and FEMnet

 

by Dubko M., m.dubko@promcore.io

 

           

           The finite element method (FEM) has long been the standard for calculating the behavior of complex structures, be it bridges, buildings or other engineering systems. It breaks the entire structure into many small "elements" and calculates parameters for each of them based on physical laws, forming a system of equations, which are then solved to obtain an accurate distribution of stresses and strains. 

            Recently, neural network approaches such as FEMnet or SmartCity have emerged, which also use the idea of ​​breaking the structure into finite elements, but work in a completely different way. Instead of recalculating stiffness matrices each time using physical equations, the neural network is trained on many examples, memorizing the laws of element behavior. As a result, FEMnet generates its own internal "matrices" that approximate the behavior of the structure, giving fast results.

Below is a detailed explanation of the differences between classical FEM and the neural network method FEMnet.       

            Imagine you want to understand how a bridge works. The traditional finite element method (FEM) breaks the entire bridge down into many small parts called “elements.” For each element, physical laws (such as Hooke’s law) are used to calculate how it will behave under load. The result is a large system of linear equations, where each small matrix (called a stiffness matrix) reflects how “elastic” or “flexible” the element is. By solving this system, engineers get the distribution of stresses and strains across the entire bridge.

            Now imagine that instead of calculating everything from scratch for each new bridge, we train a neural network called FEMnet. This neural network also “breaks down” the bridge into finite elements, but the process is different. Instead of directly calculating physical coefficients (such as material stiffness), the neural network is trained on many examples where the results of calculations or experimental data are already known. It learns to “recognize” patterns and produces results based on its experience.

What is the difference?

 

Classic FEM:

Each element is treated according to physical laws, and a specific matrix (e.g., a stiffness matrix) is generated for it, which accurately reflects the material properties and geometry of the element. These matrices are then combined into one large system, the solution of which gives an accurate distribution of stresses and deformations.

Example: If you know that rubber is more flexible than steel, then the matrix for a rubber element will be “more flexible” than for a steel element.

 

FEMnet (Finite Element Neural Network):
Here, the bridge is also broken down into small elements, but instead of direct physical calculations, the neural network generates its own "matrices." These matrices are not classic stiffness matrices - they are a set of numbers that the neural network uses to quickly approximate the behavior of elements based on training data. In other words, the neural network "knows" how elements usually behave in similar situations and forms its own internal representations, which may differ in appearance from classic matrices, but give a similar result.

Example: Imagine that you have seen many times how a pedestrian bridge made of steel elements behaves under a specific load. Instead of calculating from scratch each time, you remember that in such cases the stress distribution is always approximately the same, and a ready-made solution is born in your head. This is exactly how a neural network works - it remembers the "image" of the elements' behavior, but much more accurately than a human neural network.

 

           Why is this important to understand?

       

           Many people think that the finite element method is simply solving a system of linear equations. In fact, the classic FEM is strictly related to physics: here, each matrix has a clear physical meaning. And when the neural network is turned on, the principle of partitioning remains, but the matrices themselves - their appearance and meaning - already change. The neural network uses data to give a quick answer, but this answer is based on learning, and not on pure physical laws.

           Thus, although both methods "break" the object into finite elements, the classical approach builds a model based on physical laws, and the neural network model uses statistics and patterns learned from examples. This allows for significantly faster calculations, albeit with a slight deviation from the "absolute" accuracy of classical methods.

 

CPU Applications vs. GPU Applications: An Overview

 

         When calculating building structures (e.g., in ANSYS, Abaqus), traditional systems use the central processing unit (CPU) and system random access memory (RAM). For large models, these methods are well-established, but the speed of parallel calculations is limited by the number of cores and caching efficiency. At the same time, modern solutions (e.g., PromCore) transfer a significant part of operations to graphic processors (GPU), using video memory (VRAM) and a high degree of parallelism. This allows iterative calculations and even neural network algorithms to be performed thousands of times faster, but requires a special data storage architecture and other programming methods.

         Those who worked in ANSYS often encountered the error "Matrix solver exception: out of memory" in CPU solutions, when solving problems that go beyond the total RAM memory, it is necessary to either reduce the dimension of the finite elements or divide the problem into some large blocks.

        With GPU, things were much more complicated. When the VRAM of the video card was exhausted, usually the application also received an exception of its work, since the graphics API was not ready to visualize such large data. But with the advent of new graphics APIs, such as Vulkan.

         Vulkan is a low-level, cross-platform API that gives developers more explicit control over resource management, including memory. This allows Vulkan to behave more predictably and reliably than, say, DirectX when dealing with system RAM reservations when VRAM is low.

Fig.1 RAM usage on GPU

 

          The picture demonstrates how the new version of the PromCore 4 program now behaves when the SmartCity neural network is running outside the GPU VRAM. How much RAM is reserved on the GPU depends on the specific PC and is configured in the BIOS. On a specific server for testing, 64 GB of RAM is reserved. Taking into account 24 GB of VRAM, the total RAM was 88 GB.

         Why this might be:

- Explicit memory management: Vulkan requires the developer to manually manage memory, allowing fine-tuning of how data is copied and distributed between VRAM and system RAM. This can help in scenarios where VRAM is limited and the need for memory reservation is critical.

- Lower overhead: Vulkan is designed to minimize hidden overhead, resulting in more stable and faster performance for intensive computations, including neural networks.

 

          However, it is important to note that the stability of neural networks on the GPU depends not only on the chosen API, but also on the quality of drivers, optimization of a particular application, and support from frameworks.

          Thus, if developers use Vulkan's capabilities correctly, it can indeed provide more stable behavior of neural networks, especially in cases where system RAM reservation is required due to a lack of VRAM.

 

         In the new version of PromCore, not only all calculations are now performed on the GPU, but also multithreading on the CPU and GPU is used to the maximum when processing model geometry, since it is impossible to completely abandon the CPU. For example, a construction site of 48 buildings:                                                                                                                                                                                           

 

Fig. 2 Test model for GPU and RAM

 

             The full calculation and generation of all the reinforcement took about 9 minutes. The model takes up more than 50 GB of RAM. The total number of finite elements was about 20 million. In other words, the new version of PromCore removes the last argument - the limitation of the tasks solved on the GPU by the VRAM volume.

 

Why is it difficult to adapt classic programs to GPU

 

             All of the above complicates the mass transition of old calculation packages (ANSYS, Abaqus, Revit, Robot, etc.) to GPU parallelism. Here are the main obstacles:

      1. Architectural differences

  • Most of the "old" systems were developed as CPU-oriented with a sequential computing model.

  • For GPUs, it is necessary to rewrite algorithms for parallel logic, optimize memory access, and change data structures.

      2. Major refactoring needed

  • ANSYS/Abaqus solvers consist of hundreds of thousands of lines of code. The FEM and postprocessing modules are closely tied to each other.

  • Porting to GPU requires a modular architecture, allocation of a "core" for parallel operations, implementation of new APIs (CUDA, OpenCL). This is a long and expensive process.

      3. VRAM capacity limitation

  • Old programs are used to storing huge sparse matrices or grids entirely in RAM. And the new RAM + VRAM approach requires new approaches to writing program kernels.

       4. Support and Compatibility

  • Large systems (Revit, ANSYS) have ecosystems of plugins and modules from third-party developers.

  • Any radical change (adding AI modules, GPU engine) breaks compatibility. In addition, separate licensing of GPU functions will be required, which can increase the cost of the product. Almost all plugins will require rewriting with a much lower level of the languages ​​used. There will be a separate article on this point.

       5. Unusual for users

  • Engineering firms accustomed to classical methods may be reluctant to switch to a new calculation method.

  • Training materials and verification of results are required (after all, regulatory standards require proven accuracy).

  • The vast majority of data centers in large construction universities are CPU-based, for them, switching to GPU would mean a complete overinvestment.

       Summary: A complete transition to GPU and neural networks in such monolithic programs requires large investments and thorough testing. In practice, developers implement individual GPU modules (for example, accelerated linear system solvers, AI assistants) without completely rewriting the core, but there is no significant effect from such tools.

 

Conclusion

 

  • When there is not enough video memory, the GPU can use the system RAM, which helps to avoid a crash when VRAM is full.

  • Neural networks (AI modules) are increasingly used for generative design, fast load assessment, and optimization of reinforcement schemes. The GPU is especially effective here due to parallelism.

  • The difficulties of porting classic CAD/CAE to the GPU are related to the code architecture, the specifics of VRAM + RAM implementation, ecosystem support, and plugin incompatibility. That is why ANSYS, Revit, and similar solutions are only trying to integrate GPU acceleration and neural network functions, rather than replacing all traditional algorithms with them.

  • As a result, future solutions will most likely be hybrid: some calculations will remain on the CPU, some on the GPU, and “smart” neural networks will be used for generative design and accelerated assessment, providing faster and more cost-effective modeling of building structures.