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

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:
- Is the “Ultralight” design strong enough?
- 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 case | Load | Max |u| CalculiX M4 [mm] | Max |u| code_aster M3 [mm] | Max |u| SimJEB / OptiStruct [mm] | σVM 99.9th pct. [MPa] | Volume above yield | Verdict (linear-elastic) |
|---|---|---|---|---|---|---|---|
| LC1 vertical | 8,000 lbf = 35.6 kN | 4.27 | 4.32 | 4.07 | 2,341 (2.6× σy) | 2.98 % | ❌ yields |
| LC2 horizontal | 8,500 lbf = 37.8 kN | 5.34 | 5.36 | 5.15 | 2,272 (2.5× σy) | 9.81 % | ❌ yields |
| LC3 42° from vertical | 9,500 lbf = 42.3 kN | 0.82 | 0.83 | 0.80 | 844 (0.93× σy) | 0.01 % | ⚠️ yields very locally (max 1,149 MPa, 0.01 % of volume) |
| LC4 torsion | 5,000 lbf·in = 565 N·m | 1.53 | 1.61 | 1.36 | 1,143 (1.3× σy) | 0.21 % | ❌ yields locally |
The case

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_asterLIAISON_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
| Item | Setting |
|---|---|
| CAD repair | OpenCASCADE via cadquery-ocp (sewing 0.01 mm) → STEP; gmsh OCC healing (fix degenerated / small edges / small faces) |
| Mesher | gmsh 4.15.2, Delaunay 3D + Netgen optimisation, curvature-based sizing (12 elements per 2π), size factor 2.0 / 1.0 / 0.6 / 0.4 |
| Elements | 10-node tetrahedra (CalculiX C3D10, code_aster TETRA10), straight-sided (see “What didn’t work”) |
| Meshes | M1 257,032 nodes · M2 508,429 · M3 1,148,007 · M4 2,703,823 (1,791,006 elements) |
| CalculiX | calculiX-2.19-PARDISO on cloudHPC, *STATIC, SOLVER=PARDISO, four *STEPs |
| code_aster | codeAster-17.3.17_mpi, 1 MPI process + OpenMP, MACRO_ELAS_MULT (one factorisation, four load cases), MUMPS, UNV mesh from gmsh |
| Instances | Spot. M1–M2: 8 vCPU standard; M3: 16 vCPU highmem; M4: 32 vCPU highmem (256 GB) |
| Post-processing | One 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 | Nodes | LC1 [mm] | LC2 [mm] | LC3 [mm] | LC4 [mm] | Mesh volume vs CAD |
|---|---|---|---|---|---|---|
| M1 | 257,032 | 4.442 | 5.648 | 0.883 | 1.604 | −3.1 % |
| M2 | 508,429 | 4.306 | 5.406 | 0.835 | 1.548 | −0.9 % |
| M3 | 1,148,007 | 4.280 | 5.354 | 0.824 | 1.537 | −0.3 % |
| M4 | 2,703,823 | 4.272 | 5.337 | 0.821 | 1.533 | −0.15 % |
| SimJEB (OptiStruct, 1st-order tets, ~208 k elements) | 4.074 | 5.154 | 0.799 | 1.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

| Load case | σVM 99.9th pct. M1 → M4 [MPa] | Max σVM > 3 mm from bores, M4 [MPa] | Volume > σy M1 → M4 | Volume > 2 σy (M4) | SimJEB max σVM [MPa] |
|---|---|---|---|---|---|
| LC1 vertical | 2,342 → 2,341 | 4,060 | 3.54 % → 2.98 % | 0.10 % | 2,709 |
| LC2 horizontal | 2,495 → 2,272 | 3,638 | 9.91 % → 9.81 % | 0.29 % | 2,406 |
| LC3 42° | 904 → 844 | 1,149 | 0.00 % → 0.01 % | 0.00 % | 841 |
| LC4 torsion | 1,199 → 1,143 | 1,512 | 0.20 % → 0.21 % | 0.00 % | 1,138 |

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):




3. CalculiX vs code_aster on the same mesh
| Mesh | Load case | Max |u| CalculiX / code_aster [mm] | Δ max |u| | Δ max |u| > 20 mm from pin axis | Max σVM far from bores CalculiX / code_aster [MPa] | Correlation of σVM fields |
|---|---|---|---|---|---|---|
| M1 | LC1 | 4.442 / 4.438 | −0.08 % | −0.09 % | 3,946 / 3,946 | 0.9999 |
| M1 | LC4 | 1.604 / 1.594 | −0.67 % | −0.70 % | 1,499 / 1,500 | 0.9996 |
| M2 | LC1 | 4.306 / 4.328 | +0.50 % | +0.05 % | 3,955 / 3,958 | 0.9999 |
| M2 | LC4 | 1.548 / 1.583 | +2.21 % | −0.62 % | 1,496 / 1,477 | 0.9996 |
| M3 | LC1 | 4.280 / 4.324 | +1.01 % | +0.07 % | 4,102 / 4,103 | 0.9995 |
| M3 | LC2 | 5.354 / 5.356 | +0.03 % | −0.01 % | 3,678 / 3,680 | 0.9998 |
| M3 | LC3 | 0.824 / 0.828 | +0.40 % | +0.04 % | 1,123 / 1,124 | 0.9980 |
| M3 | LC4 | 1.537 / 1.610 | +4.75 % | −0.85 % | 1,483 / 1,445 | 0.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
*DISTRIBUTINGcoupling weights the bore nodes by their tributary area. code_aster’sLIAISON_RBE3with a singleCOEF_ESCLgives 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 | Mesh (nodes) | Instance (spot) | Equations | Solver wall time | Peak RAM | Billed cost |
|---|---|---|---|---|---|---|
| CalculiX 2.19 PARDISO | M1 (257 k) | 8 vCPU standard | 739,992 | 1.7 min | ~5 GB | €0.057 |
| CalculiX 2.19 PARDISO | M2 (508 k) | 8 vCPU standard | 1,490,391 | 5.3 min | ~14 GB | €0.081 |
| CalculiX 2.19 PARDISO | M3 (1.15 M) | 16 vCPU highmem | 3,400,857 | 14.3 min | ~40 GB | €0.341 |
| CalculiX 2.19 PARDISO | M4 (2.70 M) | 32 vCPU highmem | 8,058,441 | 47.1 min | ~124 GB | €1.76 |
| code_aster 17.3.17 MUMPS | M1 (257 k) | 8 vCPU standard | 833,322* | 2.5 min | 6.9 GB | €0.067 |
| code_aster 17.3.17 MUMPS | M2 (508 k) | 8 vCPU standard | 1,595,097* | 7.8 min | 16.3 GB | €0.104 |
| code_aster 17.3.17 MUMPS | M3 (1.15 M) | 16 vCPU highmem | 3,530,367* | 33.1 min | 83.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’sMACRO_ELAS_MULTfactorises 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_RBE3took 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)
- 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.
- 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. - Curved quadratic tets. With
HighOrderOptimizegmsh 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 (alarmMODELISA8_15, edge ratio ≈ 0.0008–0.0009), at CAD slivers; 5 on M2 and 1 on M3. - CalculiX
*DISTRIBUTINGneeds a facial surface. With a node-based surface CalculiX stops with “a nodal surface is not allowed”. We built*SURFACE, TYPE=ELEMENTfrom the C3D10 faces on the bore. - 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 withCREA_MAILLAGE(CREA_POI1=...). - code_aster run 2:
EXTR_COMPis 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.inpand the mesh include at the root of the case folder. Give the include an extension other than.inp(we usedbracket_mesh.msh), because cloudHPC runs the first.inpin alphabetical order. PickcalculiX-2.19-PARDISOand setSOLVER=PARDISOon*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.command the.unvmesh at the root. AddF libr ... R 30-style lines to the.exportto bring back your own files: we return a JSON summary and a compressed NumPy field file next to the.rmed. WithoutNB_SOUS_DOMAINE/NIVEAU_PARALLELISMEin the.commthe 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
- GrabCAD, GE jet engine bracket challenge: description, load cases and material. https://grabcad.com/challenges/ge-jet-engine-bracket-challenge
- 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
- 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
- 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
- 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
- G. Dhondt, K. Wittig, CalculiX. http://www.calculix.de
- EDF, code_aster. https://www.code-aster.org
- 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
- 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