The standard advice for tuning a liquid class is to change one parameter at a time, re-run, and measure. It is good advice, it converges, and it is slow. For a single class it is fine, but a lab with dozens of demanding liquids, each with its own viscosity and volatility, feels the cost quickly, and a recurring forum thread on liquid class optimization is essentially a group of people asking whether there is a smarter way. The answer is that there are smarter ways, they come with real tradeoffs, and the biggest practical win is often not the algorithm but running the loop while nobody is watching.
Why one-knob tuning is the default
Changing one parameter per run is the default because it teaches you causation. When you slow the flow rate and the spread tightens, you know the flow rate did it. That clarity is worth a lot, especially while you are still learning how a liquid behaves, and it is why practitioners keep recommending it even knowing it is slow. Vendors tend to tune the same way in the field, incremental and one variable at a time, and one point the thread makes is reassuring: much of the time the default classes are already close, so the one-knob loop only has a short distance to travel.
The limitation shows up when parameters interact. Flow rate, settling time, and blowout do not act independently for a hard liquid, and one-at-a-time tuning explores that coupled space slowly, holding everything else still while it walks one axis at a time.
Design of experiments
Design of experiments, or DoE, is the structured answer to interaction. Instead of moving one knob at a time, you lay out a planned set of runs that vary several parameters together, then fit a model that separates each effect and, crucially, the interactions between them. You get more information per run and you see that, say, a longer settling time only helps when the flow rate is already low. The cost is up-front design and more runs in a batch, and a certain discipline in setting it up, which is why it tends to appear in labs that tune enough classes to amortize the overhead.
Bayesian optimization
The more ambitious approach raised in that discussion is Bayesian optimization, and it fits the problem well. Tuning a class is a multi-objective search, you want trueness and tight spread at once, over a space where each measurement is expensive. Bayesian optimization builds a running model of the response surface and uses it to choose the next most informative settings to try, converging on good parameters in fewer measurements than a grid or a random walk. It shines exactly where measurements cost the most, which pipetting measurements do. The tradeoff is complexity: you need the tooling to propose settings, apply them, and read results back, which is more than most GUIs offer out of the box.
The real unlock is running it unattended
Here is the part of the thread that matters more than the choice of algorithm. On some platforms you cannot edit a liquid class while a method runs, which appears to block any automated loop. Practitioners get around it by going underneath the GUI, adjusting parameters through the underlying database or custom scripting libraries, so the deck can dispense, measure on an integrated balance, adjust, and repeat without a human in the seat. The result is that a slow method becomes fast simply by running overnight. A one-knob loop that would take days of attended work finishes by morning when it runs itself.
- One knob at a time: best for learning a new liquid and for small numbers of classes; slow but transparent.
- DoE: best when parameters clearly interact and you tune enough to justify the setup; efficient and rigorous.
- Bayesian optimization: best for expensive measurements and multi-objective goals; powerful but tooling-heavy.
- Automate whichever you choose: the overnight, unattended loop is the biggest practical speedup regardless of the search strategy on top of it.
The fastest tuning is not always the cleverest algorithm. Pick a search that matches how much you tune, then let the deck run it overnight, because unattended iteration beats a smarter method you have to babysit.