search

JuliaQuantum / JuliaQuantum.github.io

Public forum and website repository for JuliaQuantum.
http://JuliaQuantum.github.io
MIT License
39 stars 13 forks source link

Topics we can cover at this stage #1

Closed i2000s closed 9 years ago

i2000s commented 9 years ago

From the discussions on Julia-dev, I can see that there have already been some codes for quantum stuffs. It seems to me that all of these codes are just small chunks so that we can easily rewrite and integrate them into some big projects in order to gain better performance and functionality. Could those who have written some Julia codes for quantum post a brief description here on the work that has been done or in progress?

As has been discussed with a few people in the community, our current thought on organizing quantum projects is to have a basis repository to focus on basic quantum state representation and general operations in which we will define some basic Julia types for high-level algorithms. Then we will have a broad spectrum of specific projects to cover quantum chemistry, open quantum system dynamics, quantum information/computation and so on. The Quantum.jl is going to have a good shape very soon, which has implemented many basic quantum states and operations following the Dirac notations. Once the documentation part is done (possibly this weekend on July 13), we can look into it to see if the Quantum.jl is a good foundation for us to start building other branches upon it. In any case, we are open to have projects which are using their own definitions of basic states and operations to have some competitive candidates and fast implementations worth our contributions.

In this thread, we are sharing our existing works, so that we can further discuss where we should make a merge of efforts and where we should put more energy on. We are still a small organization, so that I think we should have a good sense of direction, concentrate our energy on some significant frameworks and build our necessary blocks in an efficiently organized way. Welcome to the Julia for Quantum community and hopefully we can make some significant progress in this summer.

Some projects I know are summarized below:

For people who have existing quantum projects and would like to make them as JuliaQuantum projects, please confirm with commits below ASAP. We will make up our first version target for JuliaQuantum projects.

PS: I am a theoretical physicist from CQuIC, having a specialty in Cavity-QED, nanophotonics with many-body physics, cold atoms, quantum information and control. Moving from Matlab (10-year-long user) to Python and now to Julia, would like to naively help initialize this organization. Any passionate Julia developers for quantum should contact me and deserve an ownership for JuliaQuantum organization for open source projects.

i2000s commented 9 years ago

The discussion on JuliaQuantum roadmap go to https://github.com/JuliaQuantum/Roadmap/issues/1 . Here, we can discuss what we can do for the first release cycle of JuliaQuantum projects in the near future. Enjoy!

jrevels commented 9 years ago

I'm going to go ahead and close this, as any further discussion on this topic should be had here.

i2000s commented 9 years ago

@jrevels I think we need some patience now. I was waiting for people's response on what we can really focus on for the Version 1.0 target. At least, I got confirmed from a few members that they are slowly moving their codes to GitHub and will come back here. The overall roadmap is for long term goals, and it needs to have some concrete milestones set up through discussions like this one to be more executable.

On my opinion, it could be crucial to get confirmed from Alex and Jutho on their existing works once updated. Then we may be able to set up our V1.0 target for the fundamental part of JuliaQuantum projects, start coding, and close this issue. Also, through personal discussion with Blake Johnson, I think there are some limitation on license if we want to directly use the QSimulator.jl and Cliffords.jl codes here. Better to have Blake's conversion here as well. Without really solving these issues, our JuliaQuantum projects can hardly move on to the next stage.

I will come back after the Gordon conference ended on Aug 1. I may meet up with a few Julia guys in MIT during the conf break times for some insights. Glad to have your guys here.

jrevels commented 9 years ago

I wasn't saying that we shouldn't have the conversation - much to the contrary! I just thought that we shouldn't split up (what I had assumed to be) a single conversation between two separate repos.

You've already linked to your JuliaQuantum/Roadmap#1 as the place to have a discussion about implementation topics, and - I had wrongly assumed - to discuss which packages are covering which topics. I just thought you had forgotten to close this one in place of the other. I referenced JuliaQuantum/Roadmap#1 in another issue as the place to hold this discussion, but I'll go back and point people here instead. Sorry for the miscommunication, I'll reopen the issue.

i2000s commented 9 years ago

@Jarrett. The two issues opened in separated places were targeting for different levels. ​

The roadmap repo will be kept clear​ with less discussions, and is only for monitoring progresses and wishlists. It is written especially for the users and coming developers of our libraries to have a hope to look forward to, and does not aiming at assigning tasks to our developers. Any information released there represents official and authority.

This issue opened here is just for the first release cycle, and aiming for assigning people to concrete tasks. It has a power of execution. Once we have some goal set up, the progress will be reflected in the roadmap post as well. If no one respond to this issue after this summer, I will confirm with each other personally, and set up our executable milestone anyway. My expectation is to bond the fundamental parts into the Quantum.jl project, as you have outlined in another thread with representation, dynamics, visualization modules and so on. Glad you found it out by yourself, and brought it up right now :) Similarly, if anyone else has an idea of running a JuliaQuantum project but needing help to develop right away, he/she can post a discussion here, to see if anyone can give a better idea or can take the task. Because any member of JuliaQuantum is also a member of this repository, so everyone will receive new opening issues immediately, by default. However, the roadmap repo was not designed to give everyone the permission to write in that relatively official information, and in fact not everyone was added into the Roadmap repo, and hence only a few people can receive an issue request from the roadmap repo. So, it would be a good idea to post issues requiring wide response from the community in this repo.

