Hilbert space supermode factors and canonical transformations

[danielwe]

We have been discussing native support for various aspects of non-local supermodes. This could involve both infrastructure to explicitly define Bogoliubov transformations from a list of LocalSpaces, and more generally an extension to the Hilbert space algebra to support some notion of Hilbert space factors which are nonlocal with respect to the original LocalSpace factors, but nonetheless mutually disjoint and understood to represent a single degree of freedom (in the same sense that LocalSpace represents a single degree of freedom).

This functionality would be very helpful when passing between alternative representations to the canonical factorization of Hilbert space defined by a list of LocalSpaces. Currently, the most straightforward approach is to represent supermode operators by OperatorSymbols on the full Hilbert space, but this means that the algebra is ignorant of the canonical commutation relations for supermode creation and annihilation operators, and of the fact that operators on orthogonal supermodes commute. This places a huge burden on the user to apply a large number of carefully designed patterns in order to simplify expressions.

At the moment we restrict this proposal to bosonic LocalSpace modes. Bogoliubov transformations are also defined for fermionic modes, which in QNET can be represented by two-level LocalSpaces, but there are unresolved subtleties regarding QNET and finite-level systems that should be clarified before attempting to generalize (see #90). It is further unclear if it is possible to generalize the notion of Bogoliubov transformations to a product of N-level systems where N is neither 2 nor infinity.

Representing the Bogoliubov transformation, we envision a class BogoliubovTransformation parametrized by a list of bosonic LocalSpaces and two matrices U and V such that U * U.adjoint() - V * V.adjoint() = I and U * V.T is symmetric. There are two ways to go from here:

• Not touching the Hilbert space algebra. In this case, everything we want to do with supermodes would involve classes parametrized by a BogoliubovTransformation and supermode indices. For example, we can obtain the creation operator for Bogoliubov mode 3 by calling BogoliubovCreate(3, btransform), where btransform = BogoliubovTransformation(local_spaces, U, V). We can instantiate an operator symbol acting on the subspace defined by Bogoliubov mode 2 and 5 by calling O = BogoliubovOperatorSymbol('O', [2, 5], btransform). There are no objects to explicitly represent the Hilbert space factors of the supermodes, but operators defined on disjoint subspaces know to commute, with full awareness of zeros in U and V that could make some supermode factors disjoint from some LocalSpace factors.

• Implementing a class BogoliubovSpace, parametrized by a list of bosonic LocalSpaces and two vectors u, v, where u * u.adjoint() - v * v.adjoint() = 1. These would work as similarly to bosonic LocalSpaces as possible, representing an infinite ladder of basis states and supporting algebraically aware creation, annihilation and Sigma operators, and be valid targets for OperatorSymbols. The crucial difference would be that they are not in general disjoint from other single-mode Hilbert space factors. They are aware of the LocalSpaces they overlap with, and two BogoliubovSpace instances bspace1, bspace2 parametrized by the same LocalSpaces know that they are disjoint if and only if u1 * u2.adjoint() - v1 * v2.adjoint() = 0 and u1 * v2.T = u2 * v1.T. Based on this, operators associated with disjoint spaces know to commute. The main role of a BogoliubovTransformation is then to produce a list of mutually disjoint BogoliubovSpaces built from the rows of U and V.

In either case, commutation relations between local and supermode creation and annihilation operators are known (i.e., when b_j = u_jk * a_k + v_jk * a_k.dag(), we have [b_j, a_k] = -v_jk and [b_j, a_k.dag()] = u_jk, etc.), so expressions with mixed local and supermode operators simplify as appropriate. This could be useful, e.g., for obtaining the Heisenberg equation of motion for a local mode from a Hamiltonian expressed in terms of supermodes.

[goerz]

So if we define BogoliubovSpace, we don't need a BogoliubovOperatorSymbol?

[danielwe]

If possible, I think BogoliubovSpace should work like any other Hilbert space in this regard, and be a valid space to parametrize an OperatorSymbol with. I can see that it might be tricky to make all the disjointness-aware algebra to work in that case, though.

From a user perspective, I feel like it would be preferable for Create and Destroy and all the other LocalOperators to work on BogoliubovSpaces too, and not have separate Bogoliubov{Create,Destroy}. I can see how this would be problematic, however, bevause a supermode operator is certainly not local. However, it seems like the main distinguishing feature of the LocalOperator class is that it has known algebraic relations, and that is certainly true for supermode operators too. Perhaps the solution is to rename LocalOperator to KnownOperator (or something much better, obviously).

Speaking of names, BogoliubovSpace doesn't flow very easily through the fingers. Perhaps SupermodeSpace or SuperSpace or DistributedSpace would be better, without changing any of its properties or parametrization (i.e., it would still require the rows of valid Bogoliubov transformation matrices for instantiation, and a BogoliubovTransformation would produce a list of DistributedSpaces).

[goerz]

If possible, I think BogoliubovSpace should work like any other Hilbert space in this regard, and be a valid space to parametrize an OperatorSymbol with. I can see that it might be tricky to make all the disjointness-aware algebra to work in that case, though.

Yes, I agree. Which means we should go with option 2 of the proposal (implementing BogoliubovSpace).

From a user perspective, I feel like it would be preferable for Create and Destroy to work on BogoliubovSpaces too, and not have separate Bogoliubov{Create,Destroy}.

In principle, I agree. But this (and the re-interpretation of LocalOperator, see below) might be something we should consider for version 3.0, while for the 2.0 release, I would maybe start out with BogoliubovCreate{Create,Destroy}.

I can see how this would be problematic, however, because Create,Destroy derive from LocalOperator, and a supermode operator is certainly not local. However, it seems like the main distinguishing feature of the LocalOperator class is that it has known algebraic relations, and that is certainly true for supermode operators too. Perhaps the solution is to rename LocalOperator to KnownOperator (or something much better, obviously).

The distinguishing feature is that there's a single degree of freedom (a single quantum number). However, that degree of freedom could be obtained from a transformation of the "canonical" degrees of freedom defined by the LocalSpaces.

We could rename LocalOperator to BosonicOperator, which would serve as the superclass for Create, Destroy, Displace, Phase, and Squeeze - all the operators that are defined explicitly in terms of â and â⁺ and that are in qnet.algebra.library.fock_operators (which we might want to rename to qnet.algebra.library.bosonic_operators. If we do this, LocalSigma as well as SpinOperator should directly subclass from Operator.

There would be some code duplication as a consequence of this (LocalSigma and SpinOperator duplicating some of the current functionality of `LocalOperator). So maybe the following would the most complete option:

• rename LocalOperator to something that captures the true intent, e.g. SingleDegreeOfFreedomOperator, or my current favorite SimpleOperator.
• Define BosonicOperator as above, inheriting from SimpleOperator, that is, between SimpleOperator and Create etc.
• Subclass LocalSigma and SpinOperator from SimpleOperator.

In any case BosonicOperator would be defined either on a LocalSpace, or on a BogoliubovSpace. I think this makes sense especially because we're focusing entirely on bosonic Bogoliubov transforms for the time being. I'm actually not sure whether we'll be able to use the same BogoliubovTransformation and BogoliubovSpace for the fermionic case as well (because the U and V are implicitly only valid for either bosonic or fermionic modes). We'll either need different classes, or a mode={'bosonic', 'fermionic'} parameter in the class constructor, that affects the check on U and V, and for which operators the BogoliubovSpace is allowed to be used.

Speaking of names, BogoliubovSpace doesn't flow very easily through the fingers. Perhaps SupermodeSpace or SuperSpace or DistributedSpace would be better, without changing any of its properties or parametrization (i.e., it would require the rows of Bogoliubov transformation matrices for instantiation, and a BogoliubovTransformation would produce a list of DistributedSpaces).

I sympathize, but maybe it's just because it's an unusual name, and once you type it a couple dozen of times, it will get easier. I would have a slight preference to sticking with BogoliubovSpace. That way, we attach ourselves to an existing mathematical concept (especially since we use U and V in the proper mathematical way, so we're not even stretching the concept)

Otherwise, maybe RotatedSpace (is "rotation" a good intuitive picture for what a BogoliubovTransform does?) or MixedSpace.

[danielwe]

Otherwise, maybe RotatedSpace (is "rotation" a good intuitive picture for what a BogoliubovTransform does?) or MixedSpace.

I think it depends on your perspective. Clearly, a Bogoliubov transformation can be thought of as dual to a unitary transformation of Hilbert Space, which evokes "rotation". But in the phase space perspective that we usually take on bosonic modes, it's a symplectic transformation, which as far as I understand basically means a combination of rotation (understood as a unitary mapping between modes, such as local modes to Fourier modes) and multimode squeezing. That's not to say I endorse the name SymplecticSpace, however; mathematically I think that's a name you would use for the multidimensional phase space itself.

In general I think we have consensus on both the end goal and the steps to take:

1. Implement BogoliubovSpace and BogoliubovTransformation and a family of bosonic Bogoliubov{Operator} classes mirroring what's currently in fock_operators.
2. (In the longer term) Merge the members of fock_operators and the BogoliubovOperators into a single family of bosonic operators. This redesign would probably go hand in hand with implementing whatever the conclusion of #90 turns out to be.
3. Assuming #90 has been worked out, consider generalizing to fermionic Bogoliubov transformations (I don't think this would require any new classes or parameters; the bosonic vs. fermionic case can be inferred from the parametrizing LocalSpaces).

What I'm really excited about is the eventually possibility to choose between different factorizations of Hilbert space when writing out numerical operators. QNET will do all the symbolic manipulations assuming true bosonic operators in any representation, possibly passing back and forth between several of them associated with different BogoliubovTransformations, and when it's time to write out matrices we can choose either representation and set truncated dimensions for the corresponding simple Hilbert space factors.

[danielwe]

Just realized that we can generalize a little bit further: in addition to Bogoliubov transformations, translations a -> a + \alpha preserve canonical commutation relations for bosons (but obviously not anticommutation relations for fermions). Perhaps a better idea, both for generality and naming, is CanonicalTransformation(local_spaces, displacement, U, V), and CanonicalSpace(local_spaces, displacement, u, v)? (Where displacement is a vector in the first case and scalar in the second.)

[goerz]

I have no objections to the generalization. CanonicalTransformation would work for me, but I'm concerned about CanonicalSpace, because that sounds like it refers to the canonical space (aka the LocalSpace, the thing the canonical transformation acts on, not the result of the transformation). So that should be BogoliubovSpace/TransformedSpace/MixedSpace, or something along those lines. Is there a mathematical name for Bogoliubov plus displacement? Sounds vaguely "affine".

[danielwe]

I agree that CanonicalSpace is questionable. I honestly don't know what the best name would be. BogoliubovSpace isn't too good because a canonical transformation may well be a pure translation.

I think the relevant hierarchy of transformation names would be: Affine linear transformations > Canonical transformations > Bogoliubov transformations

The first restriction is requiring that the transformation preserves canonical commutation relations, and the second is homogeneity.

[goerz]

Assuming we fully deal with #90 (properly separate out Bosonic/Fermionic/N-level operators), would our CanonicalTransformation also cover simple unitary transformations of the basis? Like, going from the computational basis to the Bell basis of qubits encoded in an N-level system?

[danielwe]

The name "canonical transformation" refers to transformations that preserve canonical (anti)commutation relations for either bosons or fermions, and doesn't cover other kinds of systems. However, using a similar infrastructure to support some types of unitary transformations on them sounds very useful too.

One of the merits of canonical transformations is that they preserve the structure of the factorization of Hilbert space, i.e., you pass from a tensor product of N bosons to a tensor product of N different bosons, but in both cases, they multiply to the same Hilbert space. Passing from the computational basis to the Bell basis for a multiqubit system is similar, right? You go from a tensor product of N two-level systems to a tensor product of N different two-level systems? There might even be an exact correspondence between this an a very simple case of a fermionic Bogoliubov transformation.

[goerz]

Yeah, I think so. But anyway, just something to keep in mind...