GE Jet Engine Bracket FEA: Is the 205 g “Ultralight” GrabCAD Bracket Strong Enough? CalculiX vs code_aster on cloudHPC

Published by Ruggero Poletto on

TL;DR

  • We downloaded the “Ultralight” entry (Jack Schorsch, 2013) of the GrabCAD GE Jet Engine Bracket Challenge: about 205 g of Ti-6Al-4V, roughly 10 % of the original 2,033 g bracket, and the 2nd lightest of the 381 designs in the MIT SimJEB dataset.
  • We ran the four GE load cases (35.6 kN vertical, 37.8 kN horizontal, 42.3 kN at 42°, 565 N·m torsion) with CalculiX 2.19 (PARDISO) on four quadratic-tet meshes from 257 k to 2.7 M nodes, and with code_aster 17.3.17 (MUMPS) on the first three.
  • The bracket does not survive the GE loads elastically. Under the vertical and horizontal loads the 99.9th-percentile von Mises stress is ≈ 2,300 MPa, about 2.5× the 903 MPa yield, and 3 % (vertical) to 9.8 % (horizontal) of the bracket volume is above yield. The 42° case and torsion exceed yield only very locally.
  • CalculiX and code_aster agree to within 0.15 % on displacements away from the pin (0.85 % in torsion) and to within 0.25 % on peak stresses in the force cases, on the same mesh. Close to the pin, the different load-coupling definitions matter: up to 4.8 % in torsion.
  • The maximum displacement converges to within 0.4 % between 1.15 M and 2.7 M nodes. It is 3–13 % above the coarse first-order OptiStruct values published in SimJEB.
  • The whole study (9 runs, including two failed code_aster set-ups) cost €3.17 on cloudHPC spot instances. The largest run (2.7 M nodes, 8 M equations) took 47 min and €1.76.

Why this bracket, and why now

In 2013 GE Aviation and GrabCAD asked the community to make an engine-lifting bracket lighter for additive manufacturing. The bracket had to keep its four bolt interfaces and its clevis pin, and it had to carry four static loads. GE’s own write-up of the challenge (Carter et al., 2014) describes how the top-10 designs were printed in titanium and load-tested. The winning design weighed 327 g against the original 2,033 g.

Ten years later the challenge is still one of the best open FEA test cases around, for two reasons:

  • The geometry, loads, material and interfaces are public: the GrabCAD challenge page lists them.
  • MIT’s SimJEB dataset (Whalen, Beyene & Mueller, 2021) cleaned, meshed and solved 381 of the entries in Altair OptiStruct under the same four load cases. That gives us an independent reference result for the very same CAD file we analyse here (SimJEB design id 23).

Topology-optimised, lattice-like parts are now everyday work in additive manufacturing. They are also exactly the parts where open-source FEA has to prove itself: dirty CAD, millions of quadratic elements, stress concentrations everywhere. So we asked two practical questions:

  1. Is the “Ultralight” design strong enough?
  2. Do CalculiX and code_aster give the same answer, and what does it cost to find out on cloudHPC?

Results at a glance

Finest CalculiX mesh (M4, 2.70 M nodes, 1.79 M C3D10). von Mises values are nodal (extrapolated and averaged). Yield of Ti-6Al-4V: 903 MPa (131 ksi).

Load caseLoadMax |u| CalculiX M4 [mm]Max |u| code_aster M3 [mm]Max |u| SimJEB / OptiStruct [mm]σVM 99.9th pct. [MPa]Volume above yieldVerdict (linear-elastic)
LC1 vertical8,000 lbf = 35.6 kN4.274.324.072,341 (2.6× σy)2.98 %❌ yields
LC2 horizontal8,500 lbf = 37.8 kN5.345.365.152,272 (2.5× σy)9.81 %❌ yields
LC3 42° from vertical9,500 lbf = 42.3 kN0.820.830.80844 (0.93× σy)0.01 %⚠️ yields very locally (max 1,149 MPa, 0.01 % of volume)
LC4 torsion5,000 lbf·in = 565 N·m1.531.611.361,143 (1.3× σy)0.21 %❌ yields locally

