The most expensive place to find a mistake in a protocol is on the deck, mid-run, with reagents committed and a plate half-filled. The cheapest place is on a screen before anything moves. Simulation, sometimes called a dry run, executes a protocol without dispensing a drop, and it catches a surprising share of problems while they are still free to fix.
What simulation actually checks
A simulator steps through the protocol the way the instrument would, tracking state without moving liquid. That lets it flag a class of errors that are invisible when you only read the code.
- Deck and motion problems: a tip rack in the wrong slot, a move that would collide, a labware item the protocol references but never placed.
- Volume accounting: a source well asked for more than it holds, a tip box that runs out partway through, a destination that overflows.
- Sequence errors: dispensing before aspirating, forgetting a tip change where one is required, mixing after the tip has already ejected.
- Feasibility: steps that assume a labware item or module the deck does not actually have.
Visualization makes the abstract concrete
A deck visualization turns the run into something you can watch: which well is touched when, how the plate fills, where the arm travels. Seeing it is how you catch the layout mistakes that read as correct in code but are obviously wrong on screen, like filling a plate in the wrong direction or skipping a column.
What simulation cannot tell you
Simulation validates logic and layout, not physics. It will not tell you that your liquid class drips, foams, or short-fills, because it does not model the liquid. That is still a job for a real run and a real measurement. Think of simulation as proving the protocol is sound and the deck is right, so that when you do commit reagents, the only open question is the liquid itself.