Forward simulation on the GPU

[rileyjmurray]

PR #390 added preliminary support for PyTorch-backed forward simulation. There's pending follow-up work in PR #613. All of this work so far has been to explore PyTorch's automatic-differentiation features. In principle, this work could be extended to do forward simulation on the GPU. This GitHub issue outlines changes we'd need for such forward simulation to be useful.

TorchForwardSimulator is currently limited to ExplicitOpModels whose members are all in the "full TP" parameterization. In order to make PyTorch-enabled GPU computations truly useful we'd need to extend TorchForwardSimulator to ImplicitOpModels and, we'd need to update several ModelMember classes to implement the Torchable API.

Here are the classes that need to implement the Torchable API.

POVMs

• ComputationalBasisPOVM
• ComposedPOVM

States

• StaticState
• ComposedState

Gates

• Various "static" operation classes (of which there's not a particularly meaningful base class): StaticArbitraryOp, StaticCliffordOp, StaticStandardOp, and StaticUnitaryOp.
• ComposedOp
• EmbeddedOp

Error processes

• ExpErrorGenOp
• LindbladErrorGen
• possibly, LindbladCoefficientBlock

[rileyjmurray]

Here's a breakdown of the Torchable API TODOs according to difficulty. We won't see a big impact unless/until LindbladErrorGen implements the Torchable API.

Easy

Changes to ComputationalBasisPOVM and StaticState should be almost trivial. Since they have no parameters, their implementation of Torchable.stateless_data should just return a cached version of self.to_dense(), or something similar; their implementations of Torchable.torch_base should just return the array produced by stateless_data.

Changes to the static operation classes should be straightforward for the same reasons. What's more, while there are four of these classes, it should suffice to just extend StaticArbitraryOp for now.

Medium

Changes to ComposedPOVM and ComposedState should be very straight forward, since the composition is between two modelmembers, at least one of which is constant. These are testable using full TP operations as error channels to get started.

Extending EmbeddedOp and ExpErrorGenOp should be similarly straightforward.

Unknown (or hard)

I don't know how hard it'll be to extend ComposedOp to the Torchable API in full generality. It's somewhat unique, because a ComposedOp can contain multiple non-constant sub-operations. We can certainly extend to at least one static op and one non-constant op, which will cover pyGSTi's most important workflows.

I think it'll be difficult to extend LindbladErrorGen, and that much of the difficulty will stem from a need to dig into LindbladCoefficientBlock.