I am sure the process of organizing posting and starting projects have been written in some of my long posts somewhere. But, in practice, I think no one wants to read those long posts carefully to think about how this organization should be organized overall. We will examine those ideas of organizing process in practice over time, and will update our Basic Agreements if we found anything inefficient and harmful. That's why I would keep the basic agreement post open for a while, and to see if anyone has better ideas of organizing our activities. Don't worry about miscommunication or something else. I think all will be clear, and will be appreciated. I am grateful for your active inputs, and appreciate anyone else's efforts for this kind of volunteering tasks. Let's just allow anyone some time to enjoy the summer and the community dynamics.

Sorry, this is too long again... I will reduce the length as time moves on.

On Mon, Jul 21, 2014 at 3:00 PM, Jarrett Revels notifications@github.com wrote:

I wasn't saying that we shouldn't have the conversation - much to the contrary! I just think that we shouldn't split up a single conversation between two separate repos; it might get kind of confusing.

You've already linked to your JuliaQuantum/Roadmap#1 https://github.com/JuliaQuantum/Roadmap/issues/1 as the place to have a discussion about implementation topics, and (I had assumed) to discuss which packages are covering which topics. I just thought you had forgotten to close this one in place of the other. I have also already pointed to JuliaQuantum/Roadmap#1 https://github.com/JuliaQuantum/Roadmap/issues/1 in other conversations as the place to hold the discussion. Sorry for the miscommunication.

— Reply to this email directly or view it on GitHub https://github.com/JuliaQuantum/JuliaQuantum.github.io/issues/1#issuecomment-49664883 .

acroy commented 9 years ago

FWIW I have pushed my package to github: QuDOS.jl. There isn't really any documentation (yet), but I have added some examples. Issue acroy/QuDOS.jl#1 gives some overview about its (tentative) scope. Comments etc are greatly appreciated.

jrevels commented 9 years ago

@acroy Good stuff! Would you consider merging what you have with the work I've done, a la the layout I proposed in JuliaQuantum/JuliaQuantum.github.io#4? This would be after we have an actual Quantum.jl repo, of course, which I'm still holding out on making so that people can discuss this layout.

If not, then I'd actually love to see this registered in a package in its own right so that my work can utilize it as a dependency. For example, all of your operator construction methods fit really well with my representation generating functions! Check it out:

julia> using Quantum

julia> fcreate(n::Integer) = dmat(creationop(n), fbasis(n))
fcreate (generic function with 1 method)

julia> showsp(fcreate(10))
10x10 DiracMatrix with 9 Float64 entries:
    [2 ,  1]  =  1.0     | 1:F ⟩⟨ 0:F |
    [3 ,  2]  =  1.4142  | 2:F ⟩⟨ 1:F |
    [4 ,  3]  =  1.7321  | 3:F ⟩⟨ 2:F |
    [5 ,  4]  =  2.0     | 4:F ⟩⟨ 3:F |
    [6 ,  5]  =  2.2361  | 5:F ⟩⟨ 4:F |
    [7 ,  6]  =  2.4495  | 6:F ⟩⟨ 5:F |
    [8 ,  7]  =  2.6458  | 7:F ⟩⟨ 6:F |
    [9 ,  8]  =  2.8284  | 8:F ⟩⟨ 7:F |
    [10,  9]  =  3.0     | 9:F ⟩⟨ 8:F |

#Kronecker product of operators; raising operator for second particle in 3 particle system
julia> showsp(kron(feye(10), fcreate(10), feye(10)))
1000x1000 DiracMatrix with 900 Float64 entries:
    [11  ,    1]  =  1.0     | 0:F, 1:F, 0:F ⟩⟨ 0:F, 0:F, 0:F |
    [12  ,    2]  =  1.0     | 0:F, 1:F, 1:F ⟩⟨ 0:F, 0:F, 1:F |
    [13  ,    3]  =  1.0     | 0:F, 1:F, 2:F ⟩⟨ 0:F, 0:F, 2:F |
    [14  ,    4]  =  1.0     | 0:F, 1:F, 3:F ⟩⟨ 0:F, 0:F, 3:F |
    [15  ,    5]  =  1.0     | 0:F, 1:F, 4:F ⟩⟨ 0:F, 0:F, 4:F |
    [16  ,    6]  =  1.0     | 0:F, 1:F, 5:F ⟩⟨ 0:F, 0:F, 5:F |
    [17  ,    7]  =  1.0     | 0:F, 1:F, 6:F ⟩⟨ 0:F, 0:F, 6:F |
    ⋮
    [993 ,  983]  =  3.0     | 9:F, 9:F, 2:F ⟩⟨ 9:F, 8:F, 2:F |
    [994 ,  984]  =  3.0     | 9:F, 9:F, 3:F ⟩⟨ 9:F, 8:F, 3:F |
    [995 ,  985]  =  3.0     | 9:F, 9:F, 4:F ⟩⟨ 9:F, 8:F, 4:F |
    [996 ,  986]  =  3.0     | 9:F, 9:F, 5:F ⟩⟨ 9:F, 8:F, 5:F |
    [997 ,  987]  =  3.0     | 9:F, 9:F, 6:F ⟩⟨ 9:F, 8:F, 6:F |
    [998 ,  988]  =  3.0     | 9:F, 9:F, 7:F ⟩⟨ 9:F, 8:F, 7:F |
    [999 ,  989]  =  3.0     | 9:F, 9:F, 8:F ⟩⟨ 9:F, 8:F, 8:F |
    [1000,  990]  =  3.0     | 9:F, 9:F, 9:F ⟩⟨ 9:F, 8:F, 9:F |

