Plans for Symbolic expressions in QuantumOptics

[Krastanov]

For a project of mine I need to be able to jump between different simulation formalisms (e.g. master equations from QuantumOptics, or Monte Carlo Clifford sims from QuantumClifford, or others). I need a way to express the quantum objects independent of the low-level numerical simulation library.

For that reason, I started developing a humble Symbolics.jl-based library to express objects of interest in Quantum mechanics / optics / information science.

• Here is a barebones documentation: https://krastanov.github.io/QuantumSavory.jl/dev/symbolics/
• Here is the implementation of the base symbolics https://github.com/Krastanov/QuantumSavory.jl/tree/master/src/symbolics
• Here is the translation layer between the symbolics and different simulation formalisms https://github.com/Krastanov/QuantumSavory.jl/tree/master/src/backends

A big design goal was to re-use as much as possible from QuantumOpticsBase. The library is nowhere near ready for release, however I find it very important to not duplicate effort. Hence, finally, my question:

Could you share your plans, if any, to add symbolics to QuantumOpticsBase? Independently of whether you have any current plans, could you consider working together on setting up symbolic packages that do not clash with each other or unnecessary duplicate effort? Would you be interested in a couple of conference calls later in the year to discuss how the aforementioned library and QuantumClifford do not clash with QuantumOptics?

While this issue focuses specifically on symbolics, it is related to https://github.com/qojulia/QuantumOpticsBase.jl/issues/38

[david-pl]

Thanks for opening this issue and pointing to your package. It looks very useful already!

In fact, we are also currently thinking about symbolic algebra in QO, but things are still very much at a planning stage. The main motivation would be interoperability with QuantumCumulants and the ability to quickly create different numerical representations of the same model. That would also allow quickly switching between the cumulant expansion method and solving problems with QO (similar to what you are going for).

As QuantumCumulants already has a symbolic algebra built in our approach here would probably be to abstract it out into a new package and make both QO and QC depend on that package. I wrote a small draft script that shows how such an interface could look in principle. I just uploaded it as a gist if you're interested. Note that this is very much still a draft and not really usable as of yet. There are still a lot of issues to consider. The main ones I can think of right now are:

• The symbolic algebra in QuantumCumulants is built to efficiently apply commutation relations of operators. This is needed for the cumulant expansion method. Symbolic expressions are always stored in a form to make this as simple as possible. This may, however, be limiting when you're trying to represent arbitrary symbolic expressions. It might actually be better to create a more generic symbolic package that then converts to QC when needed.
• There are no symbolic states (Kets) in the algebra as they were not need so far. I saw that you already implemented symbolic states in your package, that's really cool!
• Tensor products are represented in a way in QuantumCumulants that's quite different from tensor products in QuantumOptics.

So the bottom line here is: I think working together would make a lot of sense in order to avoid duplicate effort. Did you already consider interoperability of QuantumSavory and QuantumCumulants as well?

Regarding calls: I'll reach out to you by email if that's okay.

[Krastanov]

Yes, feel free to reach out over email!

I would like to see QuantumCumulants as a backend for my simulator, but it has not been a priority. I have really enjoyed using QuantumCumulants for a few projects, but it is not the type of modeling that has been most important for my work. I did give a journal club on it at the quantum photonics group at MIT and people were really impressed with the package.

I have had to deal with the problem of different representations being more useful for different applications. My current approach has been to have a cache in the metadata field of the symbolic expression that caches the representations required by different backends. Maybe something like this could work for a potential future symbolic package to be used by all of these downstream packages.

There are two big points of divergence between our approaches that we should probably tackle first:

• I imagine we will need to figure out how to merge the QCumulants: QSym, QTerm, Q... and QSavory's Symbolic{<:Union{Ket,Operator,SuperOperator}}. For what is worth, the aforementioned Ket,Operator,Superator in QSavory come from QOpticsBase.
• I think your current approach is inheriting some of the work done on Lazy operators in QuantumOptics. My approach is a bit different, first completely converting the entire expression in a form used by quantum optics and then caching it. The "numerical" expression in that cache can actually be Lazy operators from QuantumOptics. I guess right now I am distinguishing symbolic expressions from Lazy numeric expressions. I would love to see both options being feasible, but I also suspect that different backends would need different Lazy operators (one lazy representation is faster when working with Clifford stabilizer states, but another lazy representation is faster for kets from QuantumOptics; actually, even withing QuantumOptics, I imagine different lazy representations would be preferred depending on whether you are doing Lindblad master equation or Monte Carlo trajectories)

