Adds Hamiltonian Queueing and Transform to Compute Hamiltonian Expectation Value #1142

Lucaman99 · 2021-03-16T16:42:21Z

IMPORTANT NOTE

Currently, there is a small issue with this PR: when initializing a Hamiltonian using the arithmetic operations between Observables/Tensors/other Hamiltonians, the queue gets slightly confused, and Observables with no owners get added to the queue (for reasons I have yet to fully understand).

As a result, I have had to comment out an error to get things to work properly. Funnily enough, if we didn't have this error implemented, then everything would work fine (as Observables without owners that are added to the queue have no effect on the results of running the circuit). Suggestions as to how we can deal with this issue are much appreciated!

Context:

Description of the Change:

Small updates to allow qml.Hamiltonian instances to be queued in the quantum tape.
Adds a transform which allows mapping of a tape ending in the expectation value of a Hamiltonian to multiple tapes, which can be recombined to compute the expectation value after execution.

For instance, we can define the following tape:

with qml.tape.QuantumTape() as tape:
     qml.PauliX(wires=1)
     H = qml.Hamiltonian([1, 2, 1], [qml.PauliZ(0) @ qml.PauliZ(1), qml.PauliX(1), qml.PauliZ(2)])
     qml.expval(H)

Then, we can map it to multiple tapes, corresponding to different terms of the Hamiltonian

tapes, output_fn = qml.tape.transforms.hamiltonian_expval(tape)

Finally, we can execute each of the tapes and pass them through a post-processing function to return the expectation value:

dev = qml.device('default.qubit', wires=3)

results = dev.batch_execute(tapes)
expval = output_fn(results)

Benefits:

More intuitive to use than qml.ExpvalCost, which does something similar (but instead splits the QNode into a QNodeCollection, allowing for parallelization)

Possible Drawbacks:

None

Related GitHub Issues:

codecov · 2021-03-16T16:56:13Z

Codecov Report

Merging #1142 (1d9c551) into master (75fb0a4) will increase coverage by 0.09%.
The diff coverage is 92.50%.

@@            Coverage Diff             @@
##           master    #1142      +/-   ##
==========================================
+ Coverage   98.16%   98.25%   +0.09%     
==========================================
  Files         145      146       +1     
  Lines       11099    11129      +30     
==========================================
+ Hits        10895    10935      +40     
+ Misses        204      194      -10

