A Guide to Modifying Abaqus Input Files for Use in CalculiX

1

It’s often the case that someone has experience with Abaqus and starts using CalculiX. The keyword syntax of both codes is largely compatible but of course, there are some differences. You should compare the Keywords section of Abaqus documentation and the Input deck format section of CalculiX’s manual (http://www.dhondt.de/ccx_2.20.pdf) whenever in doubt but I would like to share a few tips to make the transition from Abaqus to CalculiX a bit easier:

  1. First of all, make sure that all features used in your Abaqus model are supported in CalculiX. Examples of unsupported features include general contact, connectors, several types of analyses, many advanced material models, special-purpose elements, and so on. A list of features supported in CalculiX can be found here: CalculiX: Overview of the finite element capabilities of CalculiX Version 2.20

  2. Before exporting input files from Abaqus (Write Input) check Do not use parts and assemblies in input files in Model → Edit Attributes. That’s because CalculiX doesn’t support *PART, *INSTANCE, *ASSEMBLY and other keywords related to the concept of parts and assemblies in Abaqus.

  3. Avoid moving and rotating instances in the Assembly module in Abaqus. Place them where they were initially created. That’s because CalculiX doesn’t support the *SYSTEM keyword used in Abaqus when the input file is written without using parts and instances.

  4. Remove the *PREPRINT keyword.

  5. Remove the NAME parameter from the *STEP keyword.

  6. Remove the default restart request of dynamic explicit analysis or change it to *RESTART, WRITE, FREQUENCY=1. Keep in mind that to use restart in CalculiX you have to rename the “jobname.rout” file to “jobname_new.rin”.

  7. Replace the default output requests like *OUTPUT, FIELD, VARIABLE=PRESELECT with standard CalculiX output requests like:

*NODE FILE
U
*EL FILE
S,E
  1. Syntax of rigid body constraints is a bit different:
  • in CalculiX, you need an additional node with arbitrary coordinates (can be the same as those of the ref node) to serve as a rot node
  • in Abaqus, there’s only a REF NODE parameter while CalculiX also uses ROT NODE (reason above)
  • both REF NODE and ROT NODE parameters require node numbers, not node set names. The same applies to the REF NODE parameter used for coupling constraints.
  • rotational degrees of freedom are handled by ROT NODE (its DOFs 1-3 are in fact DOFs 4-6)
  • Abaqus uses PIN NSET and TIE NSET for pinned and tied nodes while CalculiX uses just NSET

  1. In Abaqus, the data line of the *KINEMATIC keyword is empty by default but in CalculiX it requires specifying the degrees of freedom (1-3). The WEIGHTING METHOD parameter used in Abaqus with *DISTRIBUTING is not supported in CalculiX.

  2. The *SURFACE INTERACTION keyword in Abaqus has a data line for out-of-plane thickness for 2D models while in CalculiX it’s not used.

  3. CalculiX doesn’t support predefined boundary condition types such as XSYMM, PINNED and ENCASTRE used in Abaqus.

  4. The *DSLOAD keyword is supported in both Abaqus and CalculiX but the latter code supports it to a limited extent. In Abaqus this keyword can be used to define surface-based loading: pressure, surface traction or shell edge load (using several special labels such as P, TRVEC, TRSHR, and so on) as well as a stress-driven boundary for submodeling. In CalculiX this keyword is used only for pressure load (only label P is supported) or stress-based submodeling.

  5. The *DLOAD keyword in Abaqus can be used to specify element-based loadings such as pressure, surface traction, shell edge load and body loads (using several special labels such as those mentioned before and additional ones). In CalculiX only the following load types and labels are supported: pressure (Px, PxNUy), shell edge load (EDNORx), centrifugal load (CENTRIF), gravity load (GRAV).

  6. The *FREQUENCY keyword has different parameters in Abaqus. EIGENSOLVER, ACOUSTIC COUPLING and NORMALIZATION parameters won’t be recognized by CalculiX.

  7. The *BUCKLE keyword uses different data line entries. In Abaqus it’s:

  • for SUBSPACE (default) solver: number of eigenvalues, maximum eigenvalue of interest, number of vectors in iteration, maximum number of iterations
  • for LANCZOS solver: number of eigenvalues, minimum eigenvalue, maximum eigenvalue, block size, maximum number of block Lanczos steps within each run

While in CalculiX it’s: number of eigenvalues, accuracy, number of Lanczos vectors calculated in each iteration, maximum number of iterations

  1. The *SHELL SECTION keyword in Abaqus has 2 entries within the data line if a homogenous shell is defined: thickness, number of integration points through thickness. CalculiX uses only the first one.

  2. Abaqus supports several different beam sections. CalculiX supports only rectangular, elliptical, pipe, box and general sections. The elliptical section is defined with the parameter SECTION=CIRC like a circular section in Abaqus. However, the data line is different. In Abaqus, one specifies the radius of the circular section while in CalculiX the data line consists of the length of the principal axes of the ellipse. The circular section can be defined by omitting the second entry and specifying only the first one - diameter (as opposed to the radius used in Abaqus). As a side note, Abaqus doesn’t have predefined elliptical beam sections. The general beam section is defined differently in CalculiX:

  • Abaqus:
*ELEMENT, TYPE=standard_beam_element
...
*BEAM GENERAL SECTION, ELSET=..., SECTION=GENERAL
A, I_11, I_12, I_22, J, T_0, T_w
direction_1, direction_2, direction_3
E, G
  • CalculiX:
*ELEMENT, TYPE=U1
...
*USER ELEMENT, TYPE=U1, NODES=2, INTEGRATION POINTS=2, MAXDOF=6
*BEAM SECTION, ELSET=..., MATERIAL=..., SECTION=GENERAL
A, I_11, I_12, I_22, k
direction_1, direction_2, direction_3

  1. The LOAD CASE parameter used with the *BOUNDARY keyword serves a different purpose in Abaqus and CalculiX. Abaqus uses it only for linear buckling analyses while CalculiX uses it only for steady-state dynamics. The same parameter can be used in Abaqus with the *CLOAD keyword in random response analyses. In CalculiX it’s used with *CLOAD and *DLOAD keywords for the same purpose as with the *BOUDNARY keyword - to specify real and imaginary loading in SSD analyses. In Abaqus, this is done using separate parameters named REAL and IMAGINARY.

  2. The TYPE parameter used with the *BOUNDARY keyword in Abaqus is not supported in CalculiX. The only mechanical boundary conditions available in CalculiX are displacements and rotations, not velocities and accelerations.

  3. Dynamic implicit analysis in Abaqus supports several different parameters added to the *DYNAMIC keyword to control time incrementation. CalculiX supports only the DIRECT and ALPHA ones.

  4. Mass scaling is defined in Abaqus using *FIXED MASS SCALING and *VARIABLE MASS SCALING keywords. In CalculiX, it’s defined by just specifying the desired minimum time increment as a third parameter under the *DYNAMIC keyword.

  5. CalculiX supports only a subset of output variables available in Abaqus. Their list can be found in the 6.13. Output variables section of the CalculiX manual and should be compared with the Output → Output Variables section of Abaqus documentation. The differences and CalculiX’s limitations are particularly significant when it comes to energy output.

6 Likes
2

Dear @Calc_em ,

Isn’t it better to modify CalculiX source code to make it more compatible with Abaqus? I understand, it’s not easy. But the result worth it. Just imagine an open source Abaqus, which does not require license tokens at all. - That what CalculiX could be.

3

HKS allowed Guido to use Abaqus syntax. I’m pretty sure that the current owner of Abaqus (DS) would ignore any requests like that :wink: Simply copying Abaqus is out of the question for legal reasons. Also, CalculiX will never be able to reach the level of Abaqus which has been intensively developed by teams of specialists for 45 years. Of course, larger compatibility with Abaqus would be great but even now the syntax is very similar, making CalculiX the best choice for experienced Abaqus users looking for open-source solutions.

4

maybe it’s not fully their internal research, history says the ideas of Abaqus are to modify the code and makes expanding the capabilities of an opensource SAP (EL Wilson) were another pioneers (KJ Bathe of opensource NONSAP) also do similar things at the same periods.

it seems HKS took benefit from opensource academics world, as the book of EL Wilson and KJ Bathe written. so CSi and Adina started then do a similar ways, company enter the markets and do competitive.

history of CalculiX or any opensource NLFE born with similar ideas as above, in exception of keep the code’s open and accessed freely. not to do replicates totally but an improvement and expanding. in examples of CalculiX 1D beams and 2D shell are differ greatly.

1 Like