4 ms·
At one point I was doing a PhD in programming a custom FEM program written in Java. I ended up not completing that program, but have been using FEM for many yea
by mechhacker 7y ago
At one point I was doing a PhD in programming a custom FEM program written in Java. I ended up not completing that program, but have been using FEM for many years to design things.
One of the ways I play around with programming languages is try to make a small Finite Element solver. I think so far I've made them in Matlab, Python, JavaScript, and Rust. Maybe I made one in C or C++ as well.
Whenever I do, I realize that a lot of the barrier is getting good Matrix solving tools in that language. Rust was a bit difficult because I was forced to choose between 1 or 2 main linear algebra codes. However, these codes are not optimized and will not be as fast as the Fortran based codes that a lot of the Python libraries now reference (LAPACK and BLAS if I rembember correctly).
It comes down to how you store the information in the Matrix. Physical problems solvable by FEM are symmetric and linearly independent, or some tricks are done to make them so. They also end up being quite Sparse. Those Sparse solvers from LAPACK and BLAS, as well as all of the past optimizations that are probably made for dealing with cache size (I'm speculating here, I really don't know), really make a huge difference in the problem.
Last I touched the Rust libraries to make a simple code, I just stuck with non-sparse solvers. There's an enormous difference between storage size and computational effort to go through a non-sparse matrix in comparison, especially when the problem is large. I think past a few million degrees of freedom on typical mechanical engineering problems, it started to become unmanageable on a local cpu.
- InfinityByTen 7y agoThere are tons of solvers, there're a lot of libraries and SciPy, Fenics, most likely even MATLAB, Octave, FreeFEM++ all of them use LAPACK and BLAS (at least in their most performant flavours), all calling eventually the FORTRAN subroutines written decades ago. And yes, the tricky parts of this is also that how Fortran and C store 2D arrays, https://en.wikipedia.org/wiki/Row-_and_column-major_order https://en.wikipedia.org/wiki/Row-_and_column-major_order. So no one re-writes their own stuff, unless for academic purposes. I was on the verge of trying to extend the SciPy library to support block matrices 4 years ago for my thesis, but was able to work around it because duck-typing had generalised quite enough to encapsulate even that. Sparse and Full matrices have a totally different data structure. hence the difference in the solvers. Engineers and Mathematicians that want more performant solving, rely more on the modelling of the problem (physically or mathematically) than improving the solvers.The other option is hardware-assisted optimization. For full solvers, I suppose the AI/ML folk have come up with TPUs, also because they have different tolerances for floating point calculations in classifying an image compared with launching a satellite on Mars.
- dwohnitmok 7y agoThe most performant BLAS implementations are actually generally written in C and Assembly these days with a Fortran wrapper. So you can have a weird sandwich of C -> Fortran interface -> C in your code.
- alimw 7y ago> So no one re-writes their own stuff I have (unwillingly) had to do this. I did look at off-the-shelf solvers but they all seemed to restrict themselves to nice domains in low dimensions. Edit: Perhaps you are only talking about the linear algebra "stuff". I did use SciPy for that.
- chalst 7y agoThere are well-maintained wrappers for BLAS & LAPACK in Rust https://github.com/blas-lapack-rs/blas-lapack-rs.github.io/wiki https://github.com/blas-lapack-rs/blas-lapack-rs.github.io/w...
- mechhacker 7y agoThank you! Noted. I may want to play around more with Rust finite element coding.
- sandoooo 7y agoIt's a widely-used and widely-studied method, so the popular implementations are pretty optimized and the toolkits extensive. Unless you have some fundamental insight/optimization specific to your problem, I don't think it's actually worth it to roll your own. Easier to just start with something open sourced and build a small module on top. Nvidia is rolling FEM into Physx[1] - exciting stuff! GPU-accelerated FEM is going to be a game changer if they didn't cut too many corners in the pursuit of speed. I wonder if it can be coupled with FleX... [1]: https://news.developer.nvidia.com/announcing-nvidia-physx-sdk-5-0/ https://news.developer.nvidia.com/announcing-nvidia-physx-sd...
- yiyus 7y agoIt's totally worth it from a pedagogical point of view, both to learn the FE method and to learn the programming language.
- doczoidberg 7y agoIs Physx and Flex also for engineering issues but only for game physics?
- sandoooo 7y agoIt depends. The difference vs traditional engineering software is in how much deviation from reality there is, and how much you can tolerate. Both of these depends on what exactly you're simulating and what sort of results you're looking for. For example, Nvidia published a paper a while ago using Flex as a simulation environment for training AI to perform robotic tasks: https://www.roboticsbusinessreview.com/ai/nvidia-researchers-unveil-concept-to-close-simulation-reality-gap/ https://www.roboticsbusinessreview.com/ai/nvidia-researchers...
- madengr 7y agoI was recently testing a commercial FEA package that uses Intel MPI libraries. It is 30% faster on an i7 vs the equivalent core/clock AMD. Another FEA package that does not use Intel libraries has no measurable difference between the two processors. Waiting for the i10 to come out, with the 5.2 GHz boosted clock, as most of my software has diminishing returns after 4 cores.