In a lot of cases, I've already implemented functions like fcreate, but your sparse matrix construction functions run quite a bit faster than mine (for obvious reasons, when I look at your code - this project is my first foray into the world of sparse matrices, and reading your code actually helped a lot).

i2000s commented 9 years ago

I think, at this stage, it is better to compare all existing codes before considering merge. It will take some time to shape a V1.0 target roadmap when we all have some ideas of pros and cons of each code sets. Eventually, there will be a unified code set served as a JuliaQuantum project. Now, we got some more work to do :) You guys can start a separate issue for specific discussions if you want.

On Tue, Jul 22, 2014 at 11:09 AM, Jarrett Revels notifications@github.com wrote:

Good stuff! Would you consider merging what you have with the work I've done, a la the layout I proposed in JuliaQuantum/JuliaQuantum.github.io#4 https://github.com/JuliaQuantum/JuliaQuantum.github.io/issues/4? This would be after we have an actual Quantum.jl repo, of course, which I'm still holding out on making so that people can discuss this layout.

If not, then I'd actually love to see this registered in a package in its own right so that my work can utilize it as a dependency. For example, all of your operator construction methods fit really well with my representation generating functions! Check it out:

julia> using Quantum

julia> fcreate(n::Integer) = dmat(creationop(n), fbasis(n)) fcreate (generic function with 1 method)

julia> showsp(fcreate(10)) 10x10 DiracMatrix with 9 Float64 entries: [2 , 1] = 1.0 | 1:F ⟩⟨ 0:F | [3 , 2] = 1.4142 | 2:F ⟩⟨ 1:F | [4 , 3] = 1.7321 | 3:F ⟩⟨ 2:F | [5 , 4] = 2.0 | 4:F ⟩⟨ 3:F | [6 , 5] = 2.2361 | 5:F ⟩⟨ 4:F | [7 , 6] = 2.4495 | 6:F ⟩⟨ 5:F | [8 , 7] = 2.6458 | 7:F ⟩⟨ 6:F | [9 , 8] = 2.8284 | 8:F ⟩⟨ 7:F | [10, 9] = 3.0 | 9:F ⟩⟨ 8:F |

Kronecker product of operators; raising operator for second particle in 3 particle system

julia> showsp(kron(feye(10), fcreate(10), feye(10))) 1000x1000 DiracMatrix with 900 Float64 entries: [11 , 1] = 1.0 | 0:F, 1:F, 0:F ⟩⟨ 0:F, 0:F, 0:F | [12 , 2] = 1.0 | 0:F, 1:F, 1:F ⟩⟨ 0:F, 0:F, 1:F | [13 , 3] = 1.0 | 0:F, 1:F, 2:F ⟩⟨ 0:F, 0:F, 2:F | [14 , 4] = 1.0 | 0:F, 1:F, 3:F ⟩⟨ 0:F, 0:F, 3:F | [15 , 5] = 1.0 | 0:F, 1:F, 4:F ⟩⟨ 0:F, 0:F, 4:F | [16 , 6] = 1.0 | 0:F, 1:F, 5:F ⟩⟨ 0:F, 0:F, 5:F | [17 , 7] = 1.0 | 0:F, 1:F, 6:F ⟩⟨ 0:F, 0:F, 6:F | ⋮ [993 , 983] = 3.0 | 9:F, 9:F, 2:F ⟩⟨ 9:F, 8:F, 2:F | [994 , 984] = 3.0 | 9:F, 9:F, 3:F ⟩⟨ 9:F, 8:F, 3:F | [995 , 985] = 3.0 | 9:F, 9:F, 4:F ⟩⟨ 9:F, 8:F, 4:F | [996 , 986] = 3.0 | 9:F, 9:F, 5:F ⟩⟨ 9:F, 8:F, 5:F | [997 , 987] = 3.0 | 9:F, 9:F, 6:F ⟩⟨ 9:F, 8:F, 6:F | [998 , 988] = 3.0 | 9:F, 9:F, 7:F ⟩⟨ 9:F, 8:F, 7:F | [999 , 989] = 3.0 | 9:F, 9:F, 8:F ⟩⟨ 9:F, 8:F, 8:F | [1000, 990] = 3.0 | 9:F, 9:F, 9:F ⟩⟨ 9:F, 8:F, 9:F |

In a lot of cases, I've already implemented functions like fcreate, but your sparse matrix construction functions run quite a bit faster than mine (for obvious reasons, when I look at your code - this project is my first foray into the world of sparse matrices, and reading your code actually helped a lot).

— Reply to this email directly or view it on GitHub https://github.com/JuliaQuantum/JuliaQuantum.github.io/issues/1#issuecomment-49769220 .

jrevels commented 9 years ago

V1.0 target topics are what we are discussing in this issue, I thought?

More specifically relating my above comment to this issue: my work covers a lot of features useful for representation modeling, while it seems @acroy's work provides a basis for dynamics and numeric modeling. So, our works constitute candidates for those topics. Also, our two candidate projects already work well together in certain ways, which is obviously a plus. In other words, "comparing existing codes" is what I was trying to do.

