Two Powders, One Auger: Watching a Mixer Earn Its Keep
You can stir cream into your coffee, but you will never stir it back out — mixing is the rare everyday process that only runs one way. Industry leans on that arrow hard: every tablet, every batch of concrete, every bag of drink powder depends on getting two or more ingredients blended uniformly, and the machine that does it is usually some variation on a turning screw. So we built one — a small auger blender — and let the discrete-element physics in Ansys Rocky show us the blend, particle by particle, on the GPU.
The physics: mixing is convection you can’t see into
A granular mixer doesn’t blend by diffusion the way a gas does — it blends by convection. The screw physically scoops material from the bottom, carries it up the flight, and drops it back near the wall, setting up a slow circulation that folds the two halves through each other turn after turn. Get the geometry and speed right and the bed homogenizes; get them wrong and you get dead zones the screw never reaches, or — worse — the kind of size-driven de-mixing we showed in our Brazil-nut and Plinko posts, where motion sorts grains apart instead of together.
The only way to really see that circulation is to track every grain — which is exactly what a discrete-element (DEM) solver does: it follows each particle and resolves every contact force between them. That’s a lot of bookkeeping (here, thousands of contacts updating thousands of times a second), which is why Rocky runs it on the GPU.
Inside the model
The apparatus is a deliberately simple bench blender: an open-top cylindrical bin, 120 mm across and 160 mm tall, with a single central helical auger — 18 mm shaft, 104 mm flight (so an ~8 mm wall gap), 50 mm pitch — turning at 120 RPM. We load it segregated on purpose: Powder A (blue) packed in the left half, Powder B (red) in the right, roughly 0.3 kg each. Both are 4 mm spheres at 1500 kg/m³ — a coarse stand-in for real powder (more on that below).
Contacts use Rocky’s linear-hysteresis model, gravity points down the axis, and we ran 3.0 seconds of real blending — about six full auger revolutions — writing a frame every 0.025 s. The solve carried 9,940 particles on an NVIDIA RTX A1000 and took about 78 minutes of wall time.
The other half of the story: we scripted every click
The simulation is only half of what this demo proves. The whole thing — import the vessel, build the parametric auger, set the two segregated powder beds, configure the solver, launch on the GPU, and render three camera angles — was driven from a single Python script, no hand-clicking in the Rocky GUI. That’s the part a channel customer actually cares about: a mixer study you can re-run with a new screw pitch or RPM by changing two numbers and pressing go.
It wasn’t friction-free. The remote scripting route (the Pyro5 RPC bridge PyRocky expects) wasn’t
available on this machine, so we pivoted to driving Rocky in-process via Rocky.exe --script
instead — same automation, different door. We wrote that troubleshooting trail up honestly in a
debugging journey, because the workarounds are usually
more useful to the next engineer than the clean final script.
Have a mixer, blender, or conveyor whose granular behavior you need to see inside? The same scripted Rocky DEM workflow — parametric geometry, GPU solve, repeatable post-processing — is how Rand Simulation helps clients dial in screw geometry, fill level, and speed before cutting metal. That’s innovation through insight.
