fcFEM - FEA from start to finish

[HarryvL]

So that wasn't too hard. SImply put the compiled ".so" file in the .FreeCAD/Macro directory and import the relevant function from that. For the first 10 load steps of the plate with hole (my defacto benchmark) I get a marginal improvement in speed over the dense matrix Cholesy solver in SciPy. Next I will experiment with Reverse Cuthill McKee to see how I can reduce the bandwidth and its effect on banded solver speed.

[HarryvL]

Urrrrr, I just calculated the number of degrees of freedom (DOF) and the band width (BW) for the plate with hole and find they are almost equal: DOF = 2990 and BW = 2970. Clearly the node numbering is hugely inefficient. I don't understand why GMSH doesn't produce a more efficient numbering. Anyway, this explains why use of sparsity doesn't matter and give hope that pre-conditioning (reverse Cuthill McKee) will help a lot.

[Jee-Bee]

Could it be that the node numbering have something to do with 'c' numbering or 'f'(fortran) numbering? I guess that's true also with cxx...
see numpy example https://docs.scipy.org/doc/numpy/refere ... shape.html

[HarryvL]

It’s simpler than that @Jee-Bee. The structure of the global stiffness matrix is S[3*i,3*j], which is 0 except when i and j are nodes that belong to the same element. So it is essential to number the nodes such that the difference between node numbers within one element is minimal. The smaller the bandwidth=3*max(j-i) the better for storage and speed. I am surprised that GMSH doesn’t optimize node numbering in such away.

[bernd]

It’s simpler than that @Jee-Bee. The structure of the global stiffness matrix is S[3*i,3*j], which is 0 except when i and j are nodes that belong to the same element. So it is essential to number the nodes such that the difference between node numbers within one element is minimal. The smaller the bandwidth=3*max(j-i) the better for storage and speed. I am surprised that GMSH doesn’t optimize node numbering in such away.

Best to ask in the mailing list. The main developer arre there too. They will for sure give a reason or tell us a meshing parameter we need tu use to archive this. I understand what you mean but it is difficault do explain to others.

[Walgri]

It looks like GMSH is left without node reordering by design: http://onelab.info/pipermail/gmsh/2008/003717.html
Plus, partially offtopic, is see no trace of node reordering in the OOFEM manual.

Mhmmm, maybe we need a general node reordering intermediate step before writing input files and reading back the results ?

Edit: April 30, 2019
OOFem DOES node reordering either by a command line switch, or by an option in the input file, ref: http://www.oofem.org/forum/viewtopic.php?pid=334#p334 and http://www.oofem.org/resources/doc/oofe ... node8.html .

Strangely enough, a Google search for the keyword renumber in the entire Oofem website brings zero results.

[HarryvL]

I am pretty sure CCX reorders “under the hood”. Anyway, I thought of a simple way to do so and will work on implementing this.

[Jee-Bee]

Intersting topic? http://www.geuz.org/pipermail/gmsh/2008/003840.html

[HarryvL]

Interesting. I hit the same problem. Hence, this renumbering in my code: https://github.com/HarryvL/fcFEM/blob/c ... #L244-L254

[HarryvL]

Urrrrr, I just calculated the number of degrees of freedom (DOF) and the band width (BW) for the plate with hole and find they are almost equal: DOF = 2990 and BW = 2970. Clearly the node numbering is hugely inefficient. I don't understand why GMSH doesn't produce a more efficient numbering. Anyway, this explains why use of sparsity doesn't matter and give hope that pre-conditioning (reverse Cuthill McKee) will help a lot.

Well, I managed to reduce the bandwidth by a factor of 5 with reverse Cuthill McKee, but I doesn’t make any difference for the solution time . The search continues.