try doing mesh refinement, still in similar problem.
Even with a thickness of 10 mm, Pardiso gives wrong result.
What’s interesting, it takes only 40 s to solve this using Pardiso and as long as 142 s using PaStiX…
PaStiX is not reliable for shells: Problems with PaStiX solver and shell elements - CalculiX (official versions are on www.calculix.de, the official GitHub repository is at https://github.com/Dhondtguido/CalculiX).
There are some settings to improve the behavior, but I would not recommend it. I don’t think the speedup is worth it. Pardiso performs much better.
I would expect issues with PaStiX (especially when it comes to dynamic/modal analyses and expanded elements) but I’m somewhat surprised that Pardiso also gives incorrect result in this case.
below using thickness 1.4mm of flat model, PaStiX run and give result consistently.
i’m not yet to download and test for another ones since the file size is too large (44MB)
p.s my solver setting
That’s the flat plate. The problem reported by the OP is only with the curved one.
solver PaStiX also have problem in flat model, it gives inconsistent result for every running. That’s why i notified before as quite strange.
In my experience the Spooles and Pardiso work. If something is wrong using these solvers it is probably a CacluliX shell issue. PaStiX is another story.
Maybe it is buckled.
it seems not, problem of PaStiX solver only and occurs when shell thickness ratio is too high or extreme.
hi,
currently reduced model is available from GitHub. It seems the problems are due to over-constrained at some edge. Improvement can be achieved by using quadratic element instead of linear.
1sr model (original)
2nd model (modified) i’m removes UR2
result by removing rotational dof at corner nodes.
Thank you all for your messages !
The discussion continued on the calculix forum: Inconsistent result with CalculiX on a shell model of a plate in bending · Issue #64 · Dhondtguido/CalculiX (github.com)
It turns out that this kind of problem appears when we over-constrain curved shells.
It would be the drilling rotation in particular that causes the problem.
This can be remedied by using *TRANSFORM keywords to recreate local coordinates at nodes where BC are applied and thus avoid constraining the drilling rotation.
It’s still not easy to setup for a calculation like mine (there are a lot of nodes)… I am advised to use solid elements for this particular case. Thank you once again and have a good day everyone.
Maybe, in the future, an automatic feature to define local coordinate systems on shell edges could be added.
2 Likes
indeed, i investigated further about local axis of node in shell element. It will always require defining explicitly no mater normal angle transition between its element neighbor. Additional in automatic definition of local axis shell element can also be useful. It seems, this is applicable in case of structured mesh only, unstructured type still required manual definition by the user.
Hi @synt
What is the software you use to display the local coordinate systems for each shell elements ?
It may be very useful 
indeed, displaying local axes of shell element is a useful feature and commonly available in many FEA programs.
my example is a shell mesh imported from Gmsh mesher and need to be analysis with OpenSees. Local ‘1’ or ‘x’ axes (red color) required to be realigned to global ‘Z’ axes from default.
1 Like