This PR contains several modifications to DynamicsBackend that fix small issues discovered while preparing a tutorial for the class.
Details and comments
The changes:
The default absolute tolerance on _get_dressed_state_decomposition has been reduced to 1e-5, to be consistent with the Hermiticity checking in the quantum_info module. The previous absolute tolerance of 1e-8 was erroneously raising errors when dealing with Hamiltonians specified in Hz/s containing parameters in the GHz range.
No tests have been added for this as it's just a tolerance change.
The way the default measurement instructions are built in the DynamicsBackend constructor has been changed to be more in line with my understanding of what the "right" way of adding instructions is: calling target.add_instruction. (Previously, the instructions were being added directly to the instruction_schedule_map, which wasn't properly populating all fields in the target).
No specific tests have been added for this, but all DynamicsBackend tests invariably indirectly test this.
Experiment metadata is now being extracted and added to the ExperimentResult objects. qiskit-experiments uses metadata, and without this, analysis tasks were failing.
A new test has been added for this to check output metadata when submitting multiple circuits.
qiskit-experiments expects jobs to have time_per_step method that returns time stamps, which DynamicsJob was not constructing. I've added some timestamp storing internally to DynamicsJob that can be retrieved by the time_per_step.
A test has been added confirm this and its behaviour.
Lastly, I found a bug in which, if a schedule being simulated has no instructions before measurement, the returned statevector would contain nan if using JAX and jax_odeint. This was due to jax_odeint being called with t_span=[0., 0.], and this is another case in which odeint being called with non-unique time values, some of the returned states will be nan. I've updated trim_t_results_jax to detect when this is occurring and correct the returned state, which resolved the bug. (This came up as one of the experiments from qiskit-experiments appears to measure SPAM error by submitting a schedule with nothing occurring before measurement.)
I've added tests for both trim_t_results_jax and jax_odeint that would have detected this problem.
This PR also adds a test that the RoughFrequencyCal experiment from qiskit-experiments can be run using DynamicsBackend, and returns a sensible result. This is contained in the new test file test.dynamics.backend.test_qiskit_experiments, and qiskit-experiments has been added to requirements-dev.txt.
Summary
This PR contains several modifications to
DynamicsBackendthat fix small issues discovered while preparing a tutorial for the class.Details and comments
The changes:
_get_dressed_state_decompositionhas been reduced to1e-5, to be consistent with the Hermiticity checking in thequantum_infomodule. The previous absolute tolerance of1e-8was erroneously raising errors when dealing with Hamiltonians specified in Hz/s containing parameters in the GHz range.DynamicsBackendconstructor has been changed to be more in line with my understanding of what the "right" way of adding instructions is: callingtarget.add_instruction. (Previously, the instructions were being added directly to theinstruction_schedule_map, which wasn't properly populating all fields in thetarget).DynamicsBackendtests invariably indirectly test this.ExperimentResultobjects.qiskit-experimentsuses metadata, and without this, analysis tasks were failing.qiskit-experimentsexpects jobs to havetime_per_stepmethod that returns time stamps, whichDynamicsJobwas not constructing. I've added some timestamp storing internally toDynamicsJobthat can be retrieved by thetime_per_step.nanif using JAX andjax_odeint. This was due tojax_odeintbeing called witht_span=[0., 0.], and this is another case in whichodeintbeing called with non-unique time values, some of the returned states will benan. I've updatedtrim_t_results_jaxto detect when this is occurring and correct the returned state, which resolved the bug. (This came up as one of the experiments fromqiskit-experimentsappears to measure SPAM error by submitting a schedule with nothing occurring before measurement.)trim_t_results_jaxandjax_odeintthat would have detected this problem.RoughFrequencyCalexperiment fromqiskit-experimentscan be run usingDynamicsBackend, and returns a sensible result. This is contained in the new test filetest.dynamics.backend.test_qiskit_experiments, andqiskit-experimentshas been added torequirements-dev.txt.