Known CalculiX limitations

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.

No. Limitation Workaround Link
1 Rigid body constraints can’t be used with 2D elements in explicit dynamics 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) issue 59
2 Initial velocity is not transferred to the expanded nodes of 1D and 2D elements in dynamic analyses Define a dummy node-based surface from the node set used for the initial velocity definition issue 63
3 Contact print with node-to-surface contact leads to no results of an analysis Use contact print only with surface-to-surface contact thread 927
4 Models with shells, Nlgeom and rigid body constraints may not converge (since ccx 2.23, rigid body constraints can’t be used with shells at all - there is an error message) 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 thread 369 and issue 134
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) Use Pardiso (or at least PaStiX) for the lowest probability of such issues issue 74
6 Tie constraint on shells may fail when *CLOAD is applied to the slave nodes Swap master/slave surfaces or use *DLOAD issue 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 Avoid section print when using orthotropic thermal conductivity issue 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) Release rotational DOFs or use a local coordinate system issue 64 and thread 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 Avoid modified BCs and OP=NEW for BCs in linear dynamics, copy the loads from SSD to frequency steps and set them to 0 there thread 930
10 Local coordinate systems can’t be used for boundary conditions applied to rigid body reference points (analyses fail silently) Use *CLOAD instead thread 2963
11 Reaction moment read from rigid body reference point might be zero in 2D (plane stress/strain) analyses Use a single layer of 3D solid elements instead thread 1312
12 Only the last value of the FREQUENCY parameter from output requests is used Choose one output frequency for all output requests thread 974
13 Models with beam elements and tied contact (anywhere) may not converge Avoid tied contact when using beam elements issue 83
14 Results might be wrong for non-axis-aligned beams with rotational constraint or moment applied Use a local coordinate system issue 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 Split the analysis into more steps thread 1201
16 Results of a multistep analysis with shells might be incorrect when BC is applied to rotational DOFs and uses OP=NEW Use solid elements instead issue 13
17 Analyses with creep are prone to convergence issues Avoid very small A constant, try changing CETOL thread 868
18 EVOL (element volume) output doesn’t account for deformation Calculate the volume directly from the mesh issue 73
19 Springs don’t work on rotational DOFs Create a torsional spring by connecting the ROT NODES of two rigid body constraints sharing the same REF NODE with an axial spring thread 889
20 Distributing couplings either can’t handle BCs at all or don’t support rotations and moments Use kinematic coupling and rigid body constraints instead thread 2586
5 Likes

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

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

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.

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.