shell element in CalculiX is a continuum element (except user element), the benefit is speed up in modelling and problem setup. the solver does normal extrusion during process, however some knot are generate in such a condition and it may cause a problem. another disadvantages are in locking phenomena and analysis type can be applied.
i always try to modeling with pure solid element to avoid any unexpected problem and result. in case of thin structures i do it all inside Salome CAD/CAE by EDF (thanks PrePoMax for support UNV files). is quite straight forward in converting meshed shell element to solid, user only required to define the thickness and number of layers. Salome will do the rest, also for intersection or overlapped.
pictures below are an example of my workflow, it could be a great features if someday PrePoMax can do the same things.
PrePoMax (as well as Salome) uses an external program to generate a mesh. Due to this reason, mesh generation capabilities of PrePoMax are limited by the same capabilities of Netgen. Salome uses several meshers, some of them (like Gmsh) allow mesh to be extruded.
right, both Salome and PrePoMax use the same mesher (Netgen) and can be set to quad dominates. in above approach i’ve done without Gmsh mesher, only Salome mesh modules which capable to do post processing in extrusion of shell element after mesh is generate.
The extrude capability will be added in the future. Since it is a simple operation it can be added without any special software but probably I will try to incorporate the GMSH in the future. I do not know how at the moment, because I am a beginner at using GMSH but I will figure something. I would like to run the GMSH in the background but then I will have to redo all the user interfaces…
great news GMSH also interesting to incorporates, but it seems could be double feature in many capabilities (unnecessary) since current PrePoMax was able to do meshing 3D and 2D using internal mesher (Netgen,MMG).
the file size in distribution will be larger also, may the workflow is only required by simple calling the exe and arguments. this can be a generic ways and CGX or OCC-CSG also can be incorporates.
this features are advanced due to parametric capabilities of models geometry and/or meshing, boundary condition (by group of nodes or faces)
PrePoMax is required to capable reading the geometry files (IGS,STP,BRP,STL) produced by GMSH (also OCC-CSG & CGX) or mesh files (INP,UNV) produced by GMSH (also CGX) by calling external exe and command arguments (script files). this methods may similar to calling CCX and read FRD files which has been implemented.
GMSH will be added to support hex-based meshing. As said, extrude is a simple process but it only solves a very specific problem. A more general solution to prepare hex-based meshes is needed in the future. So for me, it is more time-efficient to create a more general feature once than to add many specific features which will be replaced in the future. Unfortunately my time is (very) limited
so GMSH will replacing a current Netgen mesher? may i agree, it’s the right path since hex dominant meshing continue improved by the developer teams. even i did not know much about how is complex the integrationn in PrePoMax.
bellow are the progress of the developer teams, seems high quality automatic hex-dominate is not too far.
Well, I think I will keep the Netgen because PrePoMax uses it for geometry processing. The current netgen includes additional features (added by me) that enable different geometry manipulations like import, changes in normals orientations, surface divisions, compound parts… GMSH would initially be used only for hex/hex dominated meshing.
I really like the progress in hex messing and I am following it using the https://www.hexalab.net/ But many of the solutions are really slow, hard to compile, Linux based only, …
currently there’s a workaround to extrude surface to solid in normal extrusions by converted in the solver CalculiX. After solid mesh in generates, PrePoMaX is capable to export the mesh results in INP format and imported back.
it’s also capable for multi-layer options with number of element trough thickness. However the nodes are actually separated and need to merge or connected to become continuous.
I was using this method to test it previously, but I think the layer mesh does not use merged nodes. So to fully use the feature a merge nodes feature in PrePoMax is missing.
You can also use the Check Model function to see the thicknesses of all applied shell sections.
indeed, PrePoMax “Check model” feature is useful for shell thickness definition visually in 3D. The process need to run CalculiX solver which probably using *No analysis functions.
This also can be more useful for the future of beam element implementation, actual shape, dimensions and orientation can be seen visually as is.
Specifically for this, it is currently only possible to visualize the rectangular and elliptical cross sections in the *.frd file output. The pipe, box, and general cross sections are expanded to rectangular C3D20R with different integration point schemes to account for each specific shape.
If someday this will be a feature of PrePoMax, it would need to be an internal feature, both for pre and post-processing. My suggestion would be to run the analysis twice, one time for section forces (OUTPUT=2D) and another one for stresses (OUTPUT=3D) and to combine both results in the visualization with internally generated cross-sections. However, I am pretty sure this is very hard to do and many other features are higher on the priority list.
when i try to follow CalculiX beam and shell implementation from previous and old versions, it seems the direction is to represent by solid element. Shell element approach is using multi layered method and beam element using composed (patch), which can be arbitrary in shapes. Later implementation in beam element is pipe and box section shapes using different approach, but it’s not from the main developer.
Since the shell and beam element is represented by solid element, an output 2D may be problematic. Some request for internal force output for shell element by integration has been proposed by community in the past, but later is implemented for solid element instead by *Section print function.
It seems output of internal section force are already available from classical shell and beam formulation, then both element is implemented in versions later. Currently, an output 2D for shell element expected for internal force, but actually is not something like these.
Beam and shell element in CalculiX is a novel approach by the original author, i.e not the same and available in another FE solver. It’s unique and have advantages and some disadvantages, beam is not yet completed at implementation but usable. The theory is mixing of continuum and classical element by introduced a knot at some condition in connecting.
Yes… I think the best would be to have both implementations. The expansion is very powerful because one can simulate every single analysis type originally coded for solid elements, but the classic approach of beams and shells is also a reliable and very spread utilization across the FEM community. In my case, I would only need classical elements (which could be way easier to set up correctly due to the vast list of problems in rotational DOFs) but I’m pretty sure somebody out there uses expanded beams for more complex analysis.
Maybe someday the currently very limited classical formulations of shells and beams will be upgraded. Wish I could have enough time and programming knowledge to help in this regard.
finally, this feature has been well done implemented. It uses base of existing mesh to be further in extrusion along normal direction. Almost perfect for Iges/Step surface part combined with Quasi-structured quads, also can be useful for 2D Stl files with Frontal-Delaunay for quads (simple) algorithm selection.
So many thanks and hopefully enjoyable the usefulness for everyone also.
The Thicken shell mesh currently uses normal directions computed from the FE mesh, sometimes leading to unprecise results. That is why I plan to compute the normals from the geometry using Gmsh API.
To get the sharp angle working (left image), I have to exchange the mesh-based normals with geometry-based normals, which I am working on.
For the “manifold” geometry, this will be a much harder nut to break. Here, you have three surfaces connected to a single edge. What if there are more or if there is a vertex with many faces connected at a different angle? It might be problematic.
