under the GNU profiler to recognize in which routines the C3D15 have been used, further I also did a complete search for all places where C3D15 had been implemented in
Clever way! That would have given you a lot more confidence than trying to walk through it all by hand.
I don’t think it’s too big of a deal if there are some bugs. They’ll get discovered soon enough and can be fixed one by one. If it makes it into official CCX, I’ll be making my own set of test cases too.
Thanks for spending the time on such a useful (from my POV) piece of work!
@vicmw
During the implementing of the pyramid element I got by incident implement an error in the 2’order wedge element which I just have discovered with a test of the pre-tension card.
I actual don’t who are using my pyramid code, but if you should need the updated source code and the windows exe you can get it at the link in the beginning in this thread.
I’m not using it but I have code to generate / read solution with these new elements for CCX and hope Guido includes it.
I just ran my big set of test cases on it and found these failures. I only had a quick look so let me know if you need more details.
Thermal doesn’t work but I’m not sure if you intended that or not.
CCX S30 density.inp CCX_S30_density.inp - Pastebin.com C3D5 Small difference with with gravity compared to collapsed hex and Mecway’s internal pyramids. Not sure if it’s worse or better.
@vicmw
I really appreciate your test files. It helps a lot to have to alternative input in order to make verification test.
I’ll return when I have looked into your test files, which I really have had time to look into yet, but in advance I also would like to refer from “Advanced Finite Element Methods” by Carlos Felippa, that some discrepancy should be taken into account when running tests with few elements.
I think that since pyvista supports the .frd format, it is worth adding support for these unofficial element types (C3D5 and C3D13 pyramids) to pyvista:
There is no such plan at the moment (for the near future at least). Adding new elements is always quite an effort, since you have to make sure they work with all the available features. I haven’t looked in detail at the maturity of the code in the PR though.
Has anyone tested the implementation lately?
How is the implementation status?
How do the results compare to Abaqus / other solvers?
Some pre-processors would create them by default, unless you tell it to split pyramids into tetras.
In my case not as important because I generally try to request the pyramids are split into tetras. But I’ve received models that have pyramids and it would certainly make it easier to compare if the element is available.
This is mostly useful in Cfd for perfect transitions by simple to complicated parts.
Other FEA-Codes use Contact elements from quad to tri at face of simple section to complicated section.
The mesher should make same nodes and 2 tri to one quad for good interpolation of nodal and elemental results.
A hex mesh needs only 1/6 elements for same Tetraeder with better numerics inside.
Important is here a possible good contact from hex8 to tet10 elements with mixing first order and second order parts.
So an alternative is a simple and good contact management of parts with full „welded“ contact.
Good Meshing for good contact elements is here essential and good interpolation and robust Implementation of contact by solver.
Intelligent partitioning is here important for good performance at multithreaded cpu or gpu.
