Instrument and operator-sum support

[cgranade]

Is your feature request related to a problem? Please describe.
It would be helpful to have a Qobj kind to represent operator-sum decompositions of channels (e.g.: Λ(ρ) = Σᵢ 𝐾ᵢρ𝐾ᵢ⁺) and instruments (e.g.: ρ ↦ Λᵢ(ρ) / Tr(Λᵢ(ρ)) with probability Tr(Λᵢ(ρ)), where {Λᵢ} are a set of completely positive trace non-increasing maps).

Describe the solution you'd like
See design draft at https://gist.github.com/cgranade/4a1d525c09745619716507cc3c2adee5.

Describe alternatives you've considered
See design draft at https://gist.github.com/cgranade/4a1d525c09745619716507cc3c2adee5.

[hodgestar]

@cgranade Thank you for the detailed write-up.

I have some questions below. I have my own ideas of answers to some of these questions, but I'd like to hear yours.

• What do you see as the primary drivers for this new feature?
• What is the advantage of this over using the existing superoperator representations?
• Can this advantage be carryied over into, e.g., using solvers, eigenvalue finding, etc?
• Would it be better to have a new object, sort of like QobjEvo but for sums rather than evolutions?
• How do you see the various mathematical operations working?

Given that currently dims describe the dimension of the Hilbert space and that the dimension isn't changing, I feel dims is perhaps an odd place to put the number of elements in the sum, but that doesn't prevent this becoming a feature of Qobj in some other way.

Either way, QobjEvo would need to support this too (probably not a giant amount of work, but some careful checking would be needed) & some other parts of the code might be surprised.

@jakelishman had some ideas for revamping dims support in QuTiP. I don't think it's the same idea, but the two definitely overlap in terms of which parts of QuTiP they'd evolve. Jake, would you mind posting the link to your dims proposal here if you have it handy (apologies, I seem to have lost it). Even if dims isn't the right place for this, it would be good for me to reread it.

[hodgestar]

I tagged this as QuTiP 5 (which is not to say it will be part of QuTiP 5, but just that if this does happen, QuTiP 5 is the place for it, not 4.7).

[Ericgig]

Here is the proposal from Jake: #1476.

[cgranade]

@cgranade Thank you for the detailed write-up.

No worries, thanks for giving it a readthrough!

I have some questions below. I have my own ideas of answers to some of these questions, but I'd like to hear yours.

• What do you see as the primary drivers for this new feature?

A bit of that is covered in the design draft, but I think to my mind there's two main things that this would enable:

• Operator-sum decompositions of superoperators (informally, "Kraus") as first-class Qobj values would make it a lot easier to work with channels in that representation. Currently, qt.to_kraus returns a list with no further metadata and no way to enforce that each operator in the list shares the same dimensions, such that an operator-sum decomposition of a superoperator looks like any other list of operators.
• Instruments are the most general form of measurement that can be considered in open quantum systems, but it would be difficult to implement a true instrument type or kind in QuTiP as it currently stands as the most common representation of an instrument is an operator-sum decomposition where each term is a channel in its own right. There's a slight difference with respect to decompositions of individual channels, in that these terms are indexed by the classical measurement result that one obtains in each case, but there's enough in common between both usecases to motivate finding a solution that works for both.

• What is the advantage of this over using the existing superoperator representations?

I don't think there is one, per se, in the same sense that there's no strict advantage to superoperators over Choi operators over χ operators — each is useful in different contexts, such that QuTiP supports all three in order to allow users to pick the right representation for their problem. Similarly, operator-sum decompositions of channels are quite common and are useful in some special circumstances (e.g.: expressing a Choi-rank–sparse channel without requiring a 4^n × 4^n matrix).

In the Quantum Development Kit, for instance, we use qutip.to_kraus to express user-supplied superoperators, Choi operators, and χ operators in terms of an operator-sum decomposition that is then passed to the underlying open systems simulator. While the operator-sum decomposition is quite useful internally to the simulator, that's not a detail that we want to enforce upon users, such that QuTiP's support for multiple superoperator representations is quite useful in presenting a user-friendly interface for configuring noise models.

• Can this advantage be carryied over into, e.g., using solvers, eigenvalue finding, etc?

I'm not sure I entirely follow, sorry?

• Would it be better to have a new object, sort of like QobjEvo but for sums rather than evolutions?

Perhaps, but at least for the operator-sum decomposition of channels, it would feel a bit weird to me to have superoperators, Choi operators and χ operators all have one Python type, but for Kraus representations to have a fully different Python type. Whether I represent Λ(ρ) by 0.9 𝟙ρ𝟙 + 0.1 𝑋ρ𝑋 or {√(0.9) 𝟙, √(0.1) 𝑋}, they both represent the same function from density operators to density operators.

• How do you see the various mathematical operations working?

My thought here would be that an operator-sum decomposition of a channel is just that: a representation of a channel. Thus, if lambda_ is a Qobj representing the operator-sum decomposition of Λ and phi is the representation of Φ, then lambda_ + phi should be some superoperator representation (most likely Kraus to match inputs) of the function (Λ + Φ)(ρ) = Λ﴾ρ) + Φ(ρ). Similarly, multiplying by a scalar 𝑠 would rescale each term by √𝑠 so that the corresponding function is (𝑠Λ)(ρ) = s · (Λ(ρ)) and multiplying two channels in Kraus decomposition would return their decomposition, (ΦΛ)(ρ) = (Φ ∘ Λ)(ρ) = Φ(Λ(ρ)).

Given that currently dims describe the dimension of the Hilbert space and that the dimension isn't changing, I feel dims is perhaps an odd place to put the number of elements in the sum, but that doesn't prevent this becoming a feature of Qobj in some other way.

Fair enough; I guess my thinking there was that the term index is indeed just another kind of index, but if there's a better way to represent that in the metadata for a Qobj than in dims, I'm all for it!

Either way, QobjEvo would need to support this too (probably not a giant amount of work, but some careful checking would be needed) & some other parts of the code might be surprised.

@jakelishman had some ideas for revamping dims support in QuTiP. I don't think it's the same idea, but the two definitely overlap in terms of which parts of QuTiP they'd evolve. Jake, would you mind posting the link to your dims proposal here if you have it handy (apologies, I seem to have lost it). Even if dims isn't the right place for this, it would be good for me to reread it.

Ah, nice, I hadn't realized! I'll take a look, then!

[hodgestar]

@cgranade Eric and I discussed this a bit today. Would you like to have a video call to chat through these ideas?

@jakelishman Would you like to join in if we can find a suitable time for you?

[cgranade]

@hodgestar @jakelishman I'd be happy to join a call, when works well on your end?

[jakelishman]

Yeah, I can join in if that'll help - I'll have to re-read my own proposal (I wrote it nearly a year ago, and I moved on a lot since then!), but that's ok. I don't know exactly what timezones we're going to have, but I'm in the UK - I guess to line up with the west coast of the US, that means we'll meet in my evening. I can't really meet on Thursday or Friday evenings, but I'm usually fine on the other days.

[hodgestar]

Call invitation sent. If any readers of this want to join, let me know.

[hodgestar]

Quick update for readers: We (@cgranade, @jakelishman, @Ericgig and I) agreed that the best next step is to implement a draft Instrument class that shows the function signatures and interactions with Qobj and a few examples and then to see where to go from there.

[cgranade]

@hodgestar @jakelishman @Ericgig Thanks for a fascinating discussion yesterday! I put together a (very) rough draft at #1687 to try and flesh out some of the ideas we discussed. Thank you again!