[david-pl]

I imagine we will need to figure out how to merge the QCumulants: QSym, QTerm, Q... and QSavory's Symbolic{<:Union{Ket,Operator,SuperOperator}}.

I wonder: do we have to? Maybe the symbolic algebra in QC.jl is not well-suited to represent generic problems, e.g. for conversion to different forms and things like that. At the same time, it will be quite difficult IMO to implement a generic symbolic framework that is as efficient at applying commutation relations as QC.jl's is. However, if we have a generic symbolic framework then conversion to the QC.jl algebra should be fairly straighforward as long as we store the type/constructor of an operator. Since rewriting is hardwired into QC.jl's algebra it will just "naturally" occur when converting from the other symbolic representation. Do you think QSymbolics could be the generic symbolic framework used to do this?

And yes, my approach was only focused on lazy operators, but it was just a quick draft. Different ways of representing and converting expression would be needed for sure. For example, what if you want to materialize e.g. all multiplications, but keep the tensor products lazy?

Also, just FYI, I'd be careful with using metadata to store things you need as it tends to get lost during simplification with SymbolicUtils sometimes. Not entirely sure what the status there is though.

[Krastanov]

I wonder: do we have to?

You are right, we probably should not try to unify them, if the assumption is that QCummulants will be specifically focused on fast algebra for ladder operators and expectation values. This is similar to a choice made in SymPy about ten years ago.

Do you think QSymbolics could be the generic symbolic framework used to do this?

That is the goal. The main risks are fairly standard: for the moment it is only one or two people that are working on QSymbolics as a tool to enable some research projects -- the bus factor of the project is low. For that reason I have tried to reuse as much as possible from QuantumOpticsBase, so that other people feel like it matches their requirements.

For example, what if you want to materialize e.g. all multiplications, but keep the tensor products lazy?

The feature of QSymbolics that is most important for my work is the express facilty which permits me to convert symbolic expressions into different formats. E.g. express(symbolic_expression, QuantumOpticsRepr()) would convert the expression into some default representation. But we can then have:

express(op1⊗(op2*op3), QuantumOpticsRepr(tensor=:lazy)) == LazyTensor([express(op1),express(op2*op3)])

Basically, Lazy... becomes one of the many representations supported by QSymbolics?

If that seems reasonable to you, I can further flesh out the current QSymbolics in that direction and have something more official in a month or so.

At the same time, I will probably start pushing more for https://github.com/qojulia/QuantumOpticsBase.jl/issues/38 , as I would prefer for QSymbolics and QuantumSavory and QuantumClifford to depend less on a package as big as QuantumOpticsBase.jl.

Also, just FYI, I'd be careful with using metadata to store things you need

Oh, good to know! For the moment I will treat that as (1) something not too important as the metadata is there just for caching express results, not for "correctness" and (2) I will start tracking the corresponding SymbolicUtils bugs and report more.

[david-pl]

Alright then, so we know where to start: create a core package (QuantumOpticsCore? -- #38) that is a lightweight dependency only defining basic interfaces and types (we'll need to have a more detailed discussion on what should actually be included in that package). If we do things right, we should be able to have QuantumSavory, QuantumClifford, QuantumOptics and QuantumCumulants all work together without any clashes. Then we can see about flushing out QuantumSavory/QSymbolics more to support multiple representations/backends for QO types. The code snippet you shared there looks really promising, I think that's exactly what we'd want: having a very flexible way to quickly build different numerical forms from the same symbolic expressions.

[Krastanov]

With QuantumInterface and QuantumSymbolics, there is no need to have this separate issue open anymore. For tracking the some of the related further developments check out:

• https://github.com/QuantumSavory/QuantumSymbolics.jl/issues/73
• https://github.com/qojulia/QuantumCumulants.jl/issues/214