QESEM by Qedma API reference

Default value: None

This flag enables users to obtain an estimate for the QPU time required to execute the circuit with QESEM.

• When set to None, the circuit will be executed with QESEM.
• If set to "analytical", an upper bound of the QPU time is calculated without consuming any QPU usage. This estimation has a 30-minute resolution (for example, 30 minutes, 60 minutes, 90 minutes, and so forth). It is typically pessimistic, and can only be obtained for single Pauli observables or sums of Paulis without intersecting supports (for example, Z0+Z1). It is primarily useful for comparing the complexity levels of different parameters provided by the user (circuit, accuracy, and so on).
• To obtain a more accurate QPU time estimation, set this flag to "empirical". Although this option requires running a small number of circuits, it provides a significantly more accurate QPU time estimation. This estimation has a 5-minute resolution (for example, 20 minutes, 25 minutes, 30 minutes, and so on). The user may choose to run the empirical time estimation in either batch or session mode. For more details, please see the execution_mode description. For example, in batch mode, empirical time estimation will consume less than 10 minutes of QPU time.
• Choices: "analytical" / "empirical" / None

Default value: 0.02

Will apply to pubs that don't have precision. The precision signifies the acceptable error on the expectation values of the observables in absolute value. Namely, the QPU runtime for mitigation will be determined to provide output values for all the observables of interest that fall within a 1$\sigma$ confidence interval of the target precision. If multiple observables are provided, the mitigation will run until the target precision is reached for each of the input observables.

• Choices: 0 < float

Default value: 3,600 (one hour)

Allows you to limit the QPU time, specified in seconds, to be used for the entire QESEM process. The default value is 3,600 seconds (one hour). Since the final QPU time required to reach the target accuracy is determined dynamically during the QESEM job, this parameter enables you to limit the cost of the experiment. If the dynamically-determined QPU time is shorter than the time allocated by the user, this parameter will not affect the experiment. The max_execution_time parameter is particularly useful in cases where the analytical time estimate provided by QESEM before the job starts is too pessimistic and the user wants to initiate a mitigation job anyway. After the time limit is reached, QESEM stops sending new circuits. Circuits that have already been sent continue running (so the total time may surpass the limit by up to 30 minutes), and the user receives the processed results from the circuits that ran up to that point. If you want to apply a QPU time limit shorter than the analytical time estimate, consult with Qedma to obtain an estimate for the accuracy achievable within the time limit.

• Choices: 0 < integer < 28,800 (8 hours)

Default value: standard

After a circuit is submitted to QESEM, it automatically prepares several alternative circuit transpilations and chooses the one that minimizes QPU time. For instance, alternative transpilations might utilize Qedma-optimized fractional RZZ gates to reduce the circuit depth. Of course, all transpilations are equivalent to the input circuit, in terms of their ideal output. To exert more control over the circuit transpilation, set the transpilation level in the options. While "transpilation_level": "standard" corresponds to the default behavior described above, "transpilation_level": "minimal_with_layout_opt" includes only minimal modifications required to the original circuit; for example, mapping the circuit to the device connectivity graph. Note that automatic hardware-mapping onto high-fidelity qubits is applied in any case.

For jobs that contain multiple input PUBs or multiple parameter-bound circuit instances, use "minimal_with_layout_opt".

• Choices: "minimal_with_layout_opt" / "standard"

Default value: batch

The user can choose to run the QESEM job in either a dedicated IBM session or across multiple IBM batches:

• Session Mode: Sessions are more expensive but result in a shorter time-to-result. Once the session begins, the QPU is reserved exclusively for the QESEM job. The usage calculation includes both the time spent on QPU execution and the associated classical computations (performed by QESEM and IBM). The QESEM Qiskit Function takes care of creating and closing the session automatically. For users with unlimited access to QPUs (for example, on-premises setups), it is recommended to use session mode for faster QESEM execution.

• Batch Mode: In batch mode, the QPU is released during classical computations, leading to lower QPU usage. As batch jobs typically span a longer period, there is a greater risk of hardware drifts; QESEM incorporates measures to detect and compensate for drifts, retaining reliability over extended runs.

• Choices: "session" / "batch"

Default value: True

This flag allows the user to execute the input circuit in parallel on the QPU. QESEM checks whether other patches on the QPU have sufficient fidelity. If such patches reduce QPU time, QESEM runs the input circuit on those patches in parallel. The results from the patches are combined using inverse variance weighting.

• Example: A user wants to run an 8-qubit circuit on ibm_marrakesh, a 156-qubit device, with parallel_execution=True. QESEM creates nine copies of the transpiled circuit, each mapped to a distinct 8-qubit patch on Marrakesh’s connectivity graph. After execution, the user receives a single expectation value and error bar for each input observable.

• Choices: "False" / "True"

Default value: None

Optional description to attach to the QESEM job.