Store grouping in Hamiltonian

[mariaschuld]

Context:

With the new VQE workflow, we need a way for the user to define whether PennyLane and devices are supposed to use grouping. Grouping observables can take a long time and should therefore only be computed once. A way to meet both requirements is to allow users to store grouping information in the Hamiltonian, which - if found - is used by PennyLane:

obs = [qml.PauliX(0), qml.PauliX(1), qml.PauliZ(0)]
coeffs = np.array([1., 2., 3.])
H = qml.Hamiltonian(coeffs, obs, compute_groupings=True)

Initialization with compute_groupings=True stores the indices required to make groups of
commuting observables and their coefficients. These are used
(or, if not found, computed) by the get_groupings() method, which returns the
actual groupings.

>>> H.grouping_indices
[[0, 1], [2]]
grouped_coeffs, grouped_obs = H.get_groupings()
>>> grouped_coeffs
[np.array([1., 2.]), np.array(3.)]
>>> grouped_obs
[[qml.PauliX(0), qml.PauliX(1)], [qml.PauliZ(0)]]

PennyLane's qnode, which currently splits a tape with expval(H) into tapes with a single Pauli measurement each, looks for the grouping_indices attribute, and if found, uses groups of Pauli measurements per tape. Also devices that support Hamiltonians can use this strategy if desired.

Description of the Change:

Added grouping functionality to the Hamiltonian class, and uses it in hamiltonian_expand, which in turn is used by the QNode to split expval(H) into Pauli expectations.

Benefits:

One can now control the use of grouping behaviour in the observable.

Possible Drawbacks:

I am quite unsure about the design details. Feedback welcome!

[mariaschuld]

Locally, codecov has 100% coverage for all files I changed, except from one line that I never changed (and which is a NotImplementedError). Also the measurement_grouping file it mentions has 100% coverage. I really don't understand why it complains.

[glassnotes]

Looks good, mostly minor suggestions!

[mariaschuld]

Thanks @glassnotes I think I implemented all your suggestions and also checked the docs once more...

[co9olguy]

I wonder if having both of these args is redundant?

[josh146]

Good point. Are you thinking

qml.Hamiltonian(obs, coeffs, grouping=None)
qml.Hamiltonian(obs, coeffs, grouping="qwc")

etc.

[co9olguy]

yes

[mariaschuld]

I would find this a barrier for a user - they have to know something about the grouping to use it. My personal main use case would just be compute_grouping=True, I don't want to look up strings of strategies...

But if you all feel it's better I'll change it!

[josh146]

I admit I like it because:

• it is explicit
• it avoids the value of one argument affecting the behaviour of another (which I think is always confusing!)
• it matches other libraries, e.g., scipy.optimize.minimize()

[mariaschuld]

Cool, will change it then. method will still be influenced by grouping_type, but that's ok I hope...