Remove support for higher-order elements?

[ktbolt]

Use Case

The solver currently supports the following types of higher-order elements

• 10-noded tet
• 20-noded hex
• 27-noded hex
• 8-noded quad,
• 9-noded quad
• 6-noded triangle
• 3-noded line

Problem

Support for higher-order elements increases the code size, complexity and testing support.

Solution

Do we need to support higher-order elements?

Alternatives considered

Retain support for high-order elements.

Additional context

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct and Contributing Guidelines

[mrp089]

I favor retaining the support of higher-order elements. @MatteoSalvador, @vvedula22, happy to hear your thoughts! I'm adding a question mark to the title.

I can only speak for 3D structural mechanics. I used 10-node TET elements for cardiac mechanics throughout my PhD. These elements experience less volumetric locking in quasi-incompressible solids than 4-node TETs. Also, we might want to add more advanced element types in the future that include DOFs outside the nodes (edges, faces, internal, ...).

In any case, we should have at least one test for every element type that we support. The test stokes/manufactured_solution already includes 6-noded triangles. I turned on the test here and got this error: Skipping normal calculation for node 1 in face 'bottom'.

The original block compression test also includes 10-node TETs. I assume it wasn't added in #115 because there were problems with it. Is that correct, @elenasmartinez?

[ktbolt]

@mrp089 @MatteoSalvador Let's keep the higher-order elements then.

There is currently a bug in processing 2D higher-order elements.

[wgyang]

When a high order mesh is used, the face mesh cannot be represented by vtp file. It is written in an unstructured grid (vtu) file. Currently, svFSIplus uses load_vtp to read face files making high-order cases unsupported. Can read_vtp also takes mshtype as input in addition to face type?