Abq2ccx input converter (Abaqus to CalculiX)

Tool interfaces
1

abq2ccx is a tool to convert abaqus inp file into calculix inp file.

So work is here greatly reduced to run abaqus inp files in calculix.

Calculix 2.22 is here actual state with 141 cards.

For chiefs here:
Only 3 replies in collected 3rd party posts!

1 Like
Collected posts on third party developments, examples, etc
2

abq2ccx is a tool to convert abaqus inp file into calculix inp file.

That looks like a very helpful tool! Has anyone tried it?

1 Like
3

Not yet, I just use this approach to adapt the input deck manually. But the abq2ccx tool looks really interesting, especially since it can handle the *PART/*ASSEMBLY structure, meaning that it should be no longer necessary to use flattened input decks and avoid transforming the instances. I’ll definitely give it a try.

2 Likes
4

I just had a quick look at the source code. Looks promising.

But there seem to be a couple of flaws. (E.g. ROTA for body load is not supported in ccx).

Having reference nodes defined in abaqus in the assembly is also buggy. It seems to overwrite the nodeID of the flattens assembly nodes.

But overall a good starting point!

Best,

Stoli

1 Like
5

Feedback at the project with found issues would be nice.
See

6

Actual state is now at keywords of actual caclculix 2.23 and abaqus 2025.

By finding limitations and errors please inform the developer.

7

Can you make issues at this project for the developer with some example lines by input, possible and actual result?

8

Thanks for the useful feedback on the toolbox (and a mention on the slide at wccm), I’m working on a few fixes right now. If you find more issues please let me know!

1 Like
9

Stoli: Your issue was solved at abq2ccx 2 month ago.
Do you test again ?

Calculix 2.23 is now supported.

10

Yes, the assembly node bug was fixed and resolved the main issue with my existing abaqus model database. I am still evaluating a workflow for an automatic conversion of all parts and assemblies (approx. 400 part variants) to ccx.

11

Hi all,

A quick update on abq2ccx, the converter from Abaqus .inp decks to CalculiX. The last two days went into a full audit against ccx 2.23 and a long list of new conversions.

Now on PyPI

pipx install abq2ccx      # or: pip install abq2ccx
abq2ccx model.inp --run   # writes model_ccx.inp, runs ccx, prints a results digest

Version 1.2.1 is current: one dependency-free Python file (Python 3.9+, MIT).

What’s new in 1.2

  • Published answers: 30 NAFEMS benchmark decks from the Abaqus Benchmarks Manual are converted, run in ccx and compared with their published values. 19 match Abaqus’ result for the same mesh; 7 differ for reasons traced to ccx and documented, such as how ccx extrapolates stresses to the nodes. The benchmarks also exposed 8 converter faults, now fixed.
  • Composite shells: composite S3/S4/S4R shells run as S6/S8R, and composite continuum shells (SC8R/SC6R) as one C3D8I/C3D6 per ply, with Abaqus’ ply directions.
  • Beams: *BEAM GENERAL SECTION and I, T, HEX, TRAPEZOID and ARBITRARY sections run as ccx’s U1 beam where it can carry the physics; CIRC, PIPE and BOX sections become the quadratic beams ccx accepts.
  • User materials: --abaqus-umat writes UMAT materials for ccx’s Abaqus-UMAT interface, for a ccx built with your UMAT (build steps in the user guide).
  • Constraints and loads: *MPC, connectors, rigid elements and analytical rigid surfaces, *TRANSFORMed nodes, velocity and acceleration BCs, tractions and line loads, Abaqus’ default amplitudes.
  • Workflow: --run prints a per-step results digest and the Abaqus → ccx label map for assemblies; abq2ccx deck.inp out.inp names the output.
  • Any physics a conversion drops is named in a closing “Reduced physics” warning.

Of the 1052 Abaqus decks in the test corpus, 189 solve their own physics in ccx 2.23 and 33 more solve with reduced physics flagged. Most of the rest need user subroutines.

ccx 2.23 behaviour found along the way

Each of these was measured on ccx 2.23 with small test decks, and abq2ccx now works around it.

  • Abaqus UMATs under large deformation. For a material named ABAQUSNL…, ccx calls an Abaqus-format UMAT through umat_abaqusnl.f. Since a change in November 2023 that routine never computes U0, the stretch at the start of the increment, so the stress it passes to the UMAT is undefined (zero in our build). A UMAT that updates the stress incrementally, such as J2 plasticity, then goes wrong: a J2 cantilever under NLGEOM ended with a tip reaction 70 % below the same model with ccx’s own *PLASTIC. Setting U0 (five lines, given in the user guide) brings the two within 2·10⁻⁵.
  • User-material names. ccx picks the routine for a *USER MATERIAL from the start of the material name. In a standard build, a name starting with ABAQUS runs a linear-elastic example UMAT (E and ν from the first two constants), and a name starting with USER runs the empty umat_user, which returns zero stress. Neither gives an error; any other name stops ccx with “no user material subroutine”. Two corpus decks with materials named user and user_mat had been “solving” with zero stress everywhere. abq2ccx now renames such materials so ccx stops instead.
  • Material directions on shells and membranes. On an oriented shell, ccx projects the orientation’s axis 1 onto the element and falls back to axis 3 where axis 1 is normal to it. Membranes (M3D3, M3D4) use the orientation’s 3-D axes without projecting them at all. Both differ from Abaqus, so an orthotropic shell or membrane can get the wrong stiffness without a message: in our check of a pressurised orthotropic cylinder with a cylindrical orientation, the shell came out 14 times too soft against thin-wall theory. abq2ccx now writes the material directions per element as Abaqus defines them (next release).
  • Composite plies without an orientation. In *SHELL SECTION, COMPOSITE, a ply line with an empty orientation field inherits the previous ply’s orientation in ccx 2.23, where Abaqus uses the section’s orientation. abq2ccx now gives every ply an orientation.
  • Quadratic beams. ccx expands a B32 beam into a fully integrated 20-node brick, with 3 integration points along the beam; Abaqus integrates its quadratic beams at 2. On coarse meshes B32 is therefore too stiff: a cantilever of one B32 element deflects 77 % of the beam-theory value, while B32R matches it. NAFEMS NL6 on 8 elements comes within 0.9 % of Abaqus with B32R. abq2ccx will run all 3-node beams as B32R in the next release.
  • The U1 beam. U1 is ccx’s 2-node beam element that is not expanded into solids, and the only element that takes a general section (area and moments of inertia). In our tests its nodal forces have wrong signs (the axial force at the first node, the shear force at the second), so reaction forces at U1 nodes are wrong. Its torsional stiffness is G·(I11 + I22), with no input for a torsion constant, which is far too stiff for open sections such as I-beams. abq2ccx uses U1 only in linear models, warns about the reactions, corrects the torsion with a modified material copy where possible, and otherwise needs --approximate.

In progress

  • Quadratic membranes (M3D6, M3D8, M3D8R). In a simple test (isotropic, ν = 0, loaded by nodal forces), one M3D8R element came out twice as soft as it should and one M3D8 element 1.74 times as soft; two M3D8R elements together behave as a mechanism. M3D4 and S8R are exact in the same test. We’re narrowing this down before deciding how abq2ccx should handle these elements.
  • Continuum shells without a layup. Getting the material directions of plain SC8R/SC6R sections to follow Abaqus, as for the shells above.

Feedback is welcome: decks that fail to convert or give a different answer, and corrections on the ccx side. Issues on GitHub or replies here both work.

1 Like
12

Can you report those issues with CalculiX on its GitHub ?

1 Like
13

I have a list of issues drafted, I’ll have a closer look at them before I submit them

1 Like
14

I posted some in the analysis issues forum (github mentions needing to post them there first). I did not post all my findings (I have about six more issues) since I don’t want to overflow the forum with my findings (I suppose this code is a bit of a stress test for the parser)

15

Ok, thanks. Let’s confirm these for now. Ultimately, all confirmed bugs should be reported on GitHub so that they don’t get lost/forgotten on the forum (nobody fixes the bugs reported only here). Example code/file and clear reproduction steps should be enough.

16

Many thanks @Sandervdb and @Calc_em for your work. It helps a lot to have a good description, minimal examples and an independent confirmation!

1 Like