The case

Set-up of the GE bracket FEA: bolt bores fixed, pin load through an RBE3 coupling, four GE load cases

Geometry. The “Ultralight GE Engine Bracket – 9.92 % of original weight” is a strut-and-lug design. A handful of thin struts (Ø6–10 mm) carry the clevis to the four bolt lugs. The GrabCAD download contains an IGES file of trimmed B-spline surfaces, not a solid: 354 faces, of which 239 are B-splines and 115 are surfaces of revolution.

We sewed the faces into a closed shell with OpenCASCADE (BRepBuilderAPI_Sewing, tolerance 0.01 mm). This left 0 free edges and gave a valid solid of 45,924 mm³, which is 205 g at 4.47 g/cm³. SimJEB reports 45,453 mm³ (203 g) after its own cleaning.

Interfaces and boundary conditions (from the challenge page):

  • Bolts B1–B4 (0.375-24 bolts, considered infinitely stiff): all three translations of the four bolt-bore surfaces fixed. The bores are Ø10.3 mm (three bolts) and Ø10.7 mm (one bolt).
  • Pin (Ø0.75 in, infinitely stiff): the two clevis bores (Ø20.4 mm) are tied to a reference point. The point sits on the pin axis, midway between the clevis arms. The tie is a distributing (RBE3-type) coupling: CalculiX *COUPLING + *DISTRIBUTING, code_aster LIAISON_RBE3. Forces and the torsional moment are applied to that point. SimJEB uses the same approach: rigid RBE2 bolts and an RBE3 load spider.
  • Directions in the model frame, with the engine mounting face at z = 0 and the clevis pointing to −z:
  • “vertical up” = away from the engine (−z);
  • “horizontal out” = +x, perpendicular to the pin;
  • the 42° case combines the two;
  • torsion is a moment about x through the pin centre.
  • Material: Ti-6Al-4V, E = 113.8 GPa, ν = 0.342, ρ = 4.47 g/cm³ (the SimJEB values), σy = 131 ksi = 903 MPa (challenge page).
  • Analysis: linear static, four load cases in one run.

How the runs were set up

ItemSetting
CAD repairOpenCASCADE via cadquery-ocp (sewing 0.01 mm) → STEP; gmsh OCC healing (fix degenerated / small edges / small faces)
Meshergmsh 4.15.2, Delaunay 3D + Netgen optimisation, curvature-based sizing (12 elements per 2π), size factor 2.0 / 1.0 / 0.6 / 0.4
Elements10-node tetrahedra (CalculiX C3D10, code_aster TETRA10), straight-sided (see “What didn’t work”)
MeshesM1 257,032 nodes · M2 508,429 · M3 1,148,007 · M4 2,703,823 (1,791,006 elements)
CalculiXcalculiX-2.19-PARDISO on cloudHPC, *STATIC, SOLVER=PARDISO, four *STEPs
code_astercodeAster-17.3.17_mpi, 1 MPI process + OpenMP, MACRO_ELAS_MULT (one factorisation, four load cases), MUMPS, UNV mesh from gmsh
InstancesSpot. M1–M2: 8 vCPU standard; M3: 16 vCPU highmem; M4: 32 vCPU highmem (256 GB)
Post-processingOne Python script reads the CalculiX .frd and the code_aster fields (exported as NumPy from the .comm) and computes every number in this post

Stress metrics. A peak nodal stress on a raw CAD model is mostly a measure of its sharpest corner, so we report three numbers:

  • the 99.9th percentile of nodal von Mises;
  • the maximum at nodes more than 3 mm from the bolt and pin bores;
  • the share of the bracket volume whose element-average von Mises exceeds yield.

