FEM for 3D Tet mesh

[EmJay276]

Are you interested in me implementing the FEM for 3D Tets?

I already have a working version for every element type using gmsh.
You probably want to stay with numpy / scipy only, correct?
If you don't need it next week, I can adapt it (for linear elastic tet elements) to only use numpy/scipy 😀.

• Can you give me some hints where to find existing code/functionality for 3D Tets in gpytoolbox?

• Do you use voigt notation for stresses/straits?
  

• Or diagonal notation for stresses/straits?
  
  (only relevant for anisotropic materials)

[sgsellan]

Hi! We would definitely be interested.

A very easy place to start incorporating tet FEM to gpytoolbox is all the massmatrix, massmatrix_intrinsic and cotangent_laplacian functions, that we have not yet extended to tetrahedral meshes. Our current convention for these meshes (which is chosen so they can be displayed with polyscope) can be found in regular_cube_mesh and volume.

After that, the obvious next step would be linear_elasticity and linear_elasticity_stiffness. These are intended to be lifted from their respective Matlab implementations (here and here), so I don't expect it to be hard (I believe it uses Voigt notation).

Another eventual issue will be writing a reader and writer of tetrahedral meshes (our current write_mesh is triangles only). @odedstein wrote our fabulous triangle mesh reader and writer, he probably knows better how trivial it is to extend to a few usual tet mesh formats.

Let us know if we can help!

Edit: Oh, and I forgot to answer two of your questions: yes, we would like everything to be numpy/scipy-based (like our triangle mesh FEM implementations). And no, we definitely do not need it next week :-)

[EmJay276]

Thanks for the fast reply!
If I understand correctly, there is currently no read_mesh and write_mesh available for 3D elements, right?

Some more questions to restrictions of the FEM

• You will probably stay with 3D Tets only, right? So no Hex / Wedge / ... elements. (Perhaps convert them to Tets when importing?).
• Do you want to be able to extend the FEM to quadratic (or higher) order elements (with a linear elastic material), or just stay with linear elements? For linear Tets I have a analytic solution of the stiffness matrix, for higher oder we will need Gauss integration, which is slower.
• Should the number of Gauss integration points be user definable? Or always use the minimum number of Gauss points for an exact integration (won't matter for linear tets, only for higher order).
• 3D linear Tets only makes life much easier, but they should be avoided if possible due to locking effects. Quadratic Tets fix most of the problems, I would suggest implementing linear and at least quadratic tets (user definable if linear or quadratic calculation is done).

[sgsellan]

Indeed, there is currently no read_mesh and write_mesh for 3D elements (@odedstein may contradict me in case this is not true).

I don't think we have any powerful reason to restrict ourselves to linear, tetrahedral elements, but for the fact that they make life much easier. Thus if I were writing this, I would start by doing linear tets, then quadratic tets, then other elements. As long as (like you say) the user can easily know what they're calling and it has a reasonable default, I have no opposition to the code being richer and would be happy to merge it. I have no strong opinions on any of the other points you raise

[EmJay276]

Ok thanks, then I will write the methods to make them easily extendable and annotate where it can be done.

[sgsellan]

Sounds good! Looking forward to it :-)

[EmJay276]

@sgsellan @odedstein
I did some research on 3D mesh formats. I didn't find any commonly used file format (please correct me if I'm wrong).

I would suggest to use the gmsh .msh format ( https://gmsh.info/doc/texinfo/gmsh.html#Gmsh-file-formats ).
It seems well documented and if I keep my data structure compatible with the gmsh node/element structure, I can reuse most of my existing code.
It would also be much easier to extend to different element shapes and types.

Does this sound reasonable to you?

[odedstein]

I like the gmsh .msh format. I think it's a reasonble choice.

[EmJay276]

Just an update for you, im currently working on the gmsh importer (works fine already). I hadn't much spare time recently.