Qedma: QESEM qiskit function + OBP addon tutorial

[oria-qedma]

This is a draft of a Qesem QF tutorial showing simulation of 2d transverse field Ising model with Qesem error mitigation combined with qiskit operator backpropagation module.
Feedback from IBM team is welcome.

FYI @assafb

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 3 committers have signed the CLA.

✅ oria-qedma
✅ abbycross
❌ talishnaider-qedma
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[valeriechiang]

Thank you for the draft @oria-qedma! Is it possible to scale this up to 30+ qubits?

cc: @miamico @pandasa123

[oria-qedma]

Yes it is possible to run this using a larger number of qubits , we just have to play a bit with the parameters to keep the QPU runtime short enough on the one hand but still make sure the example shows some interesting behavior on the other hand.

[valeriechiang]

More feedback from the team: It would be interesting to include a result+depth comparison when using OBP+ QESEM versus just QESEM. Thoughts?

cc: @pandasa123 @jenglick

[abbycross]

Hi! I'm working on fixing the lint errors. I don't have write access to your branch, but I opened a PR on your fork, so if you can approve/merge it, that should bring those fixes into this PR. Thanks!

[miamico]

Cool, thanks for the draft! Here's some comments for you to work on:

• The focus here should be the QESEM circuit function. Let's emphasize it more in the title (right now the use case seems the focus rather than the tool)
• Add more background details on the use case and the technique in the Background section. It's ok to use a few paragraph to give users a rough idea of the techniques and what the tutorial is about. Linking to the reference is good then for people who want to go into more details
• In general, refer to published tutorials (like this recent function one) and follow the format wordings that we standardized across tutorials (details below)
• Use only 4 steps (qiskit pattern) for the H1 sections of the tutorial. Keep naming of these consistent with our format
• Remove this sentence under the title "Qiskit Functions are an experimental feature available only to IBM Quantum® Premium Plan, Flex Plan, and On-Prem (via IBM Quantum Platform API) Plan users. They are in preview release status and subject to change."
• Add usage estimate and type of processor used (like Heron r2)
• Change the requirement section to be like other published tutorials
• Remove commented pip install cell (these instructions would be in the text cell)
• It may be nice to use plotting utils to show the layering of the device and the choice of qubits
• We generally don't want to use statevector simulation techniques that are not scalable for 30+ qubits examples. Replace AerSimulator in calculate_ideal_evs with an MPS or other techniques that can scale better
• OBP will generally return a set of possibly non-commuting observables. could you expand in the text on how these are handled by the error mitigation protocol? are they mitigated "separately" or together? Anyways, adding more details on the technique (whatever is known from other public sources like the paper) would be beneficial for users that are a little more interested in the technical details

[talishnaider-qedma]

More feedback from the team: It would be interesting to include a result+depth comparison when using OBP+ QESEM versus just QESEM. Thoughts?

cc: @pandasa123 @jenglick

Hey @valeriechiang , Thanks fo the feedback! Yeah it could be a nice comparison. Currently the notebook takes around 20 minutes of QPU time (for all the trotter steps up to 9), I'm afraid it might be intimidating for users if it were to take double the time (approximately, haven't tried it yet) let's say 50 minutes.. What do you think?

[talishnaider-qedma]

Cool, thanks for the draft! Here's some comments for you to work on:

• The focus here should be the QESEM circuit function. Let's emphasize it more in the title (right now the use case seems the focus rather than the tool)
• Add more background details on the use case and the technique in the Background section. It's ok to use a few paragraph to give users a rough idea of the techniques and what the tutorial is about. Linking to the reference is good then for people who want to go into more details
• In general, refer to published tutorials (like this recent function one) and follow the format wordings that we standardized across tutorials (details below)
• Use only 4 steps (qiskit pattern) for the H1 sections of the tutorial. Keep naming of these consistent with our format

Here I guess you meant H2 sections (if i compare to the referenced tutorial)

• Remove this sentence under the title "Qiskit Functions are an experimental feature available only to IBM Quantum® Premium Plan, Flex Plan, and On-Prem (via IBM Quantum Platform API) Plan users. They are in preview release status and subject to change."
• Add usage estimate and type of processor used (like Heron r2)
• Change the requirement section to be like other published tutorials
• Remove commented pip install cell (these instructions would be in the text cell)
• It may be nice to use plotting utils to show the layering of the device and the choice of qubits
• We generally don't want to use statevector simulation techniques that are not scalable for 30+ qubits examples. Replace AerSimulator in calculate_ideal_evs with an MPS or other techniques that can scale better
• OBP will generally return a set of possibly non-commuting observables. could you expand in the text on how these are handled by the error mitigation protocol? are they mitigated "separately" or together? Anyways, adding more details on the technique (whatever is known from other public sources like the paper) would be beneficial for users that are a little more interested in the technical details

Hey, thanks for the detailed feedback. I merged the PR and updated the notebook according to a few of the comments (checked them above). I will commit the changes and continue with the other comments later this week.

[abbycross]

Authors: If there is an option along the right-hand side of this PR to "Allow edits from maintainers" - can you please enable it, if you don't mind? That way we can commit to your branch.

[valeriechiang]

More feedback from the team: It would be interesting to include a result+depth comparison when using OBP+ QESEM versus just QESEM. Thoughts?
cc: @pandasa123 @jenglick

Hey @valeriechiang , Thanks fo the feedback! Yeah it could be a nice comparison. Currently the notebook takes around 20 minutes of QPU time (for all the trotter steps up to 9), I'm afraid it might be intimidating for users if it were to take double the time (approximately, haven't tried it yet) let's say 50 minutes.. What do you think?

@talishnaider-qedma This is a good point. Maybe we can make the comparison to just QESEM optional (and add a disclaimer note that it will take ~50 minutes)? Then we can keep the overall tutorial time estimate as 20 minutes.

cc: @miamico @jenglick @pandasa123

[oria-qedma]

Authors: If there is an option along the right-hand side of this PR to "Allow edits from maintainers" - can you please enable it, if you don't mind? That way we can commit to your branch.

@abbycross I don't see such an option, maybe because I don't have admin rights to the fork? (I think maybe @assafb created the fork originally for other documentation work)

[abbycross]

Authors: If there is an option along the right-hand side of this PR to "Allow edits from maintainers" - can you please enable it, if you don't mind? That way we can commit to your branch.

@abbycross I don't see such an option, maybe because I don't have admin rights to the fork? (I think maybe @assafb created the fork originally for other documentation work)

Thanks for checking! - it's certainly possible that it's an admin-only option.