The separate discussion of layout and structure of the main repo is at JuliaQuantum/JuliaQuantum.github.io#4, which I renamed "Quantum.jl Specifics" to reflect the fact that it's more about the main repo in general and less about just the work that I've done.

acroy commented 9 years ago

@jrevels : I will comment on the layout question over at JuliaQuantum/JuliaQuantum.github.io#4, but in short I think we should keep different functionality in separate packages (but organized under JuliaQuantum).

I read the documentation of your package and I really like your approach. What do you think about renaming it to QuantumBase.jl since it seems to be a useful basis for other packages? I will need some more (hands on) time to fully appreciate InnerProduct and ScalarExpr, but it seems to be well devised. Maybe we should move discussions about specific details to your Repo? Anyways, I was thinking that having some converts between our state types might be a good start to connect the packages.

i2000s commented 9 years ago

I think if there is no conflict of definition, these two packages can be registered as one. But separating them can save time for quick implementations. We need to see which approach works better. I prefer the combined one.

@ jrevels: the representation part may be adjusted in the end. Different utilities will require different strategies of representations. The package with dynamics provided by Alex also has representation of states and operators in itself. You and Alex need to discuss that. Another example, there may be another package plugged in focusing on matrix product states, and quantum trajectories. There will be corresponding discussions on that side as well. Sometimes, sparse matrix method may not be a good way to do a full Hamiltonian dynamics. Keep an eye on those things as we look into the codes more thoroughly. I think those detailed negotiations can be carried on in new issues for an easy track.

On Tue, Jul 22, 2014 at 12:54 PM, acroy notifications@github.com wrote:

@jrevels https://github.com/jrevels : I will comment on the layout question over at JuliaQuantum/JuliaQuantum.github.io#4 https://github.com/JuliaQuantum/JuliaQuantum.github.io/issues/4, but in short I think we should keep different functionality in separate packages (but organized under JuliaQuantum).

I read the documentation of your package and I really like your approach. What do you think about renaming it to QuantumBase.jl since it seems to be a useful basis for other packages? I will need some more (hands on) time to fully appreciate InnerProduct and ScalarExpr, but it seems to be well devised. Maybe we should move discussions about specific details to your Repo? Anyways, I was thinking that having some converts between our state types might be a good start to connect the packages.

— Reply to this email directly or view it on GitHub https://github.com/JuliaQuantum/JuliaQuantum.github.io/issues/1#issuecomment-49783967 .

Jutho commented 9 years ago

I started writing this post a few hours ago, but never got to finish it. A lot of interesting messages have been sent in the mean time, which I still have to read carefully, so I might be replicating or ignoring some things. I browsed through the docs of Quantum.jl (not so much the source code). Let me comment on it here, rather than in #4 , since I would also like to use this opportunity to give a rough sketch of what I am working on.

Quantum.jl looks like a well developed package, and I see a lot of similarities to how I started the more abstract part of my package for tensor networks. On the other hand, there are also some obvious conflicts and/or name clashes that would make it hard to replace the basic part of my code with the functionality of Quantum.jl. I am discussing this, is because I was under the impression from previous discussions that the goal would be to make Quantum.jl the basic package on top of which most/all other packages are constructed. Before raising some questions/comments, let me discuss how my code has evolved thus far.

I started working on a tensor network toolbox, although there is not much code that is actually working on this stage. I got caught up in the basic definitions and requirements for a long time, resulting in several complete overhauls of my code, and basically breaking all functionality that was already there. I have now isolated a basic part of my code to be released as a stand-alone package, which is everything that has to do with defining and working with tensors. I am currently working on this, and hope that is sufficiently general to be useful in the wider context of physics/mathematics (e.g. general relativity etc) where tensors are used. So there is nothing specific to quantum mechanics in that package. I hope to put a very preliminary version on Github somewhere next week. I decided to define a new type hierarchy for tensors, that is independent of the AbstractArray type of Julia (although the basic Tensor is just a wrapper for Array). This type hierarchy is supposed to work at a slightly more formal way. Tensor indices are associated to vector spaces (henceforth referred to as index spaces), and if the type of vector space to which the tensor index is associated is different from its dual, this corresponds to a tensor which distinguishes between covariant and contravariant indices (i.e. the indices are oriented in the quantum setting). The point is that it is useful to define different vector spaces, corresponding to e.g. symmetries. Hence, I also defined a type hierarchy for vector spaces. Elementary vector spaces can be e.g. a standard Euclidean space, or a vector space graded by irreps of a symmetry group or something else. Tensors are interpreted as multilinear maps on vector spaces and thus live in the tensor product of several elementary spaces, which could be called a composite space. However, aside from the standard Tensor, which is an object living in the tensor product space of its index spaces, one could build tensors which live in e.g. the invariant sector of a tensor product of spaces graded by irreps, the symmetric or antisymmetric subspace of a tensor product of identical spaces, ... One could have fermionic vector spaces as index spaces, which implies that a permutation of the tensor indices will induce certain sign changes etc...

Then there are supposed to be certain operations defined on tensors, the most important of which is contracting tensors, but also, e.g. orthogonal factorisations (singular value decomposition) etc. Finally there should be linear maps that map one tensor onto another one. They deserve a special type in that one typically don't want to fully encode them as matrix, but rather in a way that the matrix vector product can be computed efficiently, for use in iterative methods (Lanczos etc). My two existing packages so far (TensorOperations.jl and LinearMaps.jl) implement this functionality for standard Arrays, the tensor toolbox under construction would overload / redefine them for the new AbstractTensor hierarchy.

