I have spent some time experimenting and refining my process for compound shell meshing and calculations after this post:
There appears to be great inconsistency in the relation of PrePoMax and Calculix solver. To keep this as short as possible it comes down to these steps (after creating a good compound part):
Meshing the part with initial mesh sizing
Creating the case - BCs and Loads
Calculation - getting either no results (crashing) or horribly wrong results
Back to meshing - changing cell size
Calculation again - good results
Back to meshing - changing cell size
Calculation - no results or bad results.
The steps above are very simplified. For instance some calculations have only worked using meshes made by Gmsh using Frontal Delunay for quads and simple recombination (all other options set to No) with Mesh refine step. And only in one mesh size, coarser or finer meshes havent worked at all, same as any netgen meshes. Here are a few pictures from the latest PrePoMax v2.10.0:
The part on the pictures is a pontoon with internal frames and bulkheads, meshed pretty well and had no reason to give results like this. I’ll attach the files in the google drive link at the end.
Now for the main part. Without touching anything but switching the solver to Calculix 2.22 (apart from doing Save As… and changing the file name and analysis name) I get the following results after recalculation:
These are expected results and they look textbook basically.
I have also tried previous PrePoMax versions going back to 1.3.5. All had the same problems as the above or even worse, not finishing the calculation. The first version that has worked at all was 2.1.0 and even then not consistent - sometimes changing to newer Calculix yielded no results or they were bad as well. The only version that consistently works well for me is the newest 2.1.10 and only with Calculix 2.22.
Currently the easy fix is just to download Calculix from here and point PrePoMax to it.
The calculix build you linked, compliled by Cesare Guardino only has the spooles solver in the build.
If you have the default solver in PrePoMax chosen it will run successfully with the spooles solver in this ccx2.22 build. This is the reason you get correct results.
If you choose PaStiX you’ll get “*ERROR in linstatic: the PASTIX library is not linked”
The default is PaStiX in the PrePoMax ccx2.21 distribution.
If you’re wanting to use this and have access to all the other solvers then set PASTIX_MIXED_PRECISION=0 in the enviroment variables in PrePoMax, this will then give you correct results. Mixed precision in PaStiX is the root cause I believe, it’s been like this for some time.
well that’s Spooles solver which has known reputable for so long, not from official distribution also. Regarding PaStiX solver and shell element, i have no luck even mixed precision has been set, still did not help for case of extreme thickness to spans ratio.
that’s okay in reporting unexpected result since it will notify another user. Also, solver selection is an advanced one due to case dependent. Shell and beam element may be use Spooles or Pardiso as a solver, i guessed knot and/or MPC during expansion cause of problem in specific case of thickness to spans ratio.
As far as I’m concerned, after spending months trying to figure this out before reaching out, I’d say no if it hurts calculations for solids.
Maybe an option is to put some sort of reminder or recommendation in the help section about solver uses for different analysis types. Short of a tutorial or manual but more than nothing for guys like me who are new to open source FEA.
If it doesn’t have any negative consequences then its worth including it in the release.
I’m preparing to write tips&tricks for global analysis of shell compound parts since now I have the workflow sorted out. I’ll include the lessons from here as well.
that’s what i was thinking, similar to personal experiences of shell element in CalculiX. If i may contribute to discussion, setting mixed precision to zero can help in general case, but not always work for extremely large thickness to spans/length ratio (about 1:1000 and higher). Another consequences of these setting are in computational times become slower, but still good recommendation for default.
Some caution also can be useful, a solver selection message can be shown when the model contains shell element.
It seems Spooles solver from official distribution is not support multi-thread, it can be used as default in general and basic. However, the solver running slowly at large multipart contact analysis including plasticity. Just before PaStiX implementing, Pardiso is best at these cases but can not be better than PaStiX after at AMD processor. Maybe another Intel user have different experiences at this, since many issues reported Pardiso solver did not optimize for non Intel based processors, but result still gave consistency.