For the maximum far from the bores we also leave out a 1 mm sphere around one point: a sharp re-entrant corner at x = 16.5, y = 52.2, z = −10.0 mm, where four B-spline faces meet. Its stress was 25 GPa on M1, then 7.5 GPa on M2 and below 2.4 GPa on M3–M4. That is a coarse-mesh sliver artefact, not a value that converges. The percentile and the volume above yield include every node.

Results

1. Mesh convergence of the displacements

Mesh convergence of the maximum displacement for the four GE load cases: CalculiX, code_aster and SimJEB

MeshNodesLC1 [mm]LC2 [mm]LC3 [mm]LC4 [mm]Mesh volume vs CAD
M1257,0324.4425.6480.8831.604−3.1 %
M2508,4294.3065.4060.8351.548−0.9 %
M31,148,0074.2805.3540.8241.537−0.3 %
M42,703,8234.2725.3370.8211.533−0.15 %
SimJEB (OptiStruct, 1st-order tets, ~208 k elements)4.0745.1540.7991.359−1.0 % (its own cleaning)

What we learned

  • From M3 to M4 the maximum displacement changes by 0.2–0.4 %: M3 (1.15 M nodes) is converged for stiffness. M1 over-predicts by 4–7.5 %. That is mostly because straight-sided tets cut corners on the thin round struts: the M1 mesh has 3.1 % less volume than the CAD.
  • Our converged values are 3–5 % above SimJEB for the three force cases and 13 % above in torsion. That is the expected direction for first-order tetrahedra, which are too stiff in bending (shear locking). Torsion is also the case most sensitive to how the RBE3 spider is defined. Given different meshers, element orders and CAD cleaning, the agreement with an independent commercial-code dataset is good.

2. Stresses vs yield

Linear-elastic von Mises stress vs Ti-6Al-4V yield for the four GE load cases

Load caseσVM 99.9th pct. M1 → M4 [MPa]Max σVM > 3 mm from bores, M4 [MPa]Volume > σy M1 → M4Volume > 2 σy (M4)SimJEB max σVM [MPa]
LC1 vertical2,342 → 2,3414,0603.54 % → 2.98 %0.10 %2,709
LC2 horizontal2,495 → 2,2723,6389.91 % → 9.81 %0.29 %2,406
LC3 42°904 → 8441,1490.00 % → 0.01 %0.00 %841
LC4 torsion1,199 → 1,1431,5120.20 % → 0.21 %0.00 %1,138
Von Mises stress under the horizontal load case (LC2), CalculiX M3, deformation ×5

What we learned

  • The weak spots are where the struts join the bolt lugs B1 and B3, and the thin diagonal strut to B2/B4 in bending (red in the contour plots). Under LC1 and LC2 the struts work in bending rather than as a truss, and 3–10 % of the material goes past yield. A linear analysis cannot say how far the plastic zone would spread before collapse. It does say clearly that this design would deform permanently under the GE test loads.
  • The volume above yield is the most mesh-robust stress metric here: it moves by less than 0.6 percentage points from 257 k to 2.7 M nodes. The 99.9th percentile moves by up to 9 %. The “max far from the bores” value drifts with refinement (3,946 → 4,102 → 4,060 MPa in LC1, M1 → M3 → M4) because the fixed bolt bores are themselves a stiff idealisation.
  • Context from SimJEB: “Ultralight” is the 2nd lightest of 381 designs. Its OptiStruct peak stresses rank 352nd (vertical) and 362nd (horizontal) of 381 from the lowest. Only 147 designs have all four peak stresses below yield, and the lightest of those weighs 345 g. That is close to the 327 g of the challenge winner. Lightest is not best.

Contours of the other load cases (CalculiX M3, deformation ×5):

Von Mises stress under the vertical load case (LC1), CalculiX M3

Von Mises stress under the 42-degree load case (LC3), CalculiX M3

Von Mises stress under the torsion load case (LC4), CalculiX M3

SimJEB: mass vs worst-case displacement of 381 GE bracket designs, with the Ultralight entry highlighted

3. CalculiX vs code_aster on the same mesh

