Pulse simulator tutorial from backend model (Armonk)

[DanPuzzuoli]

Update Feb 4:

I'm now happy with the current status of the tutorial, and am looking for comments!

Summary

A tutorial demonstrating the PulseSimulator use-case of constructing a model from a backend object, and running pulse Schedules on both the real backend and the simulator.

This is a work in progress, and, at the time of writing, is extremely rough. Comments welcome!

Details and comments

Steps in the tutorial:

• Calibration of a pi pulse using rabi oscillations on the Armonk device.
  • This is taken directly from the ignis calibration notebook... the notebook could be referenced instead of reproduced here, but it's nice to find the pi value on a real device, and then run a simulation based off of it, all in the same notebook.
• A PulseSystemModel for the Armonk backend is constructed directly from the armonk backend object.
  • This part is hacked together - the numbers in the backend object are not usable, so I have to hand-insert relevant parameters (e.g. the drive strength is computed from the amplitude of the calibrated pi pulse). Nevertheless, it demonstrates the construction ability.
• The same sequence of Rabi experiments is then run on the simulator, and the same oscillations are observed.

[lcapelluto]

Another very good and valuable notebook! :D Thank you Dan 🙇‍♀

Here are my comments:

• num_exps or num_experiments might be more clear than exps
• This line is too long: rabi_pulse = pulse_lib.gaussian(duration=drive_samples, amp=drive_amp, sigma=drive_sigma, name='rabi_pulse_%d' % ii)
• Cell 6 has to be updated to just job = armonk_backend.run(rabi_qobj) since users don't have access to your jobs.
• The section where you start hand modifying params (cell 10) could use more explanation. If I have a different backend, can I straight copy and paste that section to get mine to work, or what do I have to do differently?
• qubit_lo_freq could use a little more explanation -- why does it need to be set? Also, is it possible to populate it from the backend?
• I like that you reuse get_amplitude for the plotting. Much of the rest of cell 14 looks like cell 9 -- could even more of it be put into a function to reduce cell 14?

Just an idea, take it or leave it: would it be nice to plot the real backend data as well on the last plot?

[lcapelluto]

My main request is to explain the hand written parameters more thoroughly. I think my other comments are just questions, nitpicks, and suggestions

[nonhermitian]

Needs version table and copyright. Perhaps TOC as well

[DanPuzzuoli]

Just updated the tutorial, and generally hoping to wrap this one up as well. Please let me know if anything key/necessary needs to change. @nonhermitian @lcapelluto @dcmckayibm @ajavadia

Summary of changes:

• Added TOC, version table, and copyright @nonhermitian
• Simplified notebook to use relevant Ignis Rabi calibration functions @dcmckayibm

Changes/responses to @lcapelluto 's comments:

• num_exps or num_experiments might be more clear than exps

changed

• This line is too long: rabi_pulse = pulse_lib.gaussian(duration=drive_samples, amp=drive_amp, sigma=drive_sigma, name='rabi_pulse_%d' % ii)

This line no longer exists due to using ignis to generate schedules 😄

• Cell 6 has to be updated to just job = armonk_backend.run(rabi_qobj) since users don't have access to your jobs.

Changed - I had just kept this there originally to be able to rerun the whole notebook quickly while working on it.

• The section where you start hand modifying params (cell 10) could use more explanation. If I have a different backend, can I straight copy and paste that section to get mine to work, or what do I have to do differently?

I've explained this more. As for reproducibility in other backends - it won't work unless it is a single qubit, and even then it still depends on how the hamiltonian is parameterized. In the explanation I'm trying to make it clear that this is a 'hack' without calling it such.

• qubit_lo_freq could use a little more explanation -- why does it need to be set? Also, is it possible to populate it from the backend?

It can be automatically populated from the backend, and the functionality already exists. I've changed it to do this.

• I like that you reuse get_amplitude for the plotting. Much of the rest of cell 14 looks like cell 9 -- could even more of it be put into a function to reduce cell 14?

This no longer exists either due to ignis

Just an idea, take it or leave it: would it be nice to plot the real backend data as well on the last plot?

That would be nice though I think for now I will just leave it as is as it will require more 'non-standard' messing around with stuff.

[nonhermitian]

This looks good, but the warning on the parameter fitting is a bit of an issue I think:

/Users/dpuzzuoli/anaconda3/envs/QiskitDev/lib/python3.7/site-packages/scipy/optimize/minpack.py:795: OptimizeWarning: Covariance of the parameters could not be estimated
  category=OptimizeWarning)

Is there no way to get a fit that does not emit this warning?

[DanPuzzuoli]

@nonhermitian

I don't know how to eliminate this warning. I've just raised an issue about it in ignis: qiskit-community/qiskit-ignis#358