In the context of quantum mechanics, I would interpret the elementary vector spaces V as Hilbert spaces for elementary quantum degrees of freedom. A state of a composite system (e.g. a quantum spin chain or lattice system) would then be encoded as a tensor (which is the preferred way of thinking for the tensor network community) with index spaces V1 x V2 x V3. Mixed states/Density matrices could be stored as tensors with indices in V x V* (for an single quantum degree of freedom) . TensorMaps would be the kind of objects that you don't want to encode explicitly, think e.g. a CP map in quantum information theory, where you would rather store the Kraus operators, which allow you to compute the action on a state (a tensor in V x V* ) efficiently. Then there would be the tensor networks, e.g. matrix product states, which encode the state of a composite system with many constituents in a more efficient way. I am not sure wether they need to become a subtype of the AbstractTensor hierarchy.

To return to quantum.jl, let me raise the following questions/comments, mainly from the point of view of thinking would it would mean to use this as the base for my own code (I am not saying that anybody is claiming that this has to be the case): 1) Clearly there would be several name clashes with respect to anything called tensor in quantum.jl, which refers to the tensor product, whereas for me it refers to a Tensor, i.e. a multilinear object living in this tensor product space. 2) Quantum.jl starts with defining basis vectors, I rather started with defining vector spaces. I wanted to implement functionality for defining and iterating over a basis of a given vector space (tensors would then be indexed by basis vectors instead of integers). A basis vector could be identified by e.g. a few integers, corresponding to several quantum numbers. I like the idea of basis vectors in quantum.jl, if one could use the corresponding vector space as b parameter in that definition. Unfortunately, as you mentioned, this is currently not possible, since user defined immutables cannot be used as type parameters. So one could at best use the type of vector space as b, but not the specific instance for which this is a basis vector. 3) I do not understand the rationale of using sparse vectors for storing quantum states. Maybe this comes from a difference in background, but in the context of tensor networks, quantum states are never sparse in the traditional sense of having many zeros. They are 'sparse' in a different way (i.e. they can be obtained from the contraction of network of lower-rank and thus lower-dimensional objects), which also allows to efficiently compute expectation values etc.

jrevels commented 9 years ago

@Jutho Thanks for the response, you raise some extremely valid points. I don't have experience formulating things in terms of tensor networks, but it seems like you're working on something that might be valuable to a wider audience than just quantum physicists - I know there has been a fair amount of discussion on the google group surrounding building more features for higher-rank tensors in general.

From what you wrote, I'm not sure whether or not my package would actually be useful as a dependency for yours. However, I can't really be sure or comment further until I see your code, so I'm looking forward to reading it.

As for your specific questions:

1) I see the issue, and it's an important one. I feel that your package should probably take precedence in using the type name Tensor. I would appreciate it if you could open up an issue in my repo about this, and suggest new names for objects that conflict. I'll try to think of some myself in the meantime.

2) Actually, if you wanted to use your own types as parameters for states, you can! DataTypes can be used. For example:

julia> using Quantum

julia> immutable Foo{A}
           bar::A
       end

julia> ket(Type{Foo{Float64}}, 1)
| 1:Type{Foo{Float64}} ⟩

Of course, the above example is different than explicitly storing an instance of type Foo as a parameter. If that's what you're trying to do, I think it makes more sense to make a new type with both the state and instance of your space type as fields, like so:

immutable TypedState{S<:State, V<:VectorSpace}
           state::S
           space::V
end

It almost sounds like you want to use the Basis type that I've already provided, but I'm not totally sure since I haven't seen the code. If you want, this can be opened as a separate issue in your repo (once you set it up) and we can discuss solutions there.

3) My project explicitly stores the basis alongside the representation, and for this reason, there are many useful cases where general states are going to have a significant number of zeros for coefficients. An example would be the represention of a single eigenstate in the context of a larger basis. This scenario pops up a lot in examples from my docs, and QuTiP's docs as well. However, you could be thinking of a strategy that I haven't considered, in which case I would very much appreciate continuing the discussion. Feel free to open up an issue on this in my repo if you want to discuss it further.

i2000s commented 9 years ago

@jrevels: I believe there is a limitation of horizon for everyone. The tensor network that Jutho talked about is emerged from quantum physics, not just a mathematical abstraction. From my understanding, it is a good strategy to accelerate computing tasks for especially many-body physics. On the bottom, matrix product states language is applied through singular value decomposition (you may think of this as to find eigenvules and eigenvectors for many-body system) to efficiently represent states. A whole bunch of applications have been derived from this approach. I have outlined this direction on the overall roadmap. I believe there is no hard conflict between the codes Jarrett and Jutho are working on. All of these can be worked out. @Jutho Correct me, if I misinterpret your meaning, as I only learn this on paper.

A way to work these out, I can think of, is to make out a detailed hierarchy of quantum representations, like Dirac states (ket and bra), density matrix states, matrix product states and so on. I have given a rough one in the overall roadmap. We can unify our language of defining those names and types and methods under some agreement. In we feel comfortable, we can make all representation part in one project, or separate them through defining promotion and conversion rules for different definitions. I will be happy to see this workout, as I am interested in study using matrix product states and tensor network to trace quantum trajectories. This will be helpful for many other studies as well.

i2000s commented 9 years ago

