Known CalculiX limitations

Tips & Tricks
1

Here’s a list of the most important limitations of the CalculiX solver, particularly the undocumented ones. Some can be considered recurring bugs, while others are just unimplemented features or side effects of the CalculiX’s unusual ways of handling some things (like no true 1D/2D elements or rotational DOFs). Feel free to add more in the comments.

  1. Rigid body constraints can’t be used with 2D elements in explicit dynamics. A workaround is to imitate rigid body by increasing Young’s modulus (this will decrease the stable time increment unless the minimum allowed increment size is fixed by the user): https://github.com/Dhondtguido/CalculiX/issues/59
  2. Initial velocity is not transferred to the expanded nodes of 1D and 2D elements in dynamic analyses. A workaround is to define a dummy node-based surface from the node set used for the initial velocity definition: https://github.com/Dhondtguido/CalculiX/issues/63
  3. Contact print with node-to-surface contact leads to no results of an analysis: https://calculix.discourse.group/t/possible-bug-using-contact-print/927
  4. Models with shells, Nlgeom and rigid body constraints may not converge. A workaround is to extrude shell elements to solids (e.g. using the Thicken Shell Mesh tool in PrePoMax), at least for the region with rigid body constraint applied: https://calculix.discourse.group/t/rigid-body-constraint-convergance-problems/369
  5. The first buckling mode might be skipped when the applied load is much bigger than the buckling load (also Spooles has tendencies to provide wrong eigenvalue results in general): https://github.com/Dhondtguido/CalculiX/issues/74
  6. Tie constraint on shells may fail when *CLOAD is applied to the slave nodes (*DLOAD works). A workaround is to swap master/slave: https://github.com/Dhondtguido/CalculiX/issues/34
  7. Section print with FLUX requested, together with orthotropic thermal conductivity, makes CalculiX “think” that fluid simulation is performed, and it throws an error: https://github.com/Dhondtguido/CalculiX/issues/70
  8. Constraining drilling rotation (rotation DOF normal to the shell’s mid-surface) may lead to overconstraint and incorrect results or even non-convergence (particularly for curved edges). A workaround is to use a local coordinate system: https://github.com/Dhondtguido/CalculiX/issues/64 and https://calculix.discourse.group/t/contact-of-two-shell-pipes-no-convergence-in-newer-ccx-releases/2865
  9. Shells in steady state dynamics and modal dynamics analyses can’t have modified BCs in those steps with respect to the frequency step (*BOUNDARY, OP=NEW and respecified BC also counts as modification) and load applied in the SSD step has to be applied with 0 magnitudes also in the frequency step: https://prepomax.discourse.group/t/potential-bug-applying-radial-displacement-to-rigid-surface/2963
  10. Local coordinate systems can’t be used for boundary conditions applied to rigid body reference points (analyses fail silently): https://prepomax.discourse.group/t/potential-bug-applying-radial-displacement-to-rigid-surface/2963
  11. Reaction moment read from rigid body reference point might be zero in 2D (plane stress/strain) analyses: https://calculix.discourse.group/t/zero-reaction-moment-when-reading-from-rot-node-in-2d/1312
  12. Only the last value of the FREQUENCY parameter from output requests is used: https://calculix.discourse.group/t/different-frequency-for-dat-file-and-node-file/974
  13. Models with beam elements and tied contact (anywhere) may not converge: https://github.com/Dhondtguido/CalculiX/issues/83
  14. Results might be wrong for non-axis-aligned beams with rotational constraint or moment applied. A workaround is to use a local coordinate system: https://github.com/Dhondtguido/CalculiX/issues/124
  15. Minimum time increment can’t be lower than 1e-6 * step time for static steps and 1e-10 * step time for dynamic steps. A workaround is to split the analysis into more steps: https://calculix.discourse.group/t/minimum-time-increment-cant-be-lower-than-1e-5/1201
  16. Results of a multistep analysis with shells might be incorrect when BC is applied to rotational DOFs and uses OP=NEW: https://github.com/Dhondtguido/CalculiX/issues/13
  17. Analyses with creep are prone to convergence issues: https://calculix.discourse.group/t/creep-calculation-and-results/868
  18. EVOL (element volume) output doesn’t account for deformation: https://github.com/Dhondtguido/CalculiX/issues/73
4 Likes
PrePoMax in the RR3 Wind-Turbine Tower Benchmark (Sadowski Round Robin 2024–2025) – Results & Observations
2

Limitations:
It is not possible to model a ‘true’ 2-node 6_DoF spring element with 6 K values that understands both loads or constraints at its nodes. Which means that is not possible to build detailed joints with the correct stiffness; e.g. to model a bearing with radial, axial & tilting stiffness. Or a detailed local contraint on rotations DoF at a spring node.

Similarly it occurs with ‘soft’ couplings (RBE3, distributing…) as they don’t seem to handle the 3 rots DoF at the ref node for moments and rot constraints.

1 Like
3

Something like a BUSHING connector in Abaqus would be ideal, but there have been some more or less successful attempts to model such connections with various workarounds discussed on this forum. I don’t want to go too off-topic, but the recommended way seems to be with beam element connected to the rest of the model via distributing couplings and *EQUATION constraints.

Regarding springs, indeed they don’t support K4-K6, but there is a (rather tedious) workaround with rigid body constraint: https://calculix.discourse.group/t/torsional-spring-spring2/889

When it comes to couplings, I summarized their limitations here: https://calculix.discourse.group/t/different-coupling-constraints-and-their-limitations/2586

4

As soon as we have to use rigid body constraints, or ‘rigid’ links anywhere coz of lack of correct modelling, we are over-constraining models up, and we deviate from reality. Even if the displaced shape and/or transient animations look believable.

Your thread title says ‘limitations’? I think these are big ones, not being able to model real structural assemblies, as a general method, in my opinion.

5

Perhaps we should ask Guido Dhondt (or at least create a ticket here: GitHub - Dhondtguido/CalculiX: This repository contains the source files of CalculiX, a three-dimensional Finite Element Program (www.calculix.de). - currently almost only bug reports are present there) to consider implementing some of those features. Torsional springs might be the easiest for now.