MeshLoad caseMax |u| CalculiX / code_aster [mm]Δ max |u|Δ max |u| > 20 mm from pin axisMax σVM far from bores CalculiX / code_aster [MPa]Correlation of σVM fields
M1LC14.442 / 4.438−0.08 %−0.09 %3,946 / 3,9460.9999
M1LC41.604 / 1.594−0.67 %−0.70 %1,499 / 1,5000.9996
M2LC14.306 / 4.328+0.50 %+0.05 %3,955 / 3,9580.9999
M2LC41.548 / 1.583+2.21 %−0.62 %1,496 / 1,4770.9996
M3LC14.280 / 4.324+1.01 %+0.07 %4,102 / 4,1030.9995
M3LC25.354 / 5.356+0.03 %−0.01 %3,678 / 3,6800.9998
M3LC30.824 / 0.828+0.40 %+0.04 %1,123 / 1,1240.9980
M3LC41.537 / 1.610+4.75 %−0.85 %1,483 / 1,4450.9983

The reactions at the bolts balance the applied loads to the last printed digit in both codes.

What we learned

  • Same mesh, same physics, same answer. Away from the pin, the two open-source solvers agree to 0.15 % in the three force cases and 0.85 % in torsion. The away-from-bores stress maxima differ by at most 0.25 % in the force cases and by up to 2.6 % in torsion. The nodal stress fields correlate at 0.998–0.9999.
  • The coupling is where they differ. The maximum displacement sits on the rim of the clevis lug, about 13 mm from the pin axis, so it depends on how the pin load is spread. CalculiX’s *DISTRIBUTING coupling weights the bore nodes by their tributary area. code_aster’s LIAISON_RBE3 with a single COEF_ESCL gives every node, corner or mid-side, the same weight. As the mesh is refined that weighting changes, and the torsion case drifts from −0.7 % to +4.8 %. If you compare codes, compare them away from the load introduction, or give the RBE3 weights explicitly.

4. Run time and cost

Run time and cost of the CalculiX and code_aster runs on cloudHPC

RunMesh (nodes)Instance (spot)EquationsSolver wall timePeak RAMBilled cost
CalculiX 2.19 PARDISOM1 (257 k)8 vCPU standard739,9921.7 min~5 GB€0.057
CalculiX 2.19 PARDISOM2 (508 k)8 vCPU standard1,490,3915.3 min~14 GB€0.081
CalculiX 2.19 PARDISOM3 (1.15 M)16 vCPU highmem3,400,85714.3 min~40 GB€0.341
CalculiX 2.19 PARDISOM4 (2.70 M)32 vCPU highmem8,058,44147.1 min~124 GB€1.76
code_aster 17.3.17 MUMPSM1 (257 k)8 vCPU standard833,322*2.5 min6.9 GB€0.067
code_aster 17.3.17 MUMPSM2 (508 k)8 vCPU standard1,595,097*7.8 min16.3 GB€0.104
code_aster 17.3.17 MUMPSM3 (1.15 M)16 vCPU highmem3,530,367*33.1 min83.6 GB€0.653
Two failed code_aster set-ups (see below)€0.106
Total, 9 runs€3.17

* including Lagrange multipliers. The CalculiX RAM figures are 1-minute samples of the machine RAM; the code_aster figures are the VmPeak reported by code_aster.

What we learned

  • CalculiX refactorises the stiffness matrix in every *STEP. Four load cases cost four factorisations: about 10–12 minutes each on M4. code_aster’s MACRO_ELAS_MULT factorises once and solves four right-hand sides; its solve phase on M3 took 13.7 min against 14.3 min for the whole CalculiX run.
  • code_aster’s real memory bottleneck was the RBE3, not MUMPS. Building LIAISON_RBE3 took 9 s with 4,473 slave nodes (M1), 104 s with 14,827 (M2) and 757 s with 34,557 nodes (M3), almost as long as the whole factorise-and-solve (821 s). On M3 it was also the source of the 83.6 GB memory peak (MUMPS itself needed about 13 GB), and that peak is the reason this run needed a highmem machine. Use fewer slave nodes (corner nodes only, or a ring of nodes) and the same model fits on a much cheaper instance.
  • A converged answer (M3, 1.15 M nodes) costs €0.34 with CalculiX. The whole two-code, four-mesh study cost about as much as a coffee and a croissant.

