Skip to content
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

Circuit Cutting: extend fragment_tape to work for Hamiltonians with more than one term #3672

Closed
gideonuchehara opened this issue Jan 24, 2023 · 6 comments · Fixed by #4642
Closed
Labels
enhancement ✨ New feature or request

Comments

@gideonuchehara
Copy link

Feature details

qml.transforms.qcut.fragment_graph() does not work for quantum tapes which compute the expectation values of Hamiltonians with more than one term. When applied to a tape with such Hamiltonians, it returns the unfragmented, original circuit without warning or error message.

Implementation

Fragment the quantum tape as usual based on the cut locations, then sort and split the Hamiltonian terms among the different fragments.

How important would you say this feature is?

3: Very important! Blocking work.

Additional information

No response

@gideonuchehara gideonuchehara added the enhancement ✨ New feature or request label Jan 24, 2023
@AlbertMitjans
Copy link
Contributor

Hi @gideonuchehara,

We are aware of this issue. It's on the roadmap to fix, but we can't make any promises about fixing it asap.

If you are keen to try out a fix, we'd be happy to set up a call to discuss how!

@gideonuchehara
Copy link
Author

gideonuchehara commented Feb 2, 2023

Sure @AlbertMitjans. I'd be happy to chat with you.

In the mean time, I though to also bring the following to your attention:

I also observed that this error cascaded into the qml.cut_circuit function and it is so subtle that because there is no warning or error message, the user assumes that the circuit with Hamiltonian was actually cut when in essence it was not. The qml.cut_circuit function bypasses the cut process and executes the circuit as a normal circuit without a cut, and except you print out the output of the cut, you may never notice that no cut was actually done. As an example, if you run this circuit with qml.cut_circuit, and print the cut output,

0: ──X───RZ──RY──RZ─────╭X────┤ ╭<𝓗>
1: ──X───RZ──RY──RZ─────│──╭X─┤ ├<𝓗>
2: ──RZ──RY──RZ─╭●───//─╰●─│──┤ ├<𝓗>
3: ──RZ──RY──RZ─╰X─────────╰●─┤ ╰<𝓗>

you will get the circuit below after cut:

0: ──X───RZ──RY──RZ─╭X────┤ ╭<𝓗>
1: ──X───RZ──RY──RZ─│──╭X─┤ ├<𝓗>
2: ──RZ──RY──RZ─╭●──╰●─│──┤ ├<𝓗>
3: ──RZ──RY──RZ─╰X─────╰●─┤ ╰<𝓗>

Clearly, no cut was done. Instead, WireCut was removed from the circuit, reverting it back to an uncut circuit.

To solve this problem, I implemented a hamiltonian version of qml.cut_circuit that can be used as a decorator as shown below:

def splitted_hamiltonian(tape):
    ham_tapes, ham_fn = qml.transforms.hamiltonian_expand(tape, group=False)
    ricco_tapes, ricco_fn = qml.transforms.map_batch_transform(ricco, ham_tapes)
    return ricco_tapes, ricco_fn, ham_fn
@qml.batch_transform
def ricco_hamiltonian(tape):
    
    ricco_tapes, ricco_fn, ham_fn = splitted_hamiltonian(tape)
    
    def processing_fn(res):
        result = ham_fn(ricco_fn(res))
        return qml.math.array(result)
    
    return ricco_tapes, processing_fn

I made just a minor change to the original qml.cut_circuit and I would be happy to discuss this further.

@AlbertMitjans
Copy link
Contributor

Hi @gideonuchehara !

I updated the format of the code in your comment because it was hard to read. You can click the Edit button to check the correct way of writing code blocks. Please try to use code blocks in the future 😄

Thank you for the warning and your implementation!

We will add an error message soon. Let me get back to you when I find out who coded the qcut module.

@gideonuchehara
Copy link
Author

Hi @AlbertMitjans ,

That's right. Thanks for helping out!

@AlbertMitjans
Copy link
Contributor

Hi @gideonuchehara,

@trbromley will get in touch with you!

@obliviateandsurrender
Copy link
Contributor

Thanks @gideonuchehara! This should now be possible with #4642. You may open a new issue for additional requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement ✨ New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants