fcFEM - FEA from start to finish

About the development of the FEM module/workbench.

Moderator: bernd

User avatar
HarryvL
Posts: 1042
Joined: Sat Jan 06, 2018 7:38 pm

Re: fcFEM - FEA from start to finish

Postby HarryvL » Wed Apr 03, 2019 11:47 pm

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
Posts: 1042
Joined: Sat Jan 06, 2018 7:38 pm

Re: fcFEM - FEA from start to finish

Postby HarryvL » 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
User avatar
bernd
Posts: 8018
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: fcFEM - FEA from start to finish

Postby bernd » Thu Apr 04, 2019 6:11 am

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
Posts: 1911
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: fcFEM - FEA from start to finish

Postby Jee-Bee » 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
User avatar
HarryvL
Posts: 1042
Joined: Sat Jan 06, 2018 7:38 pm

Re: fcFEM - FEA from start to finish

Postby HarryvL » Thu Apr 04, 2019 8:28 am

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
Posts: 1042
Joined: Sat Jan 06, 2018 7:38 pm

Re: fcFEM - FEA from start to finish

Postby HarryvL » Sat Apr 06, 2019 7:08 pm

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
Posts: 1042
Joined: Sat Jan 06, 2018 7:38 pm

Re: fcFEM - FEA from start to finish

Postby HarryvL » Tue Apr 09, 2019 6:55 am

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
Posts: 4755
Joined: Thu Jan 05, 2017 9:03 pm

Re: fcFEM - FEA from start to finish

Postby Kunda1 » Tue Apr 09, 2019 4:40 pm

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.
Want to contribute back to FC? Checkout:
#lowhangingfruit | Use the Source, Luke. | How to Help FreeCAD | How to report FC bugs and features
User avatar
HarryvL
Posts: 1042
Joined: Sat Jan 06, 2018 7:38 pm

Re: fcFEM - FEA from start to finish

Postby HarryvL » Wed Apr 10, 2019 4:27 am

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
Posts: 1042
Joined: Sat Jan 06, 2018 7:38 pm

Re: fcFEM - FEA from start to finish

Postby HarryvL » Wed Apr 24, 2019 4:05 am

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 211 times

Similar result for plate with hole:

fcFEM_Plate_with_Hole_peeq.png
fcFEM_Plate_with_Hole_peeq.png (152.16 KiB) Viewed 211 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.