I prepared a simple model to demonstrate the wrong results when using the PaStiX solver from the official CalculiX version 2.19 for Windows: file ccx_static.exe (the same also goes for version 2.18).
The model is a simple I-profile meshed using parabolic triangular shell elements. It is fixed on all edges on the left side and loaded with a distributed force - pressure as shown in the image.
But if the solver is switched for PaStiX with the keyword: *Static, Solver=PaStiX, the results are completely wrong and are shown in the following image:
The model with the Spooles solver can be downloaded from: Profile.inp
When using linear triangular shell elements, both solvers produce the same results. When using different mesh densities, the results are sometimes the same but sometimes they are different as in the shown example.
Can someone confirm this behaviour on Windows and on Linux.
Strange, I can’t confirm this. I downloaded your input file and submitted it without changes using 2.19 on Windows. Then I just changed *Static, solver=Spooles to *Static, solver=PaStiX. The results were pretty much the same (with insignificant differences in the second decimal place). No such distortions like in your third picture. Pardiso also provided correct results. Maybe it’s a bug that occurs occasionally.
i can confirm, it has produced different results for PaStiX solver. try modified the element with composite (2 layers), still yield the unexpected results.
i only guess this problem occurs due to coarseness of the mesh. only one element match the knot positions. but, did not know why Spooles solver gave better results.
Just for the fun of it, I had a go using CalculiX on my Mac with Intel Pardiso. Please see the screenshot below. I have not had much luck with PaStiX and default to the Intel Pardiso solver . Has anyone thought about using MUMPS (http://mumps.enseeiht.fr)?
I have tried using the proposed method, but it has no effect. Now I tried running the .inp file from the command line and got different results than previously when the analysis was started from PrePoMax. Strange. But both cases with and without the added line (1.,1.) give the same results as shown in the image.
Not reusing csc.
±------------------------------------------------+
PaStiX : Parallel Sparse matriX package +
±------------------------------------------------+
Version: 6.0.1
Schedulers:
sequential: Enabled
thread static: Started
thread dynamic: Disabled
PaRSEC: Disabled
StarPU: Disabled
Number of MPI processes: 1
Number of threads per process: 12
Number of GPUs: 0
MPI communication support: Disabled
Distribution level: 2D( 256)
Blocking size (min/max): 1024 / 2048
That setting solved the problem. Thank you! That is really helpful. If I understand correctly, this setting does not interfere with other solvers, so I could enable it every time the PaStiX solver is used?
Novel approach to exploit mixed precision arithmetic . The approach is based on the observation that singular vectors associated with small singular values can be stored in lower precisions while preserving high accuracy overall.
. Has anyone thought about using MUMPS (
