You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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'.
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?
Use Case
The solver currently supports the following types of higher-order elements
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
The text was updated successfully, but these errors were encountered: