Topology optimization: SIMP, optimality criteria and a slider through every iteration

Topology optimization asks a different question from the usual analysis. Not "is this part strong enough" but "where does material need to be at all". You hand it a block of design space, the loads, the supports and a volume target; it decides which elements deserve to exist.

WebCAE now has that loop on the desktop build.

How it works

Every element gets a density between zero and one, and its stiffness is scaled by that density raised to a penalization power — the SIMP approach. The power starts low and rises to three as the run proceeds, which lets the layout form before intermediate densities are punished out of existence. A density filter with a length-scale radius keeps the result from degenerating into a checkerboard and gives the structure a minimum member size.

For the classic problem — minimise compliance at a fixed volume fraction — the update is done by optimality criteria, which needs no extra solve because the sensitivity of compliance is self-adjoint. When the problem has more than one constraint, or an objective that is not compliance, the run switches to the method of moving asymptotes instead, and the sensitivities come from an adjoint solve: one extra linear solve per constraint, regardless of how many elements there are.

What you can ask for

Objectives: minimum compliance, minimum mass, or maximum eigenfrequency. Constraints: volume fraction, maximum displacement at a chosen node or vertex in a chosen direction, maximum von Mises stress via a p-norm aggregate with relaxation, and minimum eigenfrequency. The optimizer is chosen automatically from the shape of the problem, or you can pin it.

The design domain accepts four-node and ten-node tetrahedra and eight- and twenty-node hexahedra, and it runs at whatever element order your model already uses rather than quietly downgrading you to first order.

Scrubbing the iterations

The density history is kept, so the panel has a slider across all iterations with the compliance and volume of the selected one — not just the final numbers. Watching the layout form is the fastest way to tell a converging run from one that is oscillating, and it makes the effect of the filter radius obvious in a way that no static picture does.

When you like the result, an iso-surface is extracted from the density field by marching tetrahedra, smoothed with a volume-preserving Taubin filter, and handed back to the model tree as a body you can look at, export as STL, or use as the starting point for the real part.

Why the loop is moving to C++

Fifty iterations means fifty stiffness assemblies, and the assembly is the expensive part. Measured on a 100,000-element tetrahedral mesh, assembling the scaled stiffness matrix in JavaScript takes about 224 ms per iteration at first order and about 2.1 s at second order; in native C++ with OpenMP the same work is 8–12 ms and 35–45 ms. Over a full run that is 11 s versus half a second, and 105 s versus two seconds — with the second-order path also allocating well over a gigabyte per step in the browser. Moving the element-energy computation into the native core also cuts what has to cross the process boundary from tens of megabytes of displacement vectors to under a megabyte of energies.

Where it stands, honestly

This is a working research pipeline rather than a finished CAD feature, and we have written down exactly what still separates the two: the re-analysis currently runs on the original mesh rather than on the materialized geometry, the returned body is a boundary mesh in a solid's clothing rather than a real B-Rep, and several of the advanced criteria are further from production than their presence in the UI suggests. That list is the subject of its own post — we would rather publish it than let it be discovered.