Impacted Files	Coverage Δ
pennylane/operation.py	`95.82% <ø> (ø)`
pennylane/vqe/vqe.py	`92.19% <85.00%> (-0.78%)`	⬇️
pennylane/measure.py	`91.76% <100.00%> (ø)`
pennylane/transforms/__init__.py	`100.00% <100.00%> (ø)`
pennylane/transforms/hamiltonian_expand.py	`100.00% <100.00%> (ø)`
pennylane/transforms/measurement_grouping.py	`100.00% <100.00%> (+81.25%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 75fb0a4...1d9c551. Read the comment docs.

josh146 · 2021-03-16T17:11:47Z

Thanks @Lucaman99! Let me know when this is ready for review :)

into h_transform_new

Lucaman99 · 2021-03-23T15:56:42Z

Hey @ixfoduap @josh146, I think this PR is pretty much ready for review!

The only thing I haven't done yet is the tests for the actual queuing of the Hamiltonians, as this might change (since the queuing is currently causing some minor issues, as are described above).

Other than that, the functionality is done, and the tests/docstring for the hamiltonian_expval transform are done!

josh146

Hey @Lucaman99, this is great! I really like how you have set up written, and organized this PR.

A couple of comments and suggestions while going through it:

A big part of the work here was making sure that Hamiltonians queue correctly and are accepted by expval. However, I noticed that the hamiltonian_expval function itself shares a lot of logic with measurement_grouping. We should be able to take advantage of this, by simply calling it:

def hamiltonian_expval(tape):
    H = tape.measurements[0].obs

    if not isinstance(H, qml.Hamiltonian) or len(tape.measurements) > 1:
        raise ValueError(
            "Passed tape must end in `qml.expval(H)`, where H is of type `qml.Hamiltonian`"
        )

    H.simplify()
    return qml.transforms.measurement_grouping(tape, H.ops, H.coeffs)

I tested this out locally, and it works really well! I suggest making this change here.

Another important aspect we need to take into account is differentiability. That is, we should always have tests that check for the gradient, and not just the result, of a transform!

Currently, the hamiltonian_expval is not differentiable, since it uses standard NumPy. However, the measurement_grouping transform uses qml.math which does allow for differentiability. With the change in the point above, differentiating now works:

import pennylane as qml
from pennylane import numpy as np
from pennylane.interfaces.autograd import AutogradInterface

dev = qml.device("default.qubit", wires=3)

with qml.tape.JacobianTape() as tape:
    for i in range(2):
        qml.RX(np.array(0, requires_grad=True), wires=0)
        qml.RX(np.array(0, requires_grad=True), wires=1)
        qml.RX(np.array(0, requires_grad=True), wires=2)
        qml.CNOT(wires=[0, 1])
        qml.CNOT(wires=[1, 2])
        qml.CNOT(wires=[2, 0])

    H = -0.2 * qml.PauliX(1) + 0.5 * qml.PauliZ(1) @ qml.PauliY(2) + qml.PauliZ(0)
    qml.expval(H)

AutogradInterface.apply(tape)

def cost(x):
    tape.set_parameters(x)
    tapes, fn = qml.transforms.hamiltonian_expval(tape)
    res = [t.execute(dev) for t in tapes]
    return fn(res)

where

>>> x = np.array([0.1, 0.67, 0.3, 0.4, -0.5, 0.7], requires_grad=True)
>>> print(cost(x))
0.42294409781940345
>>> print(qml.grad(cost)(x))
[ 9.68883500e-02 -2.90832724e-01 -1.04448033e-01 -1.94289029e-09
  3.50307411e-01 -3.41123470e-01]

We should also verify it works for the other interfaces, e.g., TF:

import pennylane as qml
import tensorflow as tf
from pennylane.interfaces.tf import TFInterface

dev = qml.device("default.qubit", wires=3)

H = -0.2 * qml.PauliX(1) + 0.5 * qml.PauliZ(1) @ qml.PauliY(2) + qml.PauliZ(0)
x = tf.Variable([[0.1, 0.67, 0.3], [0.4, -0.5, 0.7]], dtype=tf.float64)

with tf.GradientTape() as gtape:
    with qml.tape.JacobianTape() as tape:
        for i in range(2):
            qml.RX(x[i, 0], wires=0)
            qml.RX(x[i, 1], wires=1)
            qml.RX(x[i, 2], wires=2)
            qml.CNOT(wires=[0, 1])
            qml.CNOT(wires=[1, 2])
            qml.CNOT(wires=[2, 0])
        qml.expval(H)

    TFInterface.apply(tape)
    tapes, fn = qml.transforms.hamiltonian_expval(tape)
    res = fn([t.execute(dev) for t in tapes])

which gives

>>> print(res)
tf.Tensor(0.42294409781940345, shape=(), dtype=float64)
>>> grad = gtape.gradient(res, x)
>>> print(grad)
[[ 9.68883500e-02 -2.90832724e-01 -1.04448033e-01]
 [-1.94289029e-09  3.50307411e-01 -3.41123470e-01]], shape=(2, 3), dtype=float64)

So once you are using measurement_grouping inside hamiltonian_expval, you should be able to write tests for the gradient :)

Finally, with respect to the queuing issue -- I have to admit, I wasn't able to track it down. My gut feeling is that one of the manipulations that occurs during arithmetic (e.g., so Observable.__mul__ or Tensor.__mul__ must not be queuing correctly? Do you think you might be able to track down the issue here?

One final, tangential thought for the future: currently, the Hamiltonian class always casts coeffs to a list, which breaks differentiability! We should try and make the Hamiltonian class differentiable, there isn't a reason why we couldn't have coefficients that are tensorflow variables :)