fcFEM - FEA from start to finish

[kkremitzki]

In terms of an internal solver, libmesh seems very promising. It's LGPL-2.1 and in C++.

[looo]

In terms of an internal solver, libmesh seems very promising. It's LGPL-2.1 and in C++.

-1 in terms of maintainability of freecad and flexibility of the simulations;) Python is definitely the better way. Look how fast HarryvL shows new results...

[bernd]

In terms of an internal solver, libmesh seems very promising. It's LGPL-2.1 and in C++.

-1 here too, apart from someone pays my monthly salary for half a year and I can learn C++ as good as I know Python ...

[PrzemoF]

What about speed? I mean I don't like C++ (*), but the python flexibility comes at a huge speed penalty.

(*) the only language I wanted to learn and I gave up when I realised if feels like a bunch of workarounds one on top of another. And then one more to fix it.

[Jee-Bee]

-1 here too, apart from someone pays my monthly salary for half a year and I can learn C++ as good as I know Python ...

start with this one :p https://www.coursera.org/learn/finite-element-method

[looo]

What about speed? I mean I don't like C++ (*), but the python flexibility comes at a huge speed penalty.

(*) the only language I wanted to learn and I gave up when I realised if feels like a bunch of workarounds one on top of another. And then one more to fix it.

As said, slow parts can be ported to c++ if it makes sense. But for most parts python has fast ways (matrix solving, eigenvalues, and other matrix operations). I guess the slow part is the assembling of element entries in global matrices. If elements are defined by classes it should be possible to reimplement these classes in c++ and create python representations with pybind11.

Also with modern c++ and eigen c++ doesn't differ a lot from python and numpy. But in my eyes python is the right tool to create and design such a library.

[HarryvL]

Just some views on the various topics debated:

LANGUAGE

I wrote my very first finite element program in BASIC on a Commodore 64. It was severely restricted in terms of speed and size, but it did the job and it beat the alternative of solving the partial differential equations by hand or working on a terminal in university with pedantic system administrators looking over my shoulder on CPU seconds spent, use of clunky graphical terminals and boxes of erroneous orint outs. The comfort of doing this at home with full flexibility, easy extensibility and printing and plotting devices at my fingertips was well worth the hit on performance. It was actually good fun to see how to simplify problems without loss of accuracy. Elegance over size and speed, so to say. And I managed to do elasto-viscoplatic tunnel collapse analyses with hardening and softening plasticity on my C64. And also 3D axi-symmetric elastic analyses. None of that ran for more than a few seconds. When I printed the source code for this in my final year report I found that serious (mainframe computer) academics who frowned upon game computers were starting to copy it. My first FOSS projectI guess.

When I joined a professional FEM development team I had to learn FORTRAN, which wasn’t a big deal. Like in other language you simply cut and paste chuncks of code and take it from there. The time spent in FEM development is not in the coding. It is in the mathematical Modelling and the testing and debugging. I can tell you, the complexity of the FEM codes I ever did or was involved in is far, far less than what I see in any freeCAD module. Anyway, I write about 4 special purpose FORTAN FEM codes in my life and they still work and I can still read and extend them. It’s just about using meaningful variable and function names and putting a lot of comments (something we don’t have enough of in freeCAD IMHO). I have tried C and C++ but for me that is 1 step away from machine coding (which I also did on the C64) and is fun but IMHO not very productive for getting to a quick FEM result.

PYTHON was not love at first sight for me. It felt like something more suitable for string manipulation than for scientific programming, but since the I found that there is large community of scientific users who developed massive libraries of super fast routines (written in C++) that can simply be imported into Python code. There are many speed comparisons out there showing that smart use of those routines gives you speed comparable to native C++ code. Google “Jake Vanderplas”. So, although I am not a Python geek (yet) and I oftentimes wonder if the OOP paradigm is not carried too far (leading to Russian doll code), I am convinced it is the future for engineering physics programming.

PRE AND POST PROCESSING
From the first start with my C64 I have been looking for ways to make input and output more efficient. I put in place XML type input and did output on a tiny plotter. After joining the development team we moved to Turbo Pascal for input and output, but I never liked the use of calls and files between two separate programs. Also here Python offers links to cutting edge graphical routines.


Anyway, too many words already, but in summary, I think Python is the perfect way (for me) to tap into a huge resource base of cutting edge routines and allows you to focus me the bits that really matter (to me).

[HarryvL]

I guess the slow part is the assembling of element entries in global matrices. If elements are defined by classes it should be possible to reimplement these classes in c++ and create python representations with pybind11.

Also with modern c++ and eigen c++ doesn't differ a lot from python and numpy. But in my eyes python is the right tool to create and design such a library.

I am planning to profile the code and report out on where time is spent. Clearly, solving the matrix equations is the most computationally intensive, but here is where NumPy/SciPy comes the rescue. Including smart use of preconditioning with classical techniques, like Cuthill McKee band optimization (also available as a routine in SciPy btw). Assembly of the global stiffness matrix is not normally the most intensive, but involves a lot of loops. Here I Need to focus on maximizing use of masking, matrix multiplication and list comprehension instead of dum loops. Suggestions on cutting out for loops are welcome.

[Jee-Bee]

how much would cython improve the speed?
https://cython.org and https://www.youtube.com/watch?v=FepqwPI ... gs=pl%2Cwn (i guess)

[HarryvL]

... it will require duplication of element nodes on selected internal faces, but that should not be too hard.

yeah sure Harry. I need to duplicate faces and tried Boolenfragments Mode: Split, but that does not give the desired result. In fact all three mode types give exactly the same mesh. In all three cases the report view just says “Part to mesh: ... ShapeType —> Compound”. Is there a way to force duplicate element faces at a contact? I tried a simple Part>Compound of two separate Compsolids, but that won’t guarantee the element faces will be lined-up at the contact (right?) ... which is a must for interface elements. I also read about GMSH physical surfaces and wanted to specify that in the geo file, but can not locate that file (or the tmp directory for that matter) on my hard disk. Does it get deleted after use?