fcFEM - FEA from start to finish

About the development of the FEM module/workbench.

Moderator: bernd

User avatar
HarryvL
Veteran
Posts: 1283
Joined: Sat Jan 06, 2018 7:38 pm
Location: Netherlands

Re: fcFEM - FEA from start to finish

Post by HarryvL »

Here some details for 3 solvers, based on the plate with hole (~3000x600 matrix after reducing bandwidth):

Code: Select all


Matrix Decomposition:
scipy.linalg.cho_factor: 0.379205942154 [s]
cholmod.cholesky: 0.0120160579681 [s]
scipy.linalg.cholesky_banded: 0.0381510257721 [s]

Solution (single iteration):
scipy.linalg.cho_solve: 0.0155708789825 [s]
cholmod.factor.: 0.000778913497925 [s]
scipy.linalg.cho_solve_banded: 0.00293803215027 [s] 



Clearly the CHOLMOD C-routine wrapped with Cython by the scikit-sparse library is by far the winner. If the solution time would be dominated by the iteration process (which I expected) then the CHOLMOD routine should be up to 20 times faster than the standard Scipy Cholesky routine. In actual fact the 10 load steps take approximately the same time for all solvers, indicating that I should look for a Python bottleneck that is common for all.
Last edited by HarryvL on Thu Apr 04, 2019 12:06 am, edited 1 time in total.
User avatar
HarryvL
Veteran
Posts: 1283
Joined: Sat Jan 06, 2018 7:38 pm
Location: Netherlands

Re: fcFEM - FEA from start to finish

Post by HarryvL »

I just checked. The 10 steps involved 152 iterations. The actual number crunching should therefore only account for approximately 152*0.00078 = 0.12 seconds, whereas in actual fact the 10 load steps take almost 70 seconds. Clearly scope for improvement in my Python admin :D
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: fcFEM - FEA from start to finish

Post by bernd »

HarryvL wrote: Thu Apr 04, 2019 12:05 am ... actual number crunching ... 0.12 seconds, ... 10 load steps ... 70 seconds. Clearly scope for improvement in my Python admin
:shock:
Jee-Bee
Veteran
Posts: 2566
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: fcFEM - FEA from start to finish

Post by Jee-Bee »

HarryvL wrote: Thu Apr 04, 2019 12:05 am Clearly scope for improvement in my Python admin :D
It's a pity that ipython isn't shipped with FC. in that case

Code: Select all

%timeit func
would help to see the bottleneck
see https://scipy-lectures.org/advanced/opt ... index.html
User avatar
HarryvL
Veteran
Posts: 1283
Joined: Sat Jan 06, 2018 7:38 pm
Location: Netherlands

Re: fcFEM - FEA from start to finish

Post by HarryvL »

Jee-Bee wrote: Thu Apr 04, 2019 6:50 am
HarryvL wrote: Thu Apr 04, 2019 12:05 am Clearly scope for improvement in my Python admin :D
It's a pity that ipython isn't shipped with FC. in that case

Code: Select all

%timeit func
would help to see the bottleneck
see https://scipy-lectures.org/advanced/opt ... index.html
Thanks. I will have a look at this.
User avatar
HarryvL
Veteran
Posts: 1283
Joined: Sat Jan 06, 2018 7:38 pm
Location: Netherlands

Re: fcFEM - FEA from start to finish

Post by HarryvL »

HarryvL wrote: Thu Apr 04, 2019 12:05 am I just checked. The 10 steps involved 152 iterations. The actual number crunching should therefore only account for approximately 152*0.00078 = 0.12 seconds, whereas in actual fact the 10 load steps take almost 70 seconds. Clearly scope for improvement in my Python admin :D
Well, I have managed to reduce the overhead timing by a factor of 4, but it comes at a price. I had to move chunks of code to Cython and give up on the compactness and elegance of numpy in a few places. For example, I find that np.dot is much slower than Cython for loops. I follow what I can find on Google, but may still do something wrong. Anyway, the efficiency hunt continues.
User avatar
HarryvL
Veteran
Posts: 1283
Joined: Sat Jan 06, 2018 7:38 pm
Location: Netherlands

Re: fcFEM - FEA from start to finish

Post by HarryvL »

I did some further work on this and managed to reduce the time taken for 10 load steps (~150 iterations) by a factor 12 compared to my version based on NumPy alone. The main bottlenecks were the stress and load update functions. In both the function Shape10tet was causing the hold up and in there it was the calculation of the Jacobian and the global derivative of the shape functions. I did 2 things to improve this, i.e. 1) combine the stress and load updates in one function, thus only requiring one call to Shape10tet per iteration, rather than two and 2) rework the combined function with Cython, using all the really good advice here: https://cython.readthedocs.io/en/latest ... y-tutorial
I think I have taken this as far as I can with my limited knowledge of C and compilers and will move back to doing some finite element work.
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: fcFEM - FEA from start to finish

Post by Kunda1 »

HarryvL wrote: Tue Apr 09, 2019 6:55 am I think I have taken this as far as I can with my limited knowledge of C and compilers and will move back to doing some finite element work.
Very cool. If you get it optimized enough (as you are reporting) moving on makes sense since perhaps someone can come along and improve on it later once you release it.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
User avatar
HarryvL
Veteran
Posts: 1283
Joined: Sat Jan 06, 2018 7:38 pm
Location: Netherlands

Re: fcFEM - FEA from start to finish

Post by HarryvL »

HarryvL wrote: Tue Apr 09, 2019 6:55 am ... thus only requiring one call to Shape10tet per iteration, rather than two ...
just to be precise: stress update is called for every integration point once for every iteration. As there are 4 integration (Gauss) points per finite element and this mesh has 453 finite elements, the total number of calls is:

#calls of Shape10tet = #total iterations * #elements * #Gauss points ~ 150 * 453 * 4 ~ 272000.

As Shape10tet performs many floating point operations to multiply and invert (relatively small) matrices, efficiency of array operations matter.

I have an idea to drastically cut down on the calls to Shape10tet, but this would only be valid for geometric linear problems (still allowing plastic collapse calculations, but not non-linear buckling for example). This can then be linked to a user option, geometric non-linearity yes/no. I expect this may achieve another order of magnitude speed improvement for small displacement and plastic collapse analysis.

PS: as it stands the current version is already faster than I ever achieved on a main frame computer with FORTRAN on a problem this size :D :ugeek:
User avatar
HarryvL
Veteran
Posts: 1283
Joined: Sat Jan 06, 2018 7:38 pm
Location: Netherlands

Re: fcFEM - FEA from start to finish

Post by HarryvL »

Working on equivalent plastic strain and ductile rupture criteria for steel.

Threshold value of equivalent plastic strain in failing trench shows development of a slip surface:

fcFEM_Trench_very_fine_peeq.png
fcFEM_Trench_very_fine_peeq.png (168.41 KiB) Viewed 1335 times

Similar result for plate with hole:

fcFEM_Plate_with_Hole_peeq.png
fcFEM_Plate_with_Hole_peeq.png (152.16 KiB) Viewed 1335 times

To judge acceptability of a design beyond first yield, ductile rupture needs to be considered. For this I will implement a ductile rupture criterion. Stay tuned in.
Post Reply