Skip to content

HEAT experiments #625

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 54 commits into
base: main
Choose a base branch
from

Conversation

nkanazawa1989
Copy link
Collaborator

@nkanazawa1989 nkanazawa1989 commented Jan 25, 2022

Summary

This PR adds HEAT experiment to the library. This experiment is introduced in the paper https://arxiv.org/abs/2007.02925 which is variant of Hamiltonian tomography with higher sensitivity to small terms. Basically this behaves as pinp-pong experiments.

This is replacement of old PR #460

Details and comments

This PR adds new experiment module qiskit_experiments.library.hamiltonian that is aiming at collecting experiments for low level device characterization. This differs from other characterizations aiming at gate or system metric. This grouping will help users to sort experiments. Of course import path is added to the library so user can still directly import the experiment from there. Note that it is planned to move CrossResonanceHamiltonian to this module in separate PR (and JAZZ is another candidate).

The HEAT experiment is designed as a batch experiment, since this is combination of two ping-pong experiment with different control qubit state. This implementation is more efficient than defining new analysis class that takes two ping-pong curves (i.e. There is no shared parameter between curves. Also we can add as many curves as batch as we want).

Since we can design many HEAT sequences for the different primary term of the generator Hamiltonian and the interrogated error axis, the base class is designed to allow such flexibility. In this PR, most standard ZX-HEAT series are added on top of the base class.

In the separate PR, I plan to add tutorial notebook for 2Q gate characterization with CrossResonanceHamiltonian and HEAT.

- Add hamiltonian tomography experiment module
- Add base HEAT framework and analysis to the module
- Add API documentation
Copy link
Contributor

@eggerdj eggerdj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Naoki, this is looking good. Most of my comments are related to docs which need a bit more work.

Copy link
Collaborator

@wshanks wshanks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put a few comments in and responded to some of Daniel's. I think this looks really good. I didn't comment much on the documentation because of the many outstanding comments from Daniel.

# that they have been altered from the originals.
"""
===============================================================================================
Hamiltonian Characterization Experiments (:mod:`qiskit_experiments.library.hamiltonian`)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a fairly broad title. Should the contents in cr_hamiltonian.py be moved under qiskit_experiments.library.hamiltonian as well? Also, I put a comment by the reno as well -- I feel like experiments are characterizing a particular schedule more than the underlying Hamiltonian. One could tweak the pulse shape or cancellation tone to adjust observed errors from the target ZX90 operation.

Copy link
Collaborator Author

@nkanazawa1989 nkanazawa1989 Jan 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably entangler and Entangler characterization? But this could kick out JAZZ experiment from here. I think having static ZZ in the module improves accessibility.

(edit)
Probably we may want to add sizzle too.

Comment on lines 48 to 52
The circuit in middle is repeated by ``N`` times to amplify the Hamiltonian
coefficients along interrogated axis on the target qubit. The ``prep`` circuit
is carefully chosen based on the generator of ``heat`` gate to investigate,
and the ``echo`` and ``meas`` circuit depend on the axis of error to amplify.
Only target qubit is measured following to the projection by ``meas`` circuit.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is also the case, though here the meaning was just that only the target qubit is actually measured.

nkanazawa1989 and others added 18 commits January 27, 2022 15:37
Copy link
Collaborator

@wshanks wshanks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! My only remaining quibble is that I see the HEAT experiment as very similar to cr_hamiltonian, so I find it odd they are in separate packages. Perhaps there could be a follow up to move cr_hamiltnonian and possibly give it a more generic name. I suppose it could be used for any gate with a ZX or ZZ Hamiltonian term (just like HEAT it just needs the first term to be Z for the 0 and 1 preparations on the control to make sense).

Copy link
Contributor

@eggerdj eggerdj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks mostly good to me. I nit picked the docstrings a bit. My biggest concern on the code front it the decorator in CompositeExperiment. It does not feel right to have a decorator with such a narrow scope.

@@ -131,3 +132,75 @@ def _postprocess_transpiled_circuits(self, circuits, **run_options):
for expr in self._experiments:
if not isinstance(expr, CompositeExperiment):
expr._postprocess_transpiled_circuits(circuits, **run_options)


def sync_transpile_options(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed in the first place? I wonder if this should be the default behavior of CompositeExperiment? Or why not have this as an extra function in the CompositeExperiment? I don't see why the decorator framework is needed when we only decorate a single method of a single class.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This aims at making a batch experiment to behave as if a single experiment (because user doesn't need to recognize its implementation to use). This SHOUD not be default behavior (unfortunately it is now) because we should be able to transpile batch (I believe also parallel) experiment with its own configuration.

Comment on lines +173 to +175
def sync_experiment_options(
composite_cls: Type[CompositeExperiment],
) -> Type[CompositeExperiment]:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above. Using decorators here only makes the code harder to follow.



class HeatAnalysis(CompositeAnalysis):
r"""A composite error amplification analysis to get unitary error coefficients.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not write an example model and make it clear that this has a broader use.

@CLAassistant
Copy link

CLAassistant commented Jul 18, 2023

CLA assistant check
All committers have signed the CLA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants