Choose a simulation method and precision settings¶
Start with SimulationOptions(method="auto", integrator="auto") and inspect the actual choice in the result. Fix a method when you need a numerical comparison. An inapplicable explicit request is rejected rather than silently replaced.
Choose the state representation¶
| Task | Selection basis |
|---|---|
| Ideal digital circuit or general Hybrid program | Usually state_vector |
| Eligible ideal standalone Analog program under hard blockade | subspace when an appropriate blockade basis exists |
| Small noisy reference | density_matrix when resources and channels permit |
| Stochastic trajectory estimation or atom loss | trajectory, recording trajectory count and seed |
Finite van der Waals interactions are not infinite hard blockade. Nor are arbitrary Digital gates in Hybrid programs automatically projected into a blockade subspace. Do not change the physical model solely to save memory.
Choose the time integrator¶
Purely Digital gates need no Analog time integration. For Analog evolution, adaptive DOP853 uses rtol, atol and the step limit, splitting at declared control boundaries. Fixed-step Krylov approximates controls at time-slice midpoints. Increase time resolution gradually and compare the observables that matter to your experiment.
The trajectory path currently uses fixed steps and rejects an adaptive integrator. Recording tolerances in a fixed-step result does not mean they controlled adaptive step selection. Smaller tolerances alone do not improve fixed-step precision.
Check what was applied¶
Run the resource-planning example and inspect method_selected, execution_dtype, tolerance_applied and candidate rejection reasons. See SimulationOptions and LocalBackend for full parameter definitions.
Change one setting at a time: examine time resolution or tolerance first, then dtype. For trajectories, increase trajectories separately from final measurement shots. Retain each result and its applied settings instead of attributing every difference to randomness.
Execution currently uses CPU; explicit GPU requests fail planning. max_wall_time_seconds and target_statistical_error are presently plan metadata only. They do not enforce a deadline or automatically increase trajectory count.