abq2ccx

abq2ccx — Abaqus → CalculiX input converter

abq2ccx.py converts an Abaqus .inp deck into a CalculiX (ccx) deck. It is one Python 3 file with no dependencies.

CalculiX copies most of Abaqus' keyword syntax, so much of a deck passes through as it is; the work is in the parts that differ. The converter knows the complete CalculiX 2.22 + 2.23 keyword set and does one of three things with every Abaqus card: passes it through, translates it into the CalculiX construct that does the same, or comments it out with a warning that says what to do. Nothing is dropped silently, and nothing that changes the physics happens unless you ask for it with --approximate.

Quick start

Run the file with Python 3.9 or later — copy it anywhere — or install it as the abq2ccx command (abq2ccx model.inp, same options):

pipx install abq2ccx                                       # from PyPI
pipx install git+https://github.com/sandervdbroek/abq2ccx  # the latest main

python3 abq2ccx.py model.inp                 # -> model_ccx.inp (+ model_ccx.log)
python3 abq2ccx.py model.inp ccx_model.inp   # -> ccx_model.inp (+ ccx_model.log)
python3 abq2ccx.py decks/*.inp --outdir out  # batch-convert into a directory
python3 abq2ccx.py model.inp --run           # convert, run CalculiX, digest its results
python3 abq2ccx.py model.inp --check         # report only, write nothing
ccx model_ccx                                # run it yourself (no .inp extension)

Always read the report: it is printed to stderr, written to *_ccx.log and repeated as ** comments at the top of the converted deck. The user guide has every option, the exit codes and the Python API.

import abq2ccx
result = abq2ccx.convert_file("model.inp")   # or convert_text(deck_string)
print(result.report.summary())               # "N warning(s), M note(s), K commented card(s)"

What it converts

• Mesh generation (*NGEN, *NFILL, *NCOPY, *ELGEN, *ELCOPY) → explicit nodes and elements.
• Parts, instances and assemblies → one flat model, with instance transforms applied and part-level sections, constraints and orientations copied per instance.
• Elements → CalculiX types, keeping the node count. Incompatible-mode CPS4I/CPE4I become exact one-element-thick C3D8I slabs (ccx has no such plane element); beams under circular, pipe and box sections get the midside nodes ccx 2.23 needs; planar beams and trusses are held in their plane; surface elements leave the mesh and their loads become nodal forces; connector elements become their kinematic constraints. A substitution that changes the element formulation (hybrid, modified or thin-shell elements run as ccx's plain ones) is flagged as reduced physics.
• Materials and orientations — elastic types, plasticity (including Johnson-Cook), the Johnson-Cook damage initiation criterion ccx shares with Abaqus, thermal expansion, composite layups and per-element *DISTRIBUTION orientations (variable-angle-tow layups); composite S4R/S4/S3 shells run as S8R/S6, composite continuum shells (SC8R, SC6R) as one solid per ply.
• Constraints — *MPC, kinematic couplings and rigid bodies (with knot beams where ccx 2.23 rejects rigid constraints on shell and beam nodes), and the overconstraints ccx rejects but Abaqus resolves.
• Rigid tools — rigid elements (R3D3, R3D4, R2D2, RAX2, …) become force-free solid skins carried by their rigid body, so contact against them works; analytical rigid surfaces are meshed the same way, curved ones only with --approximate; a *TIE to a rigid surface makes its nodes part of the body, and ROTARYI becomes point masses.
• Loads and BCs — surface tractions and beam line loads become consistent nodal forces; velocity and acceleration BCs become integrated displacement BCs; *TRANSFORM local axes are respected wherever ccx reads them.
• Steps and output — explicit dynamics with Abaqus/Explicit's defaults, output requests fitted to ccx's .frd/.dat model, and Abaqus' preselected output.

The exact handling of every keyword, element type and output variable is in the generated references: keywords, elements, output variables.

Reduced physics. Whatever the converter has to drop or replace of the Abaqus model — a constitutive behaviour ccx lacks (concrete damaged plasticity, user hardening, Chaboche back-stresses, field-dependent properties), an element formulation, a section control, a constraint or interaction, a load — is named in a "Reduced physics" warning at the end of the report (Converter.reduced_physics in the API): ccx then runs, but not the deck's own problem.

--approximate (off by default) lets the converter reframe what ccx cannot run exactly as a close equivalent, each flagged [APPROX] — a Riks step as plain static, ν ≥ 0.5 as 0.475, an I-section in space as ccx's U1 beam with too stiff a torsion (or an equivalent rectangle where U1 cannot run), NLGEOM follower tractions as fixed nodal forces, a curved analytical rigid surface as flat facets, and a few more (full list). Without it those cards are commented out with the reason, so ccx never silently runs a different model.

Validation

python validate_with_ccx.py converts the bundled examples, runs them in CalculiX (it finds ccx, including FreeCAD's copy) and compares each result with an independent reference. It prints one PASS line per check, about a hundred in all; testing lists them.

A corpus of 1052 genuine Abaqus decks — 1022 from about 180 public repositories (CAE exports, UMAT and UEL decks, explicit and coupled models, …) and 30 NAFEMS benchmark decks of the Abaqus 2017 documentation — is fetched on demand and run through convert → integrity check → ccx. On ccx 2.23 all 1052 convert with no dangling reference; 188 solve the deck's own physics; 44 more solve but stay out of that count — 14 load nothing in the source deck, 31 (3 of them also unloaded) solve a model with reduced physics, and two converge to solutions that are not the deck's (a part that only contact holds drifts away in ccx; a plate pushed far past its buckling load, whose lowest factors ccx's *BUCKLE does not return) — and 221 mesh-only decks are accepted. The other 599 need what ccx cannot run — mostly user materials (353) and user elements (66). 26 benchmark decks are checked against their published answer: 20 match Abaqus' result for the same mesh (within 0.5 % for temperatures and frequencies, 1 % for stresses and displacements), 6 differ for reasons traced to ccx (its nodal extrapolation, plane-stress slab, film integration, mass matrices, a coarse shell mesh, beam clamps). See testing.

How it works

read (+ *INCLUDE, *PARAMETER)  →  flatten *PART/*INSTANCE/*ASSEMBLY
  →  build the geometry (expand mesh generation)  →  plan deck-wide fixes
  →  translate card by card  →  settle *EQUATION dependents, audit loads  →  write

The architecture guide describes the pipeline and how to extend it.

Limitations

• User subroutines (UMAT/VUMAT, UEL, DLOAD, DISP, …) do not run in stock ccx. Such cards are commented out, naming the ccx subroutine to port; a UMAT runs in a ccx built with it (--abaqus-umat), a VUMAT has no ccx interface.
• Cohesive and gasket elements run as thin continua (their traction-separation law is lost; warned). Abaqus general contact (*CONTACT), connector behaviours, inertia relief and materials such as viscoelasticity and concrete damaged plasticity have no equivalent and are flagged for remodelling; a deck that runs without them is flagged as reduced physics.
• ccx's own first-order elements are not Abaqus': its CPE4/C3D8/CAX4 are plain 2×2(×2) integration, without Abaqus' selectively reduced volume terms (on a coarse bending mesh Abaqus' CPE4 deflects 9–19 % more for ν 0–0.3), and its CPS4 is a 3-D slab with a free thickness, not 2-D plane stress (compatibility).
• Explicit coupled temperature–displacement steps do not run; Riks steps, NLGEOM follower tractions and curved analytical rigid surfaces run only with --approximate.
• Contact is translated card by card, but ccx's penalty contact behaves differently from Abaqus' — check it.
• ccx 2.23 gets some valid input wrong without an error. The converter works around what it can and warns about the rest (compatibility, troubleshooting).
• The converter checks structure, and physics on its benchmarks — not on your model. Run ccx and sanity-check the results.

Validated on CalculiX 2.23 (the FreeCAD 1.1.4 build); written for 2.22–2.23.

Examples

Tests

python tests/test_convert.py                            # unit tests, no solver needed
python validate_with_ccx.py                             # end-to-end checks in CalculiX
python corpus/fetch.py && python tests/test_corpus.py   # the corpus

Testing describes the three layers; GitHub Actions run the first two on every push, the unit tests on Linux, macOS and Windows and the CalculiX checks on Linux and Windows.

Documentation

• User guide — options, workflow, reading the report, the Python API.
• Troubleshooting — ccx errors and results that look wrong.
• Compatibility — the Abaqus/CalculiX facts the converter relies on, ccx 2.23 issues, and what does not convert.
• Testing · Architecture · Changelog
• Generated references: keywords · elements · output variables

Sources

• CalculiX CrunchiX User's Manual v2.23 — https://www.dhondt.de/ccx_2.23.pdf, v2.22 — https://www.dhondt.de/ccx_2.22.pdf, v2.7 (HTML) — https://web.mit.edu/calculix_v2.7/CalculiX/ccx_2.7/doc/ccx/ccx.html
• calculix/new_keywords (Abaqus↔CalculiX keyword delta) — https://github.com/calculix/new_keywords
• calculix/cae (CalculiX keyword model) — https://github.com/calculix/cae
• "A Guide to Modifying Abaqus Input Files for Use in CalculiX" — https://calculix.discourse.group/t/a-guide-to-modifying-abaqus-input-files-for-use-in-calculix/1430
• CalculiX Discourse — https://calculix.discourse.group/ · PrePoMax forum — https://prepomax.discourse.group/

Compatibility lists the Abaqus manual pages behind individual facts.

License

MIT © Sander van den Broek. abq2ccx is an independent tool, not affiliated with or endorsed by Dassault Systèmes (Abaqus) or the CalculiX project. The test corpus is fetched on demand and not redistributed here; each deck keeps its own upstream license, recorded in corpus/manifest.py.