What didn’t work (and how we fixed it)

  1. The GrabCAD “Download specification” link of the original GE bracket STEP now returns 404, so we could not run the original part for comparison. The SimJEB dataset fills that gap for context.
  2. IGES surfaces, not a solid. gmsh’s HXT 3D mesher failed on the raw sewn shape (“HXT 3D mesh failed”). The Delaunay mesher then reported “No tetrahedra in region 1” (5 distorted surface triangles). Turning on gmsh’s OCC healing options (OCCFixDegenerated, OCCFixSmallEdges, OCCFixSmallFaces, OCCSewFaces, OCCMakeSolids) fixed it.
  3. Curved quadratic tets. With HighOrderOptimize gmsh crashed (BFGS errors). Without it, 6 of 310 k curved elements had negative Jacobians. We used straight-sided quadratic tets (Mesh.SecondOrderLinear = 1), which cost the 3 % volume loss on M1 seen above. code_aster still flagged 13 near-degenerate TETRA10 on M1 (alarm MODELISA8_15, edge ratio ≈ 0.0008–0.0009), at CAD slivers; 5 on M2 and 1 on M3.
  4. CalculiX *DISTRIBUTING needs a facial surface. With a node-based surface CalculiX stops with “a nodal surface is not allowed”. We built *SURFACE, TYPE=ELEMENT from the C3D10 faces on the bore.
  5. code_aster run 1, MODELISA5_7. gmsh writes a 0-D physical group (the pin reference point) to UNV as a node plus a point cell, and the point cell is missing from the element dataset. Fix: keep only the node in the UNV group and create the POI1 with CREA_MAILLAGE(CREA_POI1=...).
  6. code_aster run 2: EXTR_COMP is gone in version 17 (“has been removed. Use ‘getValuesWithDescription()'”). The solve itself had finished. A Python extraction error after it still aborts the job (<F>_ABNORMAL_ABORT), so we now also write a MED file before any Python post-processing.

How to run this case on cloudHPC

  • CalculiX: put bracket.inp and the mesh include at the root of the case folder. Give the include an extension other than .inp (we used bracket_mesh.msh), because cloudHPC runs the first .inp in alphabetical order. Pick calculiX-2.19-PARDISO and set SOLVER=PARDISO on *STATIC. Budget about 50 GB of RAM per million quadratic-tet nodes (sampled peak: ~40 GB at 1.15 M nodes, ~124 GB at 2.7 M): standard instances up to ~0.5 M nodes, highmem above.
  • code_aster: place bracket.export, bracket.comm and the .unv mesh at the root. Add F libr ... R 30-style lines to the .export to bring back your own files: we return a JSON summary and a compressed NumPy field file next to the .rmed. Without NB_SOUS_DOMAINE/NIVEAU_PARALLELISME in the .comm the run uses 1 MPI process with vCPU/2 OpenMP threads.
  • Both: load cases this size are cheap enough to run on spot instances. Check the solver log and not only the run status. A code_aster run that crashes in the Python part after the solve still shows as COMPLETED.
  • All inputs, meshing and post-processing scripts are in the cases/ folder of the download.

FAQ

What is the GE jet engine bracket challenge? It was a 2013 GrabCAD design competition sponsored by GE Aviation. Entrants had to cut the mass of a titanium engine-lifting bracket for additive manufacturing while keeping its four bolt interfaces and clevis pin, and survive four static loads: 8,000 lbf vertical, 8,500 lbf horizontal, 9,500 lbf at 42° and 5,000 lbf·in of torsion. About 700 designs were submitted. The top ten were printed and load-tested by GE.

Which boundary conditions should I use for the GE bracket in FEA? The challenge specifies rigid bolts and a rigid pin. A common choice, used both here and in the SimJEB dataset, is to fix the bolt-bore surfaces and apply the load through an RBE3 (distributing) coupling on the clevis bores, referenced to the pin centre midway between the clevis arms.

Do CalculiX and code_aster give the same results? On the same quadratic-tet mesh, yes. In this study they agreed to 0.15 % on displacements away from the load introduction (0.85 % in torsion) and to within a few MPa on peak stresses in the force cases. Differences of up to 5 % appeared only near the pin, because CalculiX weights the distributing coupling by area and code_aster’s LIAISON_RBE3 with a single coefficient weights every node equally.

How many elements does a converged FEA of a topology-optimised bracket need? For this 205 g bracket, the maximum displacement changed by at most 0.4 % between 1.15 M and 2.7 M nodes of quadratic tets. Peak stresses near sharp corners never fully converge, so check the stressed volume or percentile stresses instead.

How much does it cost to run CalculiX or code_aster in the cloud? On cloudHPC spot instances, a converged 1.15 M-node, four-load-case linear static run cost €0.34 with CalculiX 2.19 (PARDISO) and €0.65 with code_aster 17.3.17. A 2.7 M-node CalculiX run (8 M equations, 32 vCPU, 256 GB) cost €1.76.

Is the “Ultralight” GrabCAD bracket strong enough for the GE loads? Not in a linear-elastic sense. Under the vertical and horizontal loads, about 3 % and 10 % of its volume exceeds the 903 MPa yield of Ti-6Al-4V, with the highest stresses at the strut-to-lug junctions.

References

  1. GrabCAD, GE jet engine bracket challenge: description, load cases and material. https://grabcad.com/challenges/ge-jet-engine-bracket-challenge
  2. J. Schorsch, Ultralight GE Engine Bracket – 9.92 % of original weight, GrabCAD Community Library, 2013. https://grabcad.com/library/ultralight-ge-engine-bracket-9-92-of-original-weight-1
  3. W.T. Carter, D.J. Erno, D.H. Abbott, C.E. Bruck, G.H. Wilson, J.B. Wolfe, The GE Aircraft Engine Bracket Challenge: An Experiment in Crowdsourcing for Mechanical Design Concepts, Solid Freeform Fabrication Symposium, 2014. https://utw10945.utweb.utexas.edu/sites/default/files/2014-110-Carter.pdf
  4. E. Whalen, A. Beyene, C. Mueller, SimJEB: Simulated Jet Engine Bracket Dataset, Computer Graphics Forum 40(5), 9–17, 2021. https://doi.org/10.1111/cgf.14353. Dataset: https://doi.org/10.7910/DVN/XFUWJG, https://simjeb.github.io
  5. ennomotive, GE solves real business problems using the crowd: original bracket 2,033 g, winning design 327 g. https://ennomotive.com/ge-solves-real-business-problems-using-the-crowd
  6. G. Dhondt, K. Wittig, CalculiX. http://www.calculix.de
  7. EDF, code_aster. https://www.code-aster.org
  8. C. Geuzaine, J.-F. Remacle, Gmsh: a 3-D finite element mesh generator with built-in pre- and post-processing facilities, IJNME 79(11), 1309–1331, 2009. https://doi.org/10.1002/nme.2579
  9. cloudHPC blog, Decoding Performance: A Scalability Showdown Between CalculiX and Code_Aster (internal link).

CloudHPC is a HPC provider to run engineering simulations on the cloud. CloudHPC provides from 1 to 224 vCPUs for each process in several configuration of HPC infrastructure - both multi-thread and multi-core. Current software ranges includes several CAE, CFD, FEA, FEM software among which OpenFOAM, FDS, Blender and several others.

New users benefit of a FREE trial of 300 vCPU/Hours to be used on the platform in order to test the platform, all each features and verify if it is suitable for their needs