Greetings,
I have randomly stumbled upon this FEM project called FEMaster: GitHub - Luecx/FEMaster · GitHub
I have not yet tried it out, but the documentation seems extensive, the syntax is similar to Abaqus and there is support for true shell and beam elements.
I am sharing this here in case the developers of PrePoMax would be open to check the project out, since it could complement the limitations of Calculix solver (shells, beams…).
Have a nice day!
Well, I just using it for two weeks ago and looks amazing. The developer has changed the output to .frd compatible format so the direct integration with Prepomax is ready. There are some features that could complement very well Calculix such as inertia relief and inertial loads if I have understand well.
In order to run in Prepomax, we need to define mesh, material and sections as usual, and define groups of nodes/faces/elements to write then the input cards with the deck editor included in Prepomax. In the Prepomax options I have changed the CCX excecutable for the FEMaster, and in the Analyisis windows adjust a little the job parameters.
The developoer is doing a great job and advancing incredbly fast, he put the .frd result available in less than 10 days, and now is working in no lineal material definition. One feature that point me to start to using is the element shell treatment, he has developed an extra kind of elements (MITC4 and MITC8) that match perfectly other comercials solvers. Sitll I has to test if it improve the simmetry bugs/limitations over CCX
I have made lot of test for integrating in Mecway and now in Prepomax as well, results match exactly those from CaculiX, and the solver is fast, for modal analysis was incredible. It has even support for mutiple CPUs and CUDA (didn´ try yet the CUDA thing)
So it has *SUPPORT instead of *BOUNDARY. Strange. And no *STEP. But of course, similar syntax and true beams/shells make it worth trying.
I have made several cases using different kind of bc to compare including simmetry, tie, rigid body, shells, beams and results match almost exactly CCX and Mecway results. I will try to translate to Prepomax models (the initial work has made in Mecway) and put available so everybody can try it.
I can compare it with Abaqus too, but I would also look for some problematic cases where CalculiX struggles.
Shells with simetry!
Yeah, or some complex finite sliding contact conditions. Plus shells in nonlinear buckling with rigid body constraints and so on.
Basic contact is available but didn´t test it yet. Shells and no lineal buckling can be made, don´t know if with rigid body as well. Be aware that shell elements are named different, and don´t remember if Prepomax gui allow to change the kind of element, so maybe you will have to edit the input file separately, run and import the results.
Yeah, I don’t mind keyword edits. It’s easy to change the element type as long as its topology/connectivity matches CalculiX types. Abaqus also has quite different shell types, e.g. STRI65 instead of S6.
If there is sufficient interest, I could look into supporting the solver directly from PrePoMax.
That would be great, at least at the begiining in the settings options add the solver and the possibility to define the number of cpus to use, so we don´t need to edit the job parameters. We could write the bc cards in the input deck editor until they get implemented in the GUI.
Edited: Would be great also in the postprocessing window if you could identify that the results came from FEMaster and not CalculiX to avoid mistakes.
Hello Matej, Sergio and others,
i am the author of FEMaster and would absolutely love to assist you in anyhting you could need for this if you decide to do it. Regarding a few comments on this channel and maybe some background. I was working in Munich during my bachelors degree at MTU (thats where Guido Dhondt, author of calculix worked as well). I had some insights into calculix and read the book from Guido Dhondt. I thought that I could do those things myself in a modern c++ object oriented framework.
The fact that I used *SUPPORT instead of *BOUNDARY is probably a blunder and i could just add the compatibility for that. The fact that I didnt use *STEPbut *LOADCASE is also a blunder probably. If it simplifies things for you, I am happy to use other keywords.
But i decided actively to move away from certain keywords that abaqus and calculix use, for example the *CLOAD, OP=... bothered me greatly.. I dislike carrying loads from one step to another. Instead I went with the Hypermesh option of load-collectors and support-collectors which contain loads and supports and can be referenced from the steps.
Also one major flaw inside CalculiX/Abaqus is that *TRANSFORM is applied onto nodes which means that you cannot apply a load and a support in different coordinate systems onto the same load. In FEMaster i didnt do that but instead apply it onto loads and supports directly.
Another thing is constraint handling in femaster. Ill be honest: The nonlinear solving is a little bit weird at the moment and all the constraints are built to work in a linear analysis. Nonlinear tie does probably work but nonlinear connectors will probably be messy when the rotations get large (ill work on this asap). But I dropped the assumption that calculix and abaqus made which is that a slave-surface can only be used once as a slave. I have different way to handle constraints. ELIMINATION is what abaqus and calculix use. its very fast but has this limitation. Alternatively one can use NULLSPACE which is numerically a little bit worse but can deal with cyclic constraints. Also there is LAGRANGE which is viable in some cases…
Best,
Finn
If your inp not compatible, better write something at the beginning, like:
** femaster inp
** Ver 1.0
Or your *model is a new card only for your inp?
Can someone point me to the FEMaster documentation? I will compare it using AI to the Calculix documentation to get an overview of the needed changes.
The user manual is here: FEMaster/documentation/document.pdf at master · Luecx/FEMaster · GitHub
Ill give a quick update for you, as things are moving pretty quick at the moment and I am unable to catchup with all the things to implement. I have implemented the foundation for nonlinear material models so that should work in the future. But I was adding things a bit too quick and im taking a step back and documenting and reworking existing parts of the code. I will also get rid of the standard S3, S4, elements and replace them with a modern version which also supports nonlinear analysis. at the moment only the MITC4FRT supported nonlinear analysis and actually solves the Raasch-Hook accurately. Once I have the shells done, Ill get to contact and make a more robust contact implementation. The current one is just awful… Ill keep you updated here! Should take me 1-2 weeks for perfect shells 
Yeah thats probably a good idea!
@Matej and @Luecx , one of the point of interest of this new solver for the CalculiX user would be the real shell elements, so an important point would be the possibility of show in postprocessing bottom/midplane/top stress, that are not available in CCX so the postprocess code should be adapted there.
CalculiX also has these “section points” through the thickness for output, but only for the one true shell user element not supported in PrePoMax yet. But this feature could be helpful for it as well.
