Hi,
if you guys are generally open to the idea, I would very much like to
integrate/refactor most of the symbolic code from my own quantum optical
circuit package QNET [1] into SymPy over the next few months.
Specifically, this would probably lead to some completely new modules to
handle quantum optical circuits (these are very different from the circuit
representation used in quantum information algorithms, for more information
see this paper [2] or the documentation [1] or my brief intro below) as
well as contributions to sympy.physics.quantum and
sympy.physics.secondquant.py
I guess, to get started, it would be very helpful for me to know who I
could ask questions about the existing code (Brian and Aaron, you might
still remember me from this year's SciPy) and what the general policy is on
extending existing classes, and perhaps even modifying some of the design
decisions/philosophy.
First off, I know that a lot of people have put _tons_ of work into this
and that the design decisions that were made so far were made for good
reasons. I certainly don't wish to step on people's toes, but rather try to
find a way in which I can contribute useful code to what I believe is an
awesome project.
So, to start off, let me very briefly describe what sort of systems we
study and what our workflow looks like.
We generally study interconnected networks of open quantum systems where
the connections are realized by freely propagating 1-d bosonic quantum
fields.
A particular node in a network analyzed in isolation would have some
internal Hilbert space H_j and its ensemble averaged dynamics would be
computed through a Lindblad-type master equation.
Now the math behind the circuit algebra that we use allows to combine
multiple such systems and derive the model for the composite system.
This beast now has as its internal Hilbert space the tensor product of its
components H_1 (x) H_2 (x) ... (x) H_n and it could in principle be
embedded into an even larger circuit.
As a consequence, the quantum operators appearing in the overall circuit
models are usually polynomials in operators that act non-trivially only on
specific degrees of freedom.
E.g. if component j were an optical cavity that contains a single harmonic
oscillator degree of freedom, then there would be an associated pair of
creation and annihilation operators a_j, Dagger(a_j).
If we consider a single product M_1 (x) N_2, i.e. an operator M acting on
the degree of freedom labelled 1 and N acting on 2, there are two basic
ways to implement operators on such a tensor space structure.
1. For any single degree of freedom operator M_1 to be considered in a
composite system, it needs to be explicitly lifted to the whole tensor
space by tensor-multiplying it with identity operators for all remaining
degrees of freedom:
M_1 -> M_1 (x) Id_2
N_2 -> id_1 (x) N_2
2. Each single degree of freedom operator only keeps track of its
associated Hilbert space and commutes with operators acting on other
degrees of freedom.
M_1 stays M_1, N_2 stays N_2 and only when they are multiplied, their
product is considered to act non-trivially on both 1 and 2.
Their product would simply be written as
M_1 * N_2
with the fact that this is a tensor product being implicit in their
acting on different degrees of freedom.
As it stands, the classes and methods within sympy.physics.quantum
basically follow approach 1) whereas sympy.physics.secondquant appears to
follow 2).
The advantages of 1) are:
- It's very simple to resolve commutation issues for operators on
independent degrees of freedom
- The normal form, e.g. for the above example is given naturally
- It is trivial to resolve how such an operator acts on a given Hilbert
space vector because that vector needs to be defined as a sum over similar
tensor products.
- It is very easy to compute the numerical representation in a given basis
and do things like interfacing with QuTiP [3].
The advantages of 2) are:
- It is very easy to scale up to very many degrees of freedom without
cluttering your expressions
- The notation is much more like most people write quantum operator
expressions by hand
- There need not be two different operations for multiplications (within a
degree of freedom) and tensor products
- Even when working with a many component system it is trivially easy to
obtain operator expressions that are restricted to only subsets of the
overall system, i.e. each operator implicitly is defined on ANY additional
degrees of freedom you might still add to your problem
I guess my main question is, is there any chance you would be open to
making everything effectively follow the second approach?
Or is there some way you can see to make sympy.quantum.operator types
optionally have a Hilbert space property that would me to re-use everything
defined in that module?
I know this must sound pretty drastic, but if we could find an approach to
this that works for everybody, you would gain at least one (probably more)
very motivated contributors to this part of SymPy.
Obviously I would be happy to do all the work myself to prepare these
changes.
QNET also has some additional features you might find useful, there are
some capabilities for recursive pattern matching / replacement with
wildcards that can stand for single, zero or more or one or more operands.
Similar to x_, x__, x___ in mathematica. It also supports limiting the
types of matched symbols and can handle where a matched symbol must appear
multiple times. Like Add(x_, Times(5, x_)) matches q+(5*q) but not q+(5*r).
If this doesn't already exist, I'd be happy to contribute these things to
SymPy over time or maybe at least help whoever else is working on these.
Brian has already asked me to re-license QNET under MIT/BSD which I intend
to do with the next full release (which, if we can agree on the above might
be the last release of QNET that still features the general purpose quantum
operator algebra code).
Thanks!
Nikolas
[1] QNET: http://mabuchilab.github.io/QNET/
[2] SLH models and networks of quantum optical systems
http://arxiv.org/abs/0707.0048
[3] QuTiP: http://qutip.org/
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/6ee17ea7-30bd-491e-837d-6e9041145f66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