I just came back from the quantum science conference. Some of my colleagues attending the conference and I have also held a brief meeting with Jiahao, Jeff and other core contributors of the JuliaLang project in MIT to chat about progresses and future plans (photos will be uploaded to our website later). And we got some fresh blood to our JuliaQuantum projects!... I have also read over the documentations and some of the source code (including the TensorToolbox.jl under Jutho's repo) we have mentioned above these days. A lot of exciting progress has been dumped into github, which makes me feel we should now be able to move to the next stage.

Seems to me, the QuDOS.jl repo has been already shaped to a good stage on the quantum dynamics aspect, and no one has a big disputation or conflicts regarding it. The QuDirac.jl has been well coded and documented, but Jutho is working on a competitive project in a close level to span into a base for our fundamental quantum state/operator representations. There may be other efforts on different aspects of coding quantum in Julia, but people have not noticed our calling or just hesitate to announce their plan here. So, here is my suggestion for the next step:

  1. @acroy, you should be able to fork the QuDOS.jl repo to our org now. Although there are places we may need to rewrite or make some improvements, I think we can solve those technical problems under the coordination of JuliaQuantum org in the near future. For example, the QuStateVec type you defined uses AbstractMatrix as the input type and has to judge if the second dim is 1; the performance can be improved if you instead define the input as Vector type. This kind of issues can be solved once we have the quantum representation or base repo set up to optimize the common rep for states and operations. Let us not worry about it for a while. Since our priority of our org is to make sure our packages are compatible with each other and to optimize their performance to the best, there may be breaks of back-compatibility to your previous version as time moves on. I would suggest you to make a copy of your code, and fork a recent version under the JuliaQuantum org so that your previous work will not be disturbed and we can better coordinate the org version easier. You will be leading the project as an owner of the org. Next week, I and @xuhao1 will plug in some code on quantum Monte Carlo method to the QuDOS.jl project with parallel computing enhanced. I guess you may have some initial code on this method already. I appreciate if you can fork the best version to the org ASAP, or I will fork the latest one here if you are busy. We can discuss more technical details later.

  2. @jrevels and @Jutho, through going through your documentations and the source code, I feel that you guys can make one or two nice base projects for JuliaQuantum, but there are still some barriers to work out in order to form a clear roadmap for the base repo. First of all, the present QuDirac.jl gives a good foundation to implement symbolic and numerical calculus for quantum state/operator evolution. Despite the fact that it has not considered more general cases like matrix product states, graph states, general basis and so on. For most easy problems, quantum state is in a flat space, and hence we don't need to worry about the contravariant and covariant basis and so on, and the QuDirac.jl is a quick implementation of a quantum base for simple dynamic solvers. Secondly, from what I read from the current TensorToolbox.jl repo, it has been carefully formated with basis labels and compatible types, and it has been written for a general context of tensor operations. I feel that it will be compatible to the current QuDirac.jl project. We may yet need to replace the AbstractArray types used by QuDirac.jl with AbstractTensor types, or redefine and include some methods from within QuDirac.jl. In that case, the TensorToolbox.jl can be served as a abstract math foundation for concrete physics implementations of operators and states. But it will depend on the final target of these two packages. Therefore, I would suggest @jrevels and @Jutho talk to each other offline to make a solution on whether and how these two packages should be combined into a good base (maybe in terms of two separate repos) for JuliaQuantum projects. In fact, I would like to see the feature of tensor network becoming a unique and effective library in Julia, and to be used for quantum dynamics solvers (see for example, this recent paper). Once you guys form a solution for this base project, we can revise other dynamic solver packages to adapt to the better common base.

    In a long run, since your guys have a good background on symmetry and representation theory, maybe we can consider to make packages to interface with or implement the GAP package, which is C package for Group and discrete algebra. I haven't seen any similar packages written in Julia yet. It would be helpful for solving a wide range of quantum problems.

    I am glad Jutho has made a lot of changes to his original code and to some extent has adopted some conventions that the QuDirac.jl has used. This is a good way to work this situation out, since QuDirac.jl was proposed earlier. I will include this "yielding" rule to our contributor's agreement if this situation works out in this way.

  3. @rpmuller , @jiahao , @blakejohnson : If you guys have any plan on plugging in any quantum projects in our org, please do not hesitate to voice out. It would be better to raise people's attention regarding your work early than late. Even if you only have some basic ideas on what we can work on, it is still worthy to mention here at this stage. We may have volunteers to help you do some concrete stuffs.

Comments?

Jutho commented 9 years ago

Thanks for the nice summary and update @i2000s . Let me clarify some of my work / plans. The TensorToolbox.jl that is currently on my github, but completely undocumented and in a state of rapid changes, is indeed constructed to allow to work with tensors on a general level, but with a high focus on efficiency (mutating methods etc) and of course constructed by somebody with a background in tensor networks for quantum lattice systems. It basically consists of two major parts, and I in fact even consider splitting it in two separate packages.

The first part is the abstract part for defining vector spaces, where I go match the type hierarchy of Julia objects to the mathematical hierarchy of vector spaces. A general vector space V comes in four varieties, corresponding to the representation theory of the general linear group on V, i.e. V itself (fundamental representation), conj(V), dual(V) and dual(conj(V)). For real vector spaces, conj(V)=V and there is only V and dual(V), corresponding to contravariant and covariant vectors. Then there are the inner product spaces, and at the top level of the hierarchy are the Euclidean spaces , which are inner product spaces with a standard Euclidean inner product (i.e. orthogonal basis). Aside from a standard space for arbitrary purposes, I plan to add spaces that can be decomposed into sectors corresponding to irreps of symmetry groups. The role of choice of basis is not yet entirely clear to me, as I would think there is typically one preferred basis, and it is not that you a computer really 'knows' what different bases mean, so any transformation would still have to be specified manually. So I was recycling the idea of basis to be used as an iterator to easily iterate over the contents of the tensor. But unfortunately, for 'cartesian indexing' of an arbitrary Nth order tensor, or for the more custom tensors, it will require the work on staged functions in julia before this can work fast and efficiently.

The second part of TensorToolbox.jl is the actual tensor part, for constructing and computing with tensors. A general Tensor (the only one which is currently defined/implemented) lives in the tensor product of vector spaces, where I think it is ok to restrict to a homogeneous set (e.g. there is no point in taking the tensor product of a vector space with irrep labels and one without). One can then also define e.g. tensors living in the invariant subspace of a tensor product of vector spaces with symmetry sectors, or a tensor living in the symmetric or antisymmetric subspace of a tensor product of identical vector spaces, etc...

I hope that this package is sufficiently general so that it is also useful for the wider physics/mathematics community. E.g. if somebody comes along that creates a package for working with manifolds, he could then define a TangentSpace vector space as subspace of the abstract InnerProductSpace, and he can then immediately create tensors living in the tensor product of a few tangent and cotangent spaces.

I am also working on an actual package for quantum lattice systems using tensor networks. The TensorToolbox.jl is only a requirement for this package, not the actual thing itself. I was thinking of calling it QTNT.jl, for Quantum Tensor Network Toolbox. I can try to put part of it online soon, but it is currently under active development and contains e.g. a full implementation of DMRG and a new algorithm/method for time evolution with MPS, which I still have to publish (which is why the code is not online yet). To clarify how the TensorToolbox.jl relates to quantum stuff. One of the first definitions in QTNT is typealias QuantumVariable Euclidean{Complex{Real}}, meaning that quantum mechanics works with complex vector spaces with euclidean inner product (and one typically choses an orthonormal basis). For these spaces, conj(V)=dual(V), i.e. there is a natural isomorphism between the complex conjugate (Hermitian transpose) vectors and the dual vectors, which we would call bra. Quantum lattice systems would correspond to tensor product spaces of QuantumVariable objects, the prime example being the Qudit, which is just a typealias for the standard ComplexSpace of TensorToolbox.jl, and which one could also write as ℂ^d in Julia, with d some dimension (Int). I guess it is these spaces that are targeted by the QuDirac package.

It would indeed be good if we could define some julia type corresponding to kets, where different storages could be chosen, e.g. a sparse matrix or some type of AbstractTensor. There are several ways to deal with this. One could have a separate type for quantum states (kets) that has a field corresponding to the actual data, which can be of different types. Or one could identify kets with AbstractTensors and define a new SparseTensor for the specific case of a tensor with a single index (i.e. a vector). Both have advantages and disadvantages. I will think some more about this once I have more time. Any comments are welcome.

acroy commented 9 years ago

@i2000s : Glad to hear that you could hook up with some of the Julia developers and also found some more supporters for JuliaQuantum. Let me briefly comment on some of your points here, but I would suggest to discuss the specifics in separate issues (here or at the respective packages).

acroy commented 9 years ago

@Jutho: This sounds really impressive! I think your work on Tensors will indeed be useful for many math/physics applications. I hope I will have a chance to have a closer look and make use of your package(s).

The type you describe in your last paragraph, is basically what @jrevels and I had in mind (see jrevels/QuDirac.jl#2). We wanted to use one field (sparse or dense matrix/vector) for the coefficients and one field to store information about the basis. Maybe this is not the best way though ...

jiahao commented 9 years ago

@timholy has proposed a similar array type in this Images.jl issue to save information about axes labels, which could include basis information. As he wrote:

The key idea is to traverse the array in cache-friendly order but make sure the user can easily extract the current coordinate in physically-meaningful terms.

Would be interesting to bring @timholy and @kmsquire into the discussion, as the ability to have custom-labeled axes seems to be of broad interest.

jrevels commented 9 years ago

This is all sounding great, and I hope to post a more thorough response tomorrow when I have more time.

The array work being discussed is quite exciting, and I have some ideas myself about the functional treatment of basis information. It seems to be an issue that has more wide ranging scope than JuliaQuantum, though - I think the julia-dev group is probably the best place to discuss this. If somebody wouldn't mind creating a thread there and posting a link here, I would be grateful. Otherwise, I can make a thread there myself tomorrow.

i2000s commented 9 years ago

@acroy: As far as you are not worry about breaking back-compatibility of your package under the diversely development of the org in the near future, I would actually very strongly encourage you to actively maintain the package under your account at this stage. Releasing packages under the org's channel is just a way to let people easily see what the org is coordinating, and to better encourage fermionic people to join the open projects under the org's anonymous account. From my past experience of running and participating open source organizations, people will be more likely to get frustrated to participate in the end if the project is under one man's control than the organization case. But we may loose the enthusiasm of the initial developers if we pump projects under the org's name, on the other hand. This kind of volunteering work should be respected, indeed. We will make a list of participating packages for JuliaQuantum projects if any is not under the org's releasing channel. We can adjust our path depending on the interaction from the community. I will revise the corresponding agreement of contributing instructions in the other issue. Does this all work for you?

@acroy again, for the MCWF part, I may only have one week to work on it as new semester starts soon. I was heavily using clusters and doing HPC before, just because I love programming. But my current boss will look down upon me if he knows I am still working on numerical computations, as his group is working on some fundamental theory for the next generation of quantum computers where all classical algorithms may not work at all... In the following week, I will use your current convention to make the MCWF work in a nice way. @xuhao1 agreed to think about using parallel computing (CPU first, GPU package may be developed for other array manipulation tasks) to boost the performance of our packages, and maybe able to work out some GUI for our packages. He may have more time than I do to work on JuliaQuantum projects in the future. He is having an undergrad intern in Harvard now and good at coding, but he may not know quantum theory as deep as we do--he is a theoretical physics major in the second year soon. So, please explain theories in an easy way if he asks you some questions regarding your package. I will also be available to him at any time to answer quick questions about the theories that I know. I believe his joining-in will be a boost for our org.

For everyone, if any of your work is ready to be a part of the official JuliaQuantum projects, please make a direct link to the corresponding repo in the README file and the website page under this repo. Alternately, if your work is ready to be reviewed by all JuliaQuantum members for any reason, please start an issue to awake us. I will close this issue and move the Roadmap list to a standard document once we have an idea of what we are going to work on for the next stage. I feel we are very close to the goal of the initiative stage now and our projects will be self-maintained actively in the future!

Jutho commented 9 years ago

I am also supporting the discussion about different bases with the wider community, and it is actually fantastic to think about the fact that a programming language stimulates scientific discussion between communities that would otherwise not be in contact.

However, I would think that image analysis or classical geometry etc needs a much more general approach towards choice of basis (e.g. nonorthogonal basis etc), or even more generally, choice of coordinate system (curvilinear coordinates etc) then we do in quantum mechanics.

Regarding the use of sparse vectors for quantum states, I am not trying to be critical, but I would like to understand an example where this is relevant, because I don’t have any experience with this from my background. I would think that, even if you start with a state with a small number of zeros, any perturbation to the Hamiltonian or something will immediately fill all the nonzero positions. And if you only expect nonzero numbers at a predetermined number of positions, then this just means that you should restrict to that smaller subspace in the first place? I don’t see how you can expect a quantum state to have a small number of nonzero coefficients at arbitrary positions. Is this something that is relevant in symbolic computations? I would very much like to understand.

In fact, even in the more general linear algebra context, I think the reason that e.g. Julia has sparse matrices but no sparse vectors yet, is that there are many relevant cases for a matrix with a lot of zeros. But the corresponding vectors obtained from e.g. eigenvector decomposition of this sparse matrix, or solving linear systems with this sparse matrix, are always dense.

I hope I am not sending the wrong message. I would strongly support the existence of general sparse multidimensional arrays in Julia or sparse tensors in TensorToolbox.jl. I just try to get a better understanding of the general interests.

On 09 Aug 2014, at 21:54, Jarrett Revels notifications@github.com wrote:

This is all sounding great, and I hope to post a more thorough response tomorrow when I have more time.

The array work being discussed is quite exciting, and I have some ideas myself about the functional treatment of basis information. It seems to be an issue that has more wide ranging scope than JuliaQuantum, though - I think the julia-dev group is probably the best place to discuss this. If somebody wouldn't mind creating a thread there and posting a link here, I would be grateful. Otherwise, I can make a thread there myself tomorrow.

— Reply to this email directly or view it on GitHub.

timholy commented 9 years ago

The array work being discussed is quite exciting, and I have some ideas myself about the functional treatment of basis information. It seems to be an issue that has more wide ranging scope than JuliaQuantum, though - I think the julia-dev group is probably the best place to discuss this. If somebody wouldn't mind creating a thread there and posting a link here, I would be grateful. Otherwise, I can make a thread there myself tomorrow.

See https://github.com/JuliaLang/julia/issues/7941. It's not really focused on the issues of named axes, though. julia-dev might be a better place to discuss such issues.

acroy commented 9 years ago

@i2000s, @xuhao1 : I just pushed my MCWF branch to my repo. There is a function mcwfpropagate, which is not perfect but should be fine for getting started (there is also a simple example). Maybe we should open a new issue for discussions around this? Regarding parallelization we can profit immensely from Julia's infrastructure for parallel computing, e.g. distributing trajectories across several CPUs should be (almost) trivial.

@Jutho: In general you are right, any sparse vector is likely to evolve into something dense. Sometimes one wants to evaluate some properties of a specific state though, like entanglement measures and so on. I guess in that case a sparse vector would be handy? Maybe it is not worth the fuss and we should always use dense vectors/arrays ...

jrevels commented 9 years ago

@Jutho, @acroy The entanglement calculations that inspired me to use sparse vectors in QuDirac.jl were pretty specific to the work of my advisor at the time, and that kind of just got left in there. In general, @Jutho is right. I think the way to resolve this issue would be to parameterize the coefficient container type, i.e. QuantumArray{B<:AbstractBasis, C<:AbstractArray}. That way one can use whatever coefficient container type is relevant to the problem at hand.

jrevels commented 9 years ago

I've started a thread on the julia-dev group here, all further discussion about a general solution for handling coordinate systems/named axes/basis information should go there.

jrevels commented 9 years ago

There are now a bunch of different issues open with potential coverage topics, I'm closing this one as it's old.