Problems with PaStiX solver and shell elements

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.

When using the Spooles solver with the keyword: *Static, Solver=Spooles the results are as expected and are shown in the following 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.

Hello @Matej,

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 :sweat_smile:. Has anyone thought about using MUMPS (

Best wishes,

Try with this:
*Static, Solver=PaStiX

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.

By the way, I am using AMD Ryzen 5 5600X 6-Core CPU. I have some other computers with different CPUs that I will try and post the results.

I think that’s it:


modified these setting for bConverged distribution at:
C:\Program Files (x86)\bConverged\common\site\cmdStartup.bat

solved the problems here on Intel processor type.

In my computer results are correct.
AMD Ryzen 9 5900HX + Pastix Static & Dynamic with or without mixed precision doesn’t change the result.

Not reusing csc.

  • PaStiX : Parallel Sparse matriX package     +

Version: 6.0.1
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

Matrix type: General
Arithmetic: Double
Format: CSC
N: 2231
nnz: 166589

Ordering step :
Ordering method is: Scotch
Time to compute ordering: 0.0014

No problems here as well. I’m using Windows 10 with Intel i7-8750H as the processor.

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?

Is it faster when the mixed_precision=1?

1 Like

I was previously told to use PASTIX_MIXED_PRECISION=1. Does anyone know the difference between setting that from 1 to 0. Which is best to use?

looking the table comparison from @rafal.brzegowy setiing to ‘1’ is better in computational times.

1 Like


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.


Wow, that is science :slight_smile:

1 Like

I got similar results. cpu AMD A9-9420 RADEON R5, and with set PASTIX_MIXED_PRECISION=0 issue is fixed.