-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Topics we can cover at this stage #1
Comments
The discussion on JuliaQuantum roadmap go to JuliaQuantum/Roadmap#1 . Here, we can discuss what we can do for the first release cycle of JuliaQuantum projects in the near future. Enjoy! |
I'm going to go ahead and close this, as any further discussion on this topic should be had here. |
@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. |
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. |
@jarrett. The two issues opened in separated places were targeting for The roadmap repo will be kept clear with less discussions, and is only for This issue opened here is just for the first release cycle, and aiming for I am sure the process of organizing posting and starting projects have been 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
|
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. |
@acroy Good stuff! Would you consider merging what you have with the work I've done, a la the layout I proposed in #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:
In a lot of cases, I've already implemented functions like |
I think, at this stage, it is better to compare all existing codes before On Tue, Jul 22, 2014 at 11:09 AM, Jarrett Revels notifications@github.com
|
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 #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. |
@jrevels : I will comment on the layout question over at #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 |
I think if there is no conflict of definition, these two packages can be @ jrevels: the representation part may be adjusted in the end. Different On Tue, Jul 22, 2014 at 12:54 PM, acroy notifications@github.com wrote:
|
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):
|
@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:
Of course, the above example is different than explicitly storing an instance of type
It almost sounds like you want to use the
|
@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. |
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:
Comments? |
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 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 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. |
@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).
|
@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 ... |
@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:
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. |
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. |
@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! |
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:
|
See JuliaLang/julia#7941. It's not really focused on the issues of named axes, though. julia-dev might be a better place to discuss such issues. |
@i2000s, @xuhao1 : I just pushed my MCWF branch to my repo. There is a function @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 ... |
@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. |
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. |
There are now a bunch of different issues open with potential coverage topics, I'm closing this one as it's old. |
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.
The text was updated successfully, but these errors were encountered: