qiskit-aer: Aer pulse simulator doesn't produce correct results for Armonk device
Informations
- Qiskit Aer version: 0.6.1
- Python version: 3.7.4
- Operating system: MacOS
What is the current behavior?
I set up a simulation using backend configuration and defaults of the armonk
backend.
The pulse of the X gate didn’t produce a correct response: only ~60% in the |1> state vs. ~100% as expected.
Steps to reproduce the problem
Code snippet below (backend data was queried on 9/30/2020.)
import qiskit.pulse.library as library
from qiskit.providers.aer.pulse.system_models.hamiltonian_model import HamiltonianModel
from qiskit.providers.aer.pulse.system_models.pulse_system_model import PulseSystemModel
from qiskit.pulse import (Schedule, Play, ShiftPhase, SetPhase, Delay, Acquire, SamplePulse,
DriveChannel, ControlChannel, AcquireChannel, MemorySlot)
from qiskit.compiler import assemble
from qiskit.providers.aer.backends import PulseSimulator
import numpy as np
# Simulate Armonk backend with Qiskit AER
"""
Reference backend data: (9/30/2020)
'h_str': ['_SUM[i,0,0,wq{i}/2*(I{i}-Z{i})]',
'_SUM[i,0,0,delta{i}/2*O{i}*O{i}]',
'_SUM[i,0,0,-delta{i}/2*O{i}]',
'_SUM[i,0,0,omegad{i}*X{i}||D{i}]'],
'osc': {},
'qub': {'0': 3},
'vars': {'delta0': -2.1895185763064315,
'omegad0': 0.03620995108379614,
'wq0': 31.255356263726036}},
'rep_times': [1000.0],
'dt': 0.2222222222222222,
'dtm': 0.2222222222222222,
'qubit_freq_est': [4.974444447470232]
{'name': 'x',
'qubits': [0],
'sequence': [{'name': 'parametric_pulse',
't0': 0,
'ch': 'd0',
'pulse_shape': 'drag',
'parameters': {'amp': (0.657857142719338+0j),
'beta': -4.72912208204562,
'duration': 640,
'sigma': 160}}]}
"""
def system_model_1Q(delta0, omegad0, wq0, freq_est):
"""Constructs a standard model for a 1 qubit system (armonk).
Hamiltonian:
"_SUM[i,0,0,wq{i}/2*(I{i}-Z{i})]",
"_SUM[i,0,0,delta{i}/2*O{i}*O{i}]",
"_SUM[i,0,0,-delta{i}/2*O{i}]",
"_SUM[i,0,0,omegad{i}*X{i}||D{i}]"
Returns:
PulseSystemModel: model for qubit system
"""
hamiltonian = {}
hamiltonian['h_str'] = ['_SUM[i,0,0,wq{i}/2*(I{i}-Z{i})]',
'_SUM[i,0,0,delta{i}/2*O{i}*O{i}]',
'_SUM[i,0,0,-delta{i}/2*O{i}]',
'_SUM[i,0,0,omegad{i}*X{i}||D{i}]']
hamiltonian['vars'] = {'delta0': delta0, 'omegad0': omegad0, 'wq0': wq0}
hamiltonian['qub'] = {'0': 3}
ham_model = HamiltonianModel.from_dict(hamiltonian)
u_channel_lo = []
subsystem_list = [0]
dt = 0.2222222222222222
return PulseSystemModel(hamiltonian=ham_model,
u_channel_lo=u_channel_lo,
qubit_freq_est=[freq_est],
subsystem_list=subsystem_list,
dt=dt)
def x_gate_by_pulse_sched():
# Drag pulse represents X gate
#{'amp': (0.657857142719338+0j), 'beta': -4.72912208204562, 'duration': 640, 'sigma': 160}}]}
amp = 0.657857142719338
sigma = 160
beta = -4.72912208204562
duration = 640
drag_pulse = library.drag(duration, amp, sigma, beta=beta)
drive_pulse = SamplePulse(drag_pulse.samples)
schedule = Schedule()
schedule |= Play(drive_pulse, DriveChannel(0))
schedule |= Acquire(duration, AcquireChannel(0), MemorySlot(0)) << schedule.duration
return schedule
"""
Params:
'delta0': -2.1895185763064315,
'omegad0': 0.03620995108379614,
'wq0': 31.255356263726036
'qubit_freq_est': [4.974444447470232]
"""
delta0 = -2.1895185763064315
omegad0 = 0.03620995108379614
wq0 = 31.255356263726036
freq_est = 4.974444447470232
system_model = system_model_1Q(delta0, omegad0, wq0, freq_est)
schedule = x_gate_by_pulse_sched()
backend_sim = PulseSimulator()
# set up schedule and qobj
qobj = assemble([schedule],
backend=backend_sim,
meas_level=2,
meas_return='single',
meas_map=[[0]],
memory_slots=1,
shots=1024)
# set backend backend_options including initial state
y0 = np.array([1.0, 0.0, 0.0])
backend_options = {'seed' : 9000, 'initial_state' : y0}
# run simulation
result = backend_sim.run(qobj, system_model=system_model, backend_options=backend_options).result()
# Print results
print(result.to_dict())
What is the expected behavior?
Could you please take a look to see whether the set-up was not as expected or it is a bug in the simulator?
Suggested solutions
Nil
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 15 (15 by maintainers)
Yes we are aware of the issue and a fix has been prepared. Hopefully should be merged in soon
For a short term solution you could modify
omegad0
so that the given X-gate produces a proper pi pulse, though obviously that could have unintended consequences for other gates. (In any case, to do this, we needA * omegad0 / 2
to equalnp.pi / 2
, so settingomegad0 = np.pi / A
will make the X gate work. Running this myself results in state 0 going to state 1 with >99.9%.)For a proper solution we’ll need some information about backend reporting. @zachschoenfeld33