Pasqal Challenge: ByteSkip

Inspiration

Pasqal's challenge came with one hard rule: every binary variable costs an atom, and the chip holds 80. Truck routing with weight limits is exactly where the textbook encoding blows that budget, because "no more than Q" needs extra helper bits. We wanted to find out how few atoms the problem really needs.

What it does

It splits customers into trucks (Track A, cluster-first) on Pasqal's neutral-atom emulator. Each customer gets one atom, placed on the chip where the customer sits on the map. The laser picks K "anchor" customers that are far apart, and every other customer then joins the nearest anchor that still has room. That takes 4 / 10 / 15 atoms for the three problem sizes, where the textbook encoding needs 14 / 45 / 80.

How we built it

Generated 9 instances (3 per size) and solved every one exactly first, so each result is measured against a proven best answer.
Model A: wrote the cost directly as a QUBO, with a capacity penalty and no slack bits (4 / 30 / 60 atoms).
Model B: one atom per customer, the atom layout is the customer map scaled so the blockade radius keeps close customers apart. The final laser detuning comes from the geometry, not from a solver.
Every layout and pulse built in Pulser and checked against AnalogDevice; runs on pulser-simulation and emu-sv, 1000 shots per setting, a small grid over laser strength, duration and detuning.
One command reproduces it all: python -m cvrp.run_all.

Challenges we ran into

Model A failed, and that failure shaped everything. Its penalty needs far-apart customers to interact strongly, but atoms only interact strongly when they sit close together. The layout would have to be the map turned inside out. On 10 customers, the correct plan ranked about 9,000th of 59,049 under the energy the atoms actually produced. So we changed the question: in Model B a bit means "this customer is an anchor", and close customers naturally block each other.

Results

Share of 1000 reads that give the proven best plan:

S: 51–91 % (random bits 25–27 %, random anchors 67 %)
M: 13–20 % (random bits 1.6–2.9 %, random anchors 13–30 %)
L: 2–32 % (random bits 0–0.2 %, random anchors 2.8–4.0 %)

That is 2–4×, 7–12× and at least 60× better than random bits. Against the stricter random-anchor baseline it is even on S and M, and up to 8× better on L. The price: on M and L only about half of the reads are usable.

What we learned

On an analog machine the encoding has to fit the physics, not just the math. A formula with fewer variables is worthless if no atom layout can reproduce it. We also learned to report the comparison that hurts us, not only the one that flatters us.

AI helped write most of the code, figures and slides. Every layout and pulse was checked by Pulser, every number traces to results/results.csv, and the report lists the AI mistakes we caught.