Open donsano33 opened 9 months ago
The problem originates from the line 269 in rotating_wave_approximation.py
:
carrier_freqs[i] = sig.carrier_freq
which throws as it expects a float
assignment but actually receives a complex
. All carrier frequency values corresponding the control channels U*
are of type complex
while the ones for the drive channels D*
are float
.
The values for sig.carrier_freq
are extracted from the backend_config
in DynamicsBackend.from_backend
in line 677 of dynamics_backend.py
by calling _get_backend_channel_freqs(...)
.
For control channels the values are calculated in line 1059
.
freq += drive_frequencies[channel_lo.q] * channel_lo.scale
where channel_lo.scale
is of type complex
and therefore causes the issue.
As the datatype of UchannelLO.scale
is fixed at complex
(https://docs.quantum.ibm.com/api/qiskit/qiskit.providers.models.UchannelLO) I would just use the real part of the scale
factor .
for channel_lo in u_channel_lo[idx]:
freq += drive_frequencies[channel_lo.q] * channel_lo.scale.real
I do not really understand why this is a complex number, maybe you have some insight in this?
Informations
0.4.2
3.11.7
Ubuntu 22.04.3 LTS
What is the current behavior?
The call to
DynamicsBackend.from_backend
throws aValueError
if given the parameterrwa_cutoff_freq=5e9
. The docstring states, that afloat
parameter can be given.Error Message:
Steps to reproduce the problem
What is the expected behavior?
No exception is thrown and the
rwa_cutoff_freq
is used by theSolver
instance.Suggested solutions
None, I have not checked the cause of the error.