So I finally decided to stop LARPing as a simulator enjoyer and actually run Qiskit on IBM Quantum like a responsible adult. Cue me falling down a rabbit hole of Sampler vs Estimator vs “just use execute and suffer.” Before I reinvent VQE-by-regret, can the hive mind sanity-check these battle tactics?
Primitives vs legacy: For anything expectation-value-ish, Estimator is the cool kid, Sampler for bitstrings-got it. But if I already have good measurement bases and custom observables, when does Estimator actually beat rolling my own sampling + post-processing? Is there a non-marketing description of what resilience_level really does at each setting, and how much circuit overhead it adds?
Reproducibility without sacrificing goats: seed_transpiler gives me layout determinism, kind of. But day-to-day calibration shifts mutate durations and errors, which presumably mutates scheduling and mitigation. Is there a recommended “reproducible enough” checklist that doesn’t involve cryogenics in my kitchen? For example:
- Cache transpiled circuits per backend.target snapshot?
- Re-schedule on each run but lock layout with initial_layout?
- Avoid approximation_degree changes across sessions?
Sessions and queue Tetris: The docs whisper that sessions reduce queue penalties, but what’s the practical batching strategy for large sweeps?
- Many small Sampler/Estimator calls inside one long session, or one chunky call with hundreds of circuits?
- Any rule-of-thumb for circuits-per-call vs shots-per-circuit to avoid “you have offended the runtime” errors?
- Do resilience levels internally multiply my circuit count to the point that my cost estimate becomes a work of speculative fiction?
Transpilation shenanigans: On heavy-hex devices, I can pin a path with initial_layout and SabreLayout, but directionality of ECR still bites. Can I hard-require a specific two-qubit orientation, or is this “we do our best, good luck”? Also, with Target-based transpilation in 1.x, is there a blessed combo of passes for dynamic circuits that won’t delete my mid-circuit measurements out of “optimization”?
Dynamic circuits reality check: What’s the least painful way to mix mid-circuit measurements/feedback with primitives? Are there gotchas where Aer happily simulates my if-else while hardware says “cute idea”? Bonus points if someone has a mental model for latency of classical feedback across qubits so I don’t schedule a race condition with physics.
Error mitigation dogpile: If resilience_level>0 already sprinkles twirling, M3, ZNE, or friends, should I still add my own measurement calibration or dynamical decoupling? Or do we end up with double-DD like a quantum espresso shot that makes coherence worse?
Custom pulses and the Runtime wall: Am I correct that custom calibrations/pulses are basically a no-go with Runtime primitives right now? If I want bespoke echoed-CR shaping, do I have to drop to pulse-level jobs outside Runtime and accept the queue gods’ judgment?
Cost forecasting for people who like numbers: Given N circuits and S shots, can I estimate the actual number of hardware executions after resilience/optimization expansion? Or is the multiplier device- and day-dependent enough that I should just set a budget and prepare to be surprised?
“It worked on Aer” bingo: Any canonical traps folks hit when moving from Aer to real hardware under primitives? I’m already aware of basis-gate mismatches and coupling maps; looking for the more devious ones like measurement return ordering, metadata assumptions, or classical register width limits.
If you’ve got a playbook that consistently turns “cute toy circuit” into “ran on hardware and the plot makes sense,” I will trade you one (1) grateful upvote and the knowledge that you saved yet another notebook from becoming a shrine to queue times.