Random permutation of strings in Trotterisation

[vaferreiQMT]

Implements

• random permutations of Pauli strings in a PauliStrSum
• option to use random permutations during Trotterisation

See also #596

[otbrown]

Hi Vasco,

Thanks for this -- just wanted to confirm that I've seen it and will try to review once I'm back from SC (which is next week!).

Cheers,
Oliver

[TysonRayJones]

Hi Vasco and Oliver,

Here are some thoughts before merging:

• Making a new randomiseString parameter constitutes an API break - but I personally think that's fine and doesn't warrant a new major version.
• The new randomiseString parameter needs to be added to the docstrings.
• Is randomiseString the most illustrative name? I worry the String suffix doesn't clarify much - the code is shuffling the order of the prescribed Pauli rotations within each Trotter repetition - so I would personally advocate for simplifying it to randomise.
• The current implementation mutates the passed PauliStrSum, so a user printing their PauliStrSum will see it changed pre- and post-call of any of the Trotter functions. If that's a desired/acceptable postcondition, we need to doc that. If that's undesirable, it'd be straightforward to additionally maintain a list of the original indices with respect to the current mutation and restore the original order before function return. That requires O(#terms) temporary memory which may be justifiable (e.g. the Lindblad functions use greater temp mem).

[otbrown]

Hi both,

• On the API break, I agree, I think this is sufficiently new functionality in QuEST that we can justify being a bit loose with the semantic versioning.
• Rather than randomise or randomiseString I would propose something more verbose, like randomisePauliOrder, though this is not a hill I care to die on :)
• To Tyson's point about printing the sum, I'm a bit torn -- I can see the sense in not changing something the user has defined themselves, but I also don't like the idea of not giving them the opportunity to inspect what QuEST really ran. As such my vote is for documenting that this function mutates the PauliStrSum, and leaving it mutated so the user can inspect what happened.
• Only additional comment is that there should be at least some basic testing, as discussed on the call the other day Vasco!

[vaferreiQMT]

Thank you both for the feedback. I should have some time to implement your suggestions and update the PR next week or so.

Cheers

[vaferreiQMT]

Howdy, I've finally had some time to update the PR.

A couple notes:

• I've added a few lines on the Trotter docs about randomisation, including a warning about sum being mutated
• I updated the name to permutePaulis which I think should hopefully be more self-explanatory whilst also ensuring there isn't any confusion between "order" (as in the degree of the Trotter expansion) and the "order" (as in permutation of Pauli strings).
• I've added a very rough test, which hopefully can be integrated more neatly once the other Trotterisation tests are implemented. For now it serves as a quick sanity-check that randomisation is in fact improving the Trotterisation when used in the regime which we expect it to behave well.

Happy to also make any additional tweaks or alterations if anything jumps out at you.

Also a heads up, I am working on improved grouping and ordering of Trotter terms, though I still have to tidy that up a bit and will open a draft PR once it is more complete.

[otbrown]

Hi @vaferreiQMT,

This looks good to me! I see there were some test failures which look like issues with the runner not the code. After trying and failing to find a way to rerun those checks I checked it manually using the ARCHER2 AMD GPU testbed. As a bonus I can confirm that tests pass there too!

I'll look at merging #706 next, which will add some tests for the